Re: Issues with draft-ietf-radext-extended-attributes-05.txt

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Issue 225 -- It would appear that the major point of contention here
> relates to the length field and
> fragmentation.  I believe that  this comment could be resolved by
> addition of some advice (a SHOULD
> might suffice) on fragmentation usage for senders and support on
> receivers.   The ability to include
> multiple attributes inside a VSA was allowed in RFC 2865, and so should
> not be a subject of dispute
> for this document.  Given that this issue is nearly resolved, I would
> suggest that you and Alan
> work out appropriate text.

  I'll see if I can suggest something.

> Issue 278 -- The remaining portion of this issue relates to whether IANA
> can allocate Extended
> Attributes 0-255, and if by doing so, confusion would be created with
> respect to existing
> RADIUS attributes.  What is interesting about this discussion is that it
> only arose once the
> size of the type field was expanded to 16 bits.  In general, we have not
> seen confusion
> relating to use of VSAs with Type Code values which overlap the
> standards range (which
> most do).  For example, do people confuse Example.com VSA #32 with the
> RADIUS
> NAS-Identifier attribute (32)?   Maybe this issue could be resolved by
> suggestion of appropriate
> nomenclature.  For example, the term "<Attribute name> Extended
> Attribute (#)"
> instead of today's usage "NAS-Identifier Attribute (32)". 

  I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals.

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