RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Tuesday, December 21, 2004 4:15 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Scope of applicability for CUI
> 
> 
> Emile van Bergen writes...
> 
> > And I also think that we shouldn't try to hide the fact 
> that Class can 
> > also solve a lot of the scenarios. It should be /very/ 
> clear what the 
> > differences and limitations are of each, eg.:
> > 
> > 	Class can be used by a home AAA and any intermediate to
> > 	provide itself, and itself only, with a cookie set at accept
> > 	time and received at accounting time.
> > 
> > 	CUI can be used by a home AAA to provide a value to the client
> > 	and each intermediate, set at accept time and received at
> > 	accounting time. It can be used at accounting time, and when
> > 	receiving an accept, in deciding whether or not to honour it.
> > 
> > 	The other properties of CUI follow from that: only one instance,
> > 	and no modifications allowed.
> > 
> > 	Because intermediates cannot add their own CUI, it cannot be
> > 	used by intermediates to implement their own tracking schemes.
> > 	In such cases they need Class, not CUI.
> 
> This is a good summary, I think.

I agree with the summary.  I object to telling people why they should use
class.

And class is not only used for tracking. So lets leave it for other
documents to specify what class should or should not be used for.

> One point that should be emphasized is that the content of 
> CUI is the Home AAA Server's *assertion* of [billable, 
> chargeable] identity, and all "downstream" entities should 
> trust its content to be meaningful only to the extent that 
> the Home AAA Server, and the organization that operates it, 
> are both reliable and trustworthy.

I think we do that in the draft.
 
> There have been suggestions made that the content of CUI has 
> some local semantics at the NAS or a Proxy, beyond its 
> utility for inclusion in on-line or off-line accounting 
> records.  To the extent that common use cases for local 
> semantics (e.g. limitation of simultaneous logins) are 
> identified, they should be documented, in the interest of 
> global, multi-vendor interoperability.

I think we cover that. But there are many other cases as well. I don't think
we should start enumerating these uses.
 
> Given this description of CUI, what is the utility of the 
> opaque data format of CUI?  I understand that opaqueness can 
> be rendered transparent with the bilateral sharing of 
> proprietary information, pursuant to a business contract.  
> However, that exception notwithstanding, if the intent of CUI 
> is visibility and utility to the NAS and to the Proxies, I 
> suggest that the opaque data format be removed from the draft.
> 
> 
> 
> --
> 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/>