RE: Chargeable-User-Identity

["Glen Zorn" <glenzorn@comcast.net>]

Dave Nelson [mailto:d.b.nelson@comcast.net] writes:

> Glen,
> 
> > OK, I'll bite: why?
> 
> You I have always disagreed over what constitutes a clean and easily
> re-usable format for attributes, and I wouldn't expect that to change
> anytime soon.
> 
> My point here is that the "exclusion" in the RADIUS Design Guidelines
> draft
> for certain classes of attributes (*) falls down when someone wants to
> re-use one of the heretofore "excepted" attributes in another
> application
> area, one which nicely fits into the traditional RADIUS data model
> (**).
> 
> (*) The "exclusion" is for any attribute that is related to "security",
> is
> intended for parsing and action by some "plug-in" element that's
> outside the
> RADIUS server proper (such as GEOPRIV), or in general for some
> application
> where new code is absolutely required on the server.

This is very a very interesting statement.  
> 
> (**)  The traditional RADIUS data model supports single-valued
> attributes
> and data dictionary driven RADIUS Servers.  Yes, there are existing
> RFCs
> that deviate from this model, slightly.  

2865, 2868, 3162, 4675.  The "tradition" you venerate seems to be of fairly
recent vintage... 

> The idea here is to "protect"
> the
> ability of data dictionary driven RADIUS server implementations to add
> new
> attributes simply as dictionary entries.  

What is being "protected" seem not to be so much the _idea_ of data-driven
dictionaries but the existing, simplistic _implementations_ thereof...

> Complex, multi-part "string"
> attributes cannot be added in this fashion.  They require custom
> parsing
> code.

If, after 9+ years of the existence of so-called "complex" attributes, your
programmers haven't managed to create a simple data-driven machine to parse
them, maybe you need new programmers...



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