RE: backwards compatible introduction of NEW attribute such as CUI

["Nelson, David" <dnelson@enterasys.com>]

Farid Adrangi writes...
  
> We are currently working on -03 version of the CUI draft.  Here 
> is a snippet on what we want to say about backward compatibility.
> 
> "
> ... Servers which do not understand the CUI attribute SHOULD 
> silently discard the attribute.
> 
> The NAS MAY include the CUI attribute with a null character for its 
> data field in the Access-Request message to indicate its support for 
> this attribute to the home RADIUS server.  In cases where home 
> RADIUS server cannot determine the NAS support for the CUI, if the 
> CUI is required for proper billing, the home RADIUS server MUST 
> reject the request by sending an Access-Reject message including an 
> Error-Cause attribute [RFC3576] with value 402 (decimal), "Missing 
> Attribute".

DBN:  Would it be preferable to create a new value of Error-Cause to more specifically describe the incompatibility?  While Missing-CUI might be too specific, Missing Attribute is quite broad.

> Otherwise, the home RADIUS server MUST send both the UserName 
> (1) attribute and the CUI attribute, with the understanding that if 
> the NAS supports the CUI attribute the CUI attribute will override 
> the identity portion the UserName (1) attribute.

DBN:  I think you want to qualify this MUST statement with "if the authentication is successful".  That is probably understood from context, but added clarity may be helpful.

> That is, the UserName(1) attribute will be used for routing and the CUI
> attribute will be used for identity purposes.
>"
>
> Before we get into developing a protocol (as suggested below) to 
> determine the CUI support, I would like to know why the above
> paragraph does not address the backward compatibility problem. 

DBN: IMHO, it does.

DBN:  Editorial nits:  "UserName (1)" is User-Name (1)". Do you want to use the text "CUI attribute" or do you want to spell out a standard format RADIUS attribute name. e.g. "Chargeable-User-ID (tba)"?
 

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