Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")

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

Glen Zorn writes...

> Syntactically, I think that they are both strings.  Semantics are a
> different ballgame, of course, but 2865 isn't really consistent on
this
> either.  In fact, RADIUS is (laudably or lamentably, depending on your
> POV) pretty loose WRT to data typing.

I think that Glen has summarized this nicely.  The loose data typing in
RADIUS is definitely a double-edged sword.

I believe that one reason that RADIUS (RFC 2865, RFC 2866) has been
successful with its loose data typing is that it was largely written by
a single author (the engineering staff at Livingston Enterprises).  When
one has a uniformity of vision in the authoring process, formal rules
for data typing are much less important.

I also believe that subsequent RADIUS RFCs, issued after the closing of
the RADIUS WG, have been, in varying degrees, substantially less
successful in maintaining the unstated data model of RADIUS.  I
attribute this to the fact that different authors were involved, with
differing design perspectives, and no guideline to work with.

I would like to see guidelines that would produce a more rational and
self-consistent data model.  I don't think we need the formalism of
something like SMI, as used in SNMP.  I do think some form of unified
data typing, as part of a semi-formal data model, is desirable.

I believe that the RADIUS Design Guidelines document should provide that
kind of guidance.  I don't believe it goes far enough, in its current
version, to address the issue of compound data types (structures). 


--
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/>