[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: backwards compatible introduction of NEW attribute such as CUI
Hi David, all
Thanks. Please see my response inline.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Nelson, David
> Sent: Tuesday, December 07, 2004 12:45 PM
> To: email@example.com
> 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 firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.