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

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Was this issue discussed previously in the wg? Should you shortly raise
it in Dallas, in connection with the Design Guidelines document (or
not)?

Dan


 
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Thursday, March 09, 2006 10:28 PM
> To: radiusext@ops.ietf.org
> Subject: Does RADIUS need a data model? (was RE: RADEXT WG 
> Last Call on "RADIUS Delegated IPv6 Prefix Attribute")
> 
> 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/>
> 

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