RE: Capabilities Proposals

["Nelson, David" <dnelson@enterasys.com>]

Barney Wolff writes...
 
> I don't believe a capabilities attribute is required for CUI.  The
last
> scheme I'm aware of for CUI has the proxy or NAS that requires CUI
signal
> that by including a NUL CUI attribute in its Access-Request.

If we generalize the concept to "capabilities signaling", then I think
that both notions are covered.  The existence of a capability can be
signaled to a peer by either (a) sending a pre-agreed value of the
attribute in question that denotes support (e.g. the NULL CUI value), or
(b) setting one (or more) bits in a special capabilities attribute,
indicating support for one (or more) attributes (presumably other than
the capabilities attribute itself).

The assertion that method (a) is preferable for CUI does not indicate
that capabilities signaling, per se, is not a requirement for CUI.  I
think what's being debated is whether the WG wants to adopt method (a)
or method (b) as the form of capabilities signaling.  Alternately we
could do this in an ad-hoc fashion with some attributes using method (a)
and some using method (b), but that would seem to me, at least, to be
more complicated.



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