RE: Issue -- draft-ieft-radext-chargeable-user-id-00

[<john.loughney@nokia.com>]

Hi David,

This seems like a reasonable change. We can fix this in the next update.

cheers,
John

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Nelson, David
> Sent: 10 December, 2004 19:32
> To: radiusext@ops.ietf.org
> Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
> 
> 
> Description of issue: Use of Chargeable-User-ID attribute in
> Access-Request Messages
> Submitter name: Dave Nelson
> Submitter email address: dnelson@enterasys.com
> Date first submitted: December 10, 2004
> Reference: (N/A)
> Document: draft-ietf-radext-chargeable-user-id-00.txt
> Comment type: T
> Priority: 1
> Section: 2.1
> Rationale/Explanation of issue:  Unless and until the RADEXT 
> WG decides
> to enhance RADIUS to include Capabilities Negotiation (as it exists,
> e.g. in PPP), we need to continue to rely on Capabilities 
> Advertisement.
> Advertisement has been a standardized part of RADIUS, in the form of
> "hint" attributes in Access-Request messages, since its inception.
> There has been discussion on the mailing list that suggests we ought
> define Capabilities Negotiation for new attributes that are considered
> mandatory (or conditionally mandatory) such as Chargeable-User-ID.  In
> order to drive this issue to a resolution, I am suggesting a change to
> the draft to make Capabilities Advertisement a strong SHOULD.
> Length description of problem:  (see above)
> 
> Requested change: Change the following text in Section 2.1:
>  
> From:
> 
> "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 the home
> RADIUS server cannot determine the NAS support for the CUI, if the
> home RADIUS server requires the NAS support for CUI for any reason
> (e.g., for billing or charging purposes), the home RADIUS server MUST
> reject the request by sending an Access-Reject message including an
> Error-Cause attribute [RFC3576] with value (to-be-defined) (decimal),
> "CUI-Support-Undetermined"."
> 
> To:
> 
> "The NAS SHOULD 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, unless deployment specific
> constraints dictate that the home RADIUS server has some 
> other reliable
> means to determine that the NAS supports this attribute.  Such means
> might include out-of-band configuration.  In cases where the 
> home RADIUS
> server cannot determine the NAS support for the CUI, if the 
> home RADIUS
> server requires the NAS support for CUI for any reason (e.g., for
> billing or charging purposes), the home RADIUS server MUST reject the
> request by sending an Access-Reject message including an Error-Cause
> attribute [RFC3576] with value (to-be-defined) (decimal),
> "CUI-Support-Undetermined"."
> 
> 
> --
> 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/>