RE: -01 version of Chargeable User Identity

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

> A bigger question is the expected behavior by NAS and RADIUS server.
> 
> What is the purpose of the "null CUI" attribute in the 
> Access-Request?  Is
> this to inform the RADIUS server that the NAS supports CUI, 
> in case the
> RADIUS server supports it and wants to use it? 

Yes, this is the reason, at least IMO.  If so, I propose the following
text:

"
The NAS SHOULD include the CUI attribute with a nul value in the
Access-Request message to advertise its support for this attribute to
the RADIUS server.  In cases where the CUI is required for the proper
billing and the home RADIUS server cannot determine the NAS support for
the CUI attribute, the home RADIUS server MAY reject the request by
sending an Access-Reject message containing a Reply-Message(18)
attribute indicating the failure text: "CUI is missing".
"

Your comment?

> Or is it a 
> statement from
> the NAS that "the RADIUS server MUST support CUI or I won't provide
> service."
> 
> The latter is more problematic, because the RADIUS server 
> could send an
> Access-Accept with no CUI attribute, and then wonder why the NAS never
> sent an Accounting packet indicating that service started.  Or is the
> intent for a non-supporting RADIUS server to send an 
> Access-Reject?  If
> so, then we need to verify that existing RADIUS servers that 
> don't support
> CUI actually behave this way.
> 


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