RE: backwards compatible introduction of NEW attribute such as CUI

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hi David, all
Thanks.  Please see my response inline.
BR,
Farid

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Tuesday, December 07, 2004 12:45 PM
> To: radiusext@ops.ietf.org
> Subject: RE: backwards compatible introduction of NEW 
> attribute such as CUI
> 
> 
> 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.
> 

Yes, it would be.  I need to check RFC 3576 to find out the procedure for adding a new value to the Error-Cause.  

> > 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.
> 
Yes. Good point.

> > 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)"?
>  
Will change to User-Name(1).  CUI is shorter, but I am okay with using Chargeable-User-ID instead.
> 
> --
> 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/>