[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dave Nelson [mailto:firstname.lastname@example.org] writes:
> > 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
> for certain classes of attributes (*) falls down when someone wants to
> re-use one of the heretofore "excepted" attributes in another
> area, one which nicely fits into the traditional RADIUS data model
> (*) The "exclusion" is for any attribute that is related to "security",
> 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
> where new code is absolutely required on the server.
This is very a very interesting statement.
> (**) The traditional RADIUS data model supports single-valued
> and data dictionary driven RADIUS Servers. Yes, there are existing
> that deviate from this model, slightly.
2865, 2868, 3162, 4675. The "tradition" you venerate seems to be of fairly
> The idea here is to "protect"
> ability of data dictionary driven RADIUS server implementations to add
> 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
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.