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

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

Alan DeKok said:

"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."

There are multiple issues here, I think:

a. Whether existing implementations will have a problem with a vendor-id
of zero, regardless of the size of the type code space, and the attribute
numbering;  

b. Whether the *combination* of a vendor-id of zero along with attribute
usage 1-255 can cause problems; 

If we have problem a, then the fix would be to assign the IETF a non-zero
Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 

If we only have problem b, then we could prohibit attributes 1-255 from
being assigned. 



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