Re: Proposal: Capabilities Attribute

[Barney Wolff <barney@databus.com>]

On Tue, Jan 18, 2005 at 02:03:18PM -0500, Avi Lior wrote:
> 
> To me that is sending a sparse metrics.  And also, not every capability and
> or sub-capability maps to an attribute. For example, support for DM or COA
> message, they are actually two command codes.

It's a question for debate whether an attribute of 256/8=32 bytes is
bigger or smaller than an attribute of one byte per supported attribute.
I can't get terribly excited either way.

> But in prepaid we need to know whether or not the NAS supports a type of
> prepaid for example Volume based prepaid or Time based prepaid or both. This
> does not map to an attribute but rather a value of one or more attributes.
> So it is not safe to say that Capabilities and sub-capabilities map to
> attributes.

This is exactly what I was ranting against.  If you're gonna support
prepaid, either do both or don't support it.  As for command support,
I might do that with virtual attributes - we're not actually tight on
attribute space, and indefinite expansion of RADIUS makes no sense to
me.  Unless RADIUS remains forever much less complex than Diameter, it
loses its justification for continued use.

Regards,
Barney

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