RE: Issue: Transparency (e.g. NAS visibility of) CUI

[Avi Lior <avi@bridgewatersystems.com>]

Infact, I think that only the oqaque value should have been placed in the
draft in the first place.  SDOs then can define what format they want to
use.

The opaque value gives us two capabilities.

One it allows the home network to create a handle for the user that is
private. It's a number that represents the user for a period of time.

As well, the opaque value allows an SDO to define another format for the CUI
without the need to go to the IETF. 

Some of the current values for the CUI are very specific to 3GPP and 3GPP2.
I felt that the IETF should have provided an opaque value and let those
organizations define the contents.

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Tuesday, December 21, 2004 4:23 PM
> To: radiusext@ops.ietf.org
> Subject: Issue: Transparency (e.g. NAS visibility of) CUI
> 
> 
> Since CUI is intended for utilization at the NAS and at 
> intermediate Proxies in a way that is not possible using the 
> Class attribute, 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, in the interest 
> of global, multi-vendor interoperability.
> 
> --
> 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/>