Re: Capabilities: Summary

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> What if we were to re-examine the extended RADIUS attribute format,
> complete with a Mandatory bit?  Could we then simplify the whole
> capabilities issue down to detection of support for (a) Access-Challenge
> and (b) Extended Attribute format?

  Backwards compatibility in existing attributes being "mandatory" for
an implementation?  Existing Vendor-Specific extensions that don't
have a mandatory bit?  Or, *requested* information like location?

  e.g. "If you have location, provide it, otherwise it's still OK".
That appears to be the use-case Avi is addressing.  A mandatory bit in
an extended attribute doesn't support his use-case.  Adding an
"requested" bit does address it, though.  You're then back to 2 bits
per attribute, which is pretty much what Avi was suggesting in a
different layout.

  To address your comments out of order:

> While the syntax is concise, formal and parse-able, the overall level of
> complexity to satisfy both clients and servers as to desired and
> required attribute support is growing again.

  I don't think the issue is "required attribute support", so much as
"required and optional functionality support".  The mandatory bit in
Diameter is nice, but I don't see it as being incredibly useful in
deployments.  Customers want functionality-based solutions, not
attribute-based solutions.

  To that end, Avi's functionality-based capability draft addresses
the problem directly.  It's just the format and future concerns that
concern me.

  If we focus on functionality support, two attributes would suffice:

  Mandatory-Functionality
  Requested-Functionality

  Make them enumerated int32's, and allow zero or more in
Access-Request and Access-Challenge.  Even allow them in
Access-Reject, as a hint as to why the request was rejected.  Start
off with value 1 meaning "understands Access-Challenge for PAP, etc",
and go on from there.  This would be fully compatible with existing
implementations, vendor-specific solutions, etc.

  The use cases Avi had in the end-to-end document looked like they
would have a very limited number of functionality advertisements.  So
making them int32's versus bits would have little protocol impact.

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