[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
Glen Zorn said:
"There are problems with such things, as this conversation illustrates. One
is that one person's "meaningful type" is another's "meaningless
distinction", leading to (possibly endless) discussions akin to those
medieval ones involving angels and pins ;-); another is the addition of yet
another constituency to the debate over protocol extension. How long would
it be before we hear from some server vendor that some perfectly reasonable
& extremely useful RADIUS extension cannot be adopted because "my parser
won't handle that data type"?"
Maybe it would be useful to go back to the original justification for the
RADIUS dictionary. RADIUS does not support explicit data typing as in
ASN.1, for example. As far as I can tell, the purpose of including any
typing at all in RADIUS is to enable support for new attributes by addition
of dictionary entries, without changing code. This is not just an academic
point about "data models" -- this has real impact on customers.
As Emile has noted, some implementations have added support for more
elaborate structures, allowing compound attributes of type "STRING" to be
entered more easily (e.g. the tagged attributes of RFC 2868).
However, this is but a detail -- using the basic RADIUS data types, it is
possible for the administrator to add support for virtually any new
attribute sent by the server to the client, by adding a dictionary entry.
No new code required. So if we are talking about attributes only sent in
Access-Challenges or Access-Accepts, I don't think see how compound
attributes affect the ability of administrators to add support for new
attributes without code changes.
The issue is really about attributes sent from the client to the server. As
Emile noted, if the attribute sub-elements don't need to be addressed
individually, such as if they are always handled as an opaque blob, then the
attribute can be treated as type "STRING" by the server, and existing
implementations will work just fine, so there is no issue.
The problem occurs if the sub-elements need to be referred to individually.
Can existing implementations handle this, or will new code be required? My
guess is that in most cases, new code *will* be required. If so, these kind
of attributes represent a departure from the principles underlying the
creation of the RADIUS dictionary, and will force users to upgrade their
servers. So this is really the situation in which compound attributes
impose a real cost.
As far as I can tell, while compound attributes have a rich history within
RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have
any compound attributes been introduced which require individual addressing
of sub-elements. So as far as I can see, it is not use of "compound
attributes" but rather "individually addressable sub-elements" that
represents the critical distinction here.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.