RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>