RE: Clearinghouse/Aggregator Support for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Hi Alan,

Just to add and highlight some of your thoughts.  

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Monday, October 25, 2004 10:49 PM
> To: radiusext@ops.ietf.org
> Subject: Re: Clearinghouse/Aggregator Support for CUI
> 
> 
> "Blair T. Bullock" <bbullock@ipass.com> wrote:
> > CLASS - The Class Attribute was the initial legacy-based 
> work-around 
> > to CUI based on its ability to reflect home data in an accounting 
> > stream.
> > However:
> ...
> > 2 - This is an additive attribute and their value ordering 
> > unspecified.
> > How many classes to we demand support for in a NAS?  One?  
> Four?  Eight?
> >  Many of these APs don't have that much processing power.
> 
>   How much processing power is required to keep track of ~1k 
> of data, for multiple attributes?
> 
>   I can see memory on the AP being an issue, and 
> implemenation limitations.  Some AP's already discard 
> trailing octets from the State attribute, if it's longer than 
> 16 octets.  Similar issues may apply to Class.

Many NASes (if they support Class) will only support one Class attribute.
Many NASes truncate Class at the first NULL.
All very ugly.

>   I don't see ordering as much of an issue.  Implementations 
> which use the Class attribute should have some way of 
> recognizing which of multiple Class attributes is theirs.

True.  
 
>   I'm not saying that we *should* use Class, as the CUI does 
> appear to be better.  I just wish to be sure that the 
> benefits of CUI are clear.

I don't think Class is even a starter when we are talking outside the home
realm.
 
>   My one concern about the CUI is privacy.  We may want 
> intermediaries to not know the identity, but to still have a 
> unique "token" which may be used to bill the home network.  
> The "opaque string" type is good for this purpose, but it 
> would be good to include a suggested "best practices" for format.

I agree.  My approach to CUI was to utilize an opaque string. Communities of
operators (e.g., 3GPP 3GPP2 ) would then choose the format that is most
appropriate for this attribute and the contents.  So if they were concerned
about privacy etc... 

However, due to Diameter CC and GSMA we have formally defined several
formats for this attribute.

But most importantly, its up to the Operator's to choose how private the CUI
is.  Its up to us to make sure everyone understands the Privacy issue.

>   Alan DeKok.
> 
> --
> 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/>