Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft)

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...

> I think it depends upon one's interpretation (which is what this
> conversation is about).  BTW, the definition of the "Address" data 
> type in RFC 2865 is identical (with the exception that addresses 
> can be signed) to that of "Integer"; what does that mean? 

Good question.  I don't think I've ever seen the address data type used.
The notion of a signed address confuses me.  :-)

> More to 
> the point, it doesn't matter to me whether the attribute data field
> in question is defined as a string or an integer, since it is 
> neither (or both, depending upon your POV).

Well, I suppose it does matter when the encoding on the wire may differ,
or one implementer's interpretation (POV) differs from another's,
resulting in poor interoperability.

> > I'm sure that there are lots of such programs, as C has no 
> > strong data typing.
> 
> As you imply below, neither does RADIUS...

I think RFCs 2865/66 have strong, but very limited (and limiting), data
typing.  Once you get beyond those base documents, yes, I think there is
no consistent data model.

> > The substance of this discussion, I think, is whether
> > or not the RADIUS protocol should have meaningful data model, 
> >and meaningful data types,
> 
> There are problems with such things, as this conversation 
> illustrates.  One is that one person's "meaningful type" is 
> another's "meaningless distinction", leading to (possibly endless)
> discussions akin to those medieval ones involving angels and pins ;-);
> another is the addition of yet another constituency to the debate
> over protocol extension.  How long would it be before we hear from 
> some server vendor that some perfectly reasonable & extremely useful
> RADIUS extension cannot be adopted because "my parser won't handle 
> that data type"?

I agree that the right balance is important.  My feeling is that we need
more formality in the RADIUS data model that we have now (which is
pretty minimal) to enhance interoperability going forwards, and allow
server vendors who wish to design data dictionary driven implementations
to do so.  Exactly how much more is the topic we should be debating.

I've noticed, BTW, that no one on the list has taken up Greg Weber's
invitation to directly comment upon his latest RADIUS Design Guidelines
draft.  We seem to be having some of that discussion, in a
meta-discussion sense, in this thread though.  I suppose that simply
validates the observation that WG's don't really engage in discussing
any document until WGLC.  :-)


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>