RE: Issue 278

["D. B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...
 
>  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.

In hind sight, that was a very inconvenient thing for implements to have
done, although I can see its attraction in terms of abstracting properties
of various classes of attributes.

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

I suggested at two different IETF meetings that using a Vendor ID of 0 might
be problematic.  I envisioned just this sort of scenario.  No one seemed to
see the same issues, since my suggestion gathered no support.  :-)  We could
revisit the use of 0 and assign some other, non-zero, PEN.

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

Or we could reserve the legacy values 0..255.



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