RE: Chargeable-User-Identity

["Dave Nelson" <d.b.nelson@comcast.net>]

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.

(**)  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.  The idea here is to "protect" the
ability of data dictionary driven RADIUS server implementations to add new
attributes simply as dictionary entries.  Complex, multi-part "string"
attributes cannot be added in this fashion.  They require custom parsing
code.



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