Mandating 3579 and 2486bis for CUI was RE: Scope of applicabilit y for CUI

[Avi Lior <avi@bridgewatersystems.com>]

David,

David wrote:

> I object to the "for whatever reason" line of reasoning.

I object to making something mandatory for the sake of making something
mandatory.

The EAP usecase demonstartes the particallity and the need for CUI. But that
does not mean that that is the only need or use.

If there are no specific requirements to mandate a use of CUI to EAP and
2486bis then we should NOT mandate it. It is bad practice from a protocol
development point of view to create false dependencies.

Please demonstrate why this MUST ONLY work if the NAS only deployed EAP AND
2486.

Otherwise the text in the document is fine as is.  The draft only brings up
the EAP case and that is as far as it should go.


Avi.

 



> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Friday, December 17, 2004 3:08 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > As a driving usecase for this work we noted that when certain EAP 
> > methods are used the identity of the user is hidden and mediating 
> > networks have no way to associate an 
> Authentication\Authorization and 
> > or Accounting events to a specific user or chargeable entity. CUI 
> > provides a mechanims whereby the home network can provide a 
> handle to 
> > the chargeable entity (without revealing the true identity), to the 
> > roaming partners and or mediating networks.
> 
> Yes, this is the justification for standardizing the CUI 
> attribute as a RADEXT WG work item. (And the *only* 
> justification, IMHO.)
> 
> > This does not mean that it is required when EAP is used.  
> Nor does it
> mean
> > that it can't be used in cases where EAP is not used.
> > 
> > It simply means that it is available to be used when it is 
> required by 
> > roaming partners - for whatever reason.
> 
> I object to the "for whatever reason" line of reasoning.  We 
> have justified the existence, usage and support requirement 
> for Chargeable-User-ID by a very specific use case.  Since it 
> is an "alias" for User-Name, and User-Name SHOULD always be 
> used in preference to Chargeable-User-ID, unless these 
> specific circumstances apply, why would it lead to greater 
> interoperability in RADIUS for this attribute to be generally 
> available for various undocumented uses?
> 
> I am generally opposed to "opaque carrier attributes" that 
> have the imprimatur of standardization, by being described in 
> a Standards Track RFC for a specific, well documented 
> purpose, but are then used for other, potentially 
> proprietary, purposes besides the explicitly documented one.  
> I am vaguely concerned that the Chargeable-User-ID might 
> become one of these, if its scope of use is not clearly and 
> concisely defined.
> 
> 
> --
> 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/>