Re: Capabilities: Summary

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> Might I suggest one solution to this objection would be to create a
> single new attribute called Required-Attribute, whose value is the
> attribute ID of the required attribute.  Zero or more instances of
> Required-Attribute would be allowed in Access-Challenge messages.

  This was discussed earlier.  We would also need to address the issue
of required values.  i.e. "Service-Type = foo" is required.  And this
wouldn't address functionality that requires multiple attributes,
though one attribute could be used as a place-holder.

  My interest here is to get clarification of the requirements.  If
the sample exchange I gave satisfies the requirements, then that's a
step forward.  The next step is to determine what kinds of
capabilities (or server-side hints) are needed.

  We could define an "attribute list" type, where the content would be
a sequence of attribute numbers, possibly with VSA's in the vendor
format.  e.g.

  0x50 Message-Authenticator
  0x1a Vendor-Specific
    0x00 00 00 09 Cisco
    0x01          Cisco AVPair
  0x1a  Vendor-Specific
    0x00 00 01 ad USR
    0x00 00 00 66 Last number dialed out

  That would simple, clear, and wouldn't require IANA involvement.  It
would avoid the bitstrings of the current proposal, which scare me.

  We could then define:

  Necessary-Attributes of type "attribute number sequence"
  Requested-Attributes of type "attribute number sequence"

  I suggest "Necessary" rather than "required", because I can't think
of another synonym for "requested".  Having both "required" and
"requests" is a recipe for confusion.

  We could so something similar for values.  Extend the "attribute
sequence list" idea by adding a 32-bit integer after each listed
attribute.  e.g.

  0x06  Service-Type
    0x00 00 00 0a Call Check
  0x1a  Vendor-Specific
    0x00 00 01 ad USR
    0x00 00 98 10 Bridging
    0x00 00 00 02 disabled

  This proposal could take up more space than Avi's proposal, but it's
clearer to parse and understand.  And, it has the benefit that you can
address capabilities directly by number, rather than giving a long
string with one capability at the end.

  It also avoids the ACK problem I saw in the original proposal.
There wasn't a way to ACK capabilities there, but in this proposal,
the existing of an attribute is itself the ACK to the request.

  To get the functionality-based implementation that Avi suggested, we
could add another attribute of type "enumeration":

  Supported-Functionality
	foo 1
	bar 2
	...

  Which could be used as part of the above scheme to implement what
Avi was suggesting.

  If this is satisfactory to the group, I'll write up something more
formal.  If Avi is OK with it, the text could go into the end-to-end
capability draft.

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