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

["Avi Lior" <avi@bridgewatersystems.com>]

Bernard,

I agree with what you wrote and I want to add something:

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

But also, even if we added an attribute of known type say "FOO" type
integer, the Server would not have to add any code to parse this
attribute, but it probably will need to have code to handle this
attribute, unless of course all the server did was record the attribute
and did not intepret it.

So whether or not the attribute is compound or not, if the server needs
to "interact" with that attribute then it needs to have new code added.
This applies to any server or client that needs to "interact" with that
attribute.

So the notion of dictionary driven code and using existing radius types
really speaks only about not adding any code to the RADIUS packet
encoder/decoder. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Tuesday, March 14, 2006 10:17 PM
> To: radiusext@ops.ietf.org
> Subject: 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 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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