Re: Vendor-Id for radext extended attributes

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> The question in my mind is whether it is better to go with multiple
> Vendor-Ids, or instead, to expand the Vendor-Type space to 16 bits.  

  I am wary of defining yet another VSA format.  Existing 16-bit VSAs do
not support grouping, which is supported by the current extended
attribute format.  Modifying the current proposal to support 16-bit VSAs
would mean incompatibilities with WiMAX, which uses a similar format.

> While there is more work involved in supporting a 16-bit Vendor-Type
> space, it seems like a cleaner solution long term, particularly from the
> IANA point of view.  Asking IANA to track Vendor-Id allocations for
> individual WGs, and individual RADIUS attribute allocations within those
> Vendor-Ids, seems like it could quickly become complex.

  Agreed.  A flat 16-bit name space would be simpler.

  On the other hand, the WiMAX standard supports sub-AVPs inside of a
WiMAX VSA.  i.e. RADIUS attribute 26, WiMAX attribute X, sub-AVP Y, all
nested inside one another.

  Allowing that would extend the attribute space significantly.  It
would also easily permit grouping of logically related items, such as
with the filter draft.  The individual filter elements could be
converted from the current proposal (text) to AVPs inside of a filter
VSA.  That would also allow easy addition of new filter elements.

  To prioritize the choices, I'd prefer modifying the current proposal
to use 16-bit VSAs before I would add sub-AVPs.

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