RE: Glen's proposal for Attribute Extension

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <> scribbled on Monday, August 28, 2006 8:13 AM:

...

> Perhaps.  I'm likely reacting to the "naming thing".  Somehow, the
> notion of a Standard Extended Attribute format that is defined as a
> special case of a Vendor Specific Attribute seems wrong to me.  

Not sure why: it seems to have worked pretty well for other SDOs, 3GPP2
being the one with which I'm most familiar.

> 
> The value you see in using 26 as the "top-level" attribute ID is that
> it re-uses existing code for generating and parsing VSAs?  

Actually, the whole proposal reuses well understood techniques & attempt
to isolate the changes to an area of the code  that is likely fluid in
any case.

> IMHO, once
> you need to make *any* code changes, you need to release new versions
> of the SW/FW.  I very much doubt there are many (if any)
> implementations that can accomplish this with only data dictionary
> changes.  Having said that, what is the practical cost of assigning a
> different "top-level" ID for the Extended Attribute? 

Not sure; the rationale for making this a VSA is largely that VSA
formats are often non-standard (Cisco's, for example; I believe
Nortel's, as well, probably others) & therefore this (minor) change
would be localized in an area of code that changes fairly often anyway,
rather in the main line which I suspect changes much more rarely.    

Hope this helps,

~gwz

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