RE: Scope of applicability for CUI

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

Jari Arkko writes...

> But this brings me to a new issue. Remember how we agreed that
> CUI helps in policy decisions, such as the one-session-at-a-time
> rule. My question is whether there's a second utility which
> is not quite as apparent because it operates again at the
> "billing layer" which is not standardized. We can make CUI
> an opaque entity, only designed for the equality test. An
> opaque CUI can also be used as a billing handle, as long
> as organizations X and Y agree that they are using the CUIs
> in this process, either in the RADIUS accounting messages
> or in the postprocessing/billing transactions or in both.
> 
> However, looking at the definition of the CUI, it seems
> that people want *also* the ability to use a cleartext
> user handle of a specific format. One reason for wanting
> to do this would be to, say, be able to feed the identity
> to an existing roaming/accounting/billing system that can
> only support a specific type of an identity. Is this
> the reason why we have non-opaque values in the document
> too? Or is there some other reason, such as tracing/
> legal interception/logging need to see actual user
> identities?

I guess this is what I've been poking at in the past few days.  Do we
have two different problems that we're attempting to solve using a
single attribute?  The "paradox" as I've stated it is maintaining the
notion of CUI as an opaque handle and at the same time providing for
explicit (and ostensibly clear-text, human readable) name formats in the
same attribute.



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