RE: Scope of applicability for CUI

["Nelson, David" <dnelson@enterasys.com>]

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.

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.

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.

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