RE: Mandating 3579 and 2486bis for CUI was RE: Scope of applicab ility for CUI

[Avi Lior <avi@bridgewatersystems.com>]

We could document other examples of usage. But I didn't think that that is
necessary. After all we are talking about one attribute. It is for the most
part tightly specified and we allow a free form specification for it (the
opaque option).

So if you insist we can put other usecases in...but that last thing I want
is to create more confusion, more debate.

But it is important for us not to tie this thing down to 3579 and 2846.

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Friday, December 17, 2004 5:27 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Mandating 3579 and 2486bis for CUI was RE: Scope 
> of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > Family members may have one username for example:
> papabear@example.com,
> > mamabear@example.com etc,, while the billing identity is 
> > thebearfamily@example.com.  The billing identity may be required
> outside
> > the home network.
> 
> Snipping the other example use cases for the sake of brevity.
> 
> Great.  Specific use cases are far more helpful than 
> generalized posturing.
> 
> I can see that your examples may be of utility in certain 
> deployments. Given that some of these examples entail 
> semantics (i.e. required
> actions) at the NAS beyond the requirement to include the CUI 
> in future *-Request messages, it would be helpful if these 
> requirements were documented, somewhere.  The CUI draft may 
> be an obvious place, but it could be some other document.  In 
> the interests of global interoperability, it would be helpful 
> if anyone reading the RFC(s) on CUI could understand all the 
> standardized uses, and implement NAS firmware that 
> interoperates in a multi-vendor deployment.
> 
> All that I'm asking for, I guess, is full documentation of 
> the intended uses of the new attribute.  Undocumented uses 
> lead to poor interoperability.  Of course, undocumented uses 
> may also lead to product-specific competitive 
> differentiators.  We need to carefully weigh the interests of 
> multi-vendor interoperability in writing Standards Track RFCs.
> 
> 
> 
> --
> 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/>