[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
- To: <email@example.com>
- Subject: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
- From: "Nelson, David" <firstname.lastname@example.org>
- Date: Thu, 9 Mar 2006 15:28:12 -0500
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
> 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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.