RE: Clearinghouse/Aggregator Support for CUI

[Avi Lior <avi@bridgewatersystems.com>]

It wouldn't be a vendor (as in Bridgewater etc) that would determine how it
will generate a handle for a real identity and store it in the CUI.

It would be a vendor as in the case of an SDO such as 3GPP or 3GPP2 that
would determine the method for generating handles to subscribers.  For
example, 3GPP already does generate a TIMSI (temporary IMSI) to protect the
true identity. They would define the method of generating an temporary
identity and the length of time.

Note that users of that identity (Clients) really don't care of the format
of the attribute and how it was generated.  They would just use the value as
given knowing that it represents a handle to the identity that will be valid
for some time period.

For example if a 3GPP operator were to send the value to a WLAN operator,
the WLAN operator just needs to know that that value allocated by a 3GPP
operators represents the value of a user for a length of time.  The length
of time will be made known to the WLAN operator based on business
arrangements.



> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Monday, October 25, 2004 5:37 PM
> To: Avi Lior; Alan DeKok; radiusext@ops.ietf.org
> Subject: RE: Clearinghouse/Aggregator Support for CUI
> 
> 
> > I don't think that it is appropriate to mention this in the draft.
> 
> I guess that would depend on whether one would expect to be 
> able to demonstrate multi-vendor interoperability solely 
> based on what is documented in an IETF RFC.  If it is 
> acceptable to require additional, Non-IETF information in 
> order to demonstrate multi-vendor interoperability, then 
> maybe one could omit this information. 
> 

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