RE: backwards compatible introduction of NEW attribute such as CU I

[Avi Lior <avi@bridgewatersystems.com>]

3576 supports missing attribute indication. The suggestion is not to have
something too specific such as missing CUI but more specific then missing
attribute.? 

I fail to see, in the scope of Error-Cause what we would create that is
between missing cui and missing attribute.

I also have an issue with this.  If we send this new attribute back wouldn't
the RADIUS server have to recognize it. Only a compatible RADIUS Server
would be able to recognize this new attribute. 

Also based on this text it seems to me in cases where CUI is needed by the
server we require the Client to send the CUI -- otherwise if the client
didn't send the CUI the request will be rejected.

So make the advertizement a MUST or a SHOULD.  MAY maybe useless here.  But
perhaps I missed some discussion on this issue.
 
> > > "
> > > ... 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.  

Also please note the User-Name is not the only thing that is used for
routing requests in RADIUS.  We keep forgetting this in the text.  Here are
some snippets from 2865.


Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").

Finally, User-Name is not required in an access-request and this RFC should
not change that.

We can for example have cause to use Called-Station-Id and CUI. So lets not
break existing deployements that could use CUI that don't use User-Name.

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