I think that it might be a better idea instead of using the (already assigned to IANA, as David has pointed out) Vendor-Id of zero (0) for the radext extended attributes to instead request a separate Vendor-Id for the radext WG & encourage other WGs that need new attributes to do the same. For example, the hokey WG is likely to need at least one new RADIUSattribute, so it would get its own ID (& therefore its own namespace). Thishas the advantage of expanding the standard attribute space by leaps rather than baby steps ;-) & provides a fairly automatic & orderly method of namespace management. Thoughts?
I would agree that there is a namespace management issue, not only for the extensions, but also for VSAs in general. If we are looking to enable SDOs to manage their own RADIUS attribute space much as as they manage their OID space (e.g. virtually unlimited space, not gated by IANA), then I don't think you can get there via use of a single Vendor-Id and an 8 bit Vendor-Type space.
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. 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.
-- 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/>