RE: -01 version of Chargeable User Identity

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

> 
> On Fri, 15 Oct 2004, Barney Wolff wrote:
> 
> > On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
> >> Thanks for your comments.   RADIUS does not support a 
> generic capability advertisement.
> >> However in this draft,  we can say that the NAS MUST send the CUI
> >> attribute with a nul value in the Access-Request, if it 
> supports the
> >> attribute.  This indicates the home RADIUS server whether 
> or not the
> >> NAS support CUI.  Will this address your concern?
> >
> > Since an old server that does not support CUI is quite 
> likely to respond
> > with Reject to a request with an attribute that it does not 
> understand,
> > this is not likely to solve all interoperability problems.
> 
> Do we know that existing servers will behave this way?  Perhaps a poll
> would be appropriate.
> 

As I stated it in my response to Barney's e-mail, I don't understand why
the RADIUS server should ever reject a request because it contains a new
attribute, not supported by the server.  In general, this should not be
the expected behavior as it impacts the interoperability every time a
new attribute is introduced.  

> 
> In this particular case, my understanding is that the local 
> operator is
> unwilling to provide service if the new attribute isn't 
> included, because
> it does not feeling confident about payment.  So it seems to 
> me that an
> Access-Reject might be the desired response.
> 

I agree.  So, I think the proposal was that NAS advertises its support
for the new attribute by sending a nul CUI.  And, the RADIUS will have
the option to reject the request in the absence of the CUI.  Do you see
any problem with respect to overhead resulting from the CUI
advertisement 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/>