Re: Clearinghouse/Aggregator Support for CUI

["Alan DeKok" <aland@ox.org>]

"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.

  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.

  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.

  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.

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