RE: Vendor-Id for radext extended attributes

["Glen Zorn" <glenzorn@comcast.net>]

[gwz] ...
[gwz] 
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.
[gwz] I don't know -- it seems to have worked out OK so far...

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.
[gwz] 
[gwz] Not sure why we wouldn't let the "vendors" manage their own 8-bit
areas; in any case, though we're talking about a 2-level hierarchy which I
can't imagine anyone (esp. the efficient folks @ IANA) considering
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/>