RE: Glen's proposal for Attribute Extension

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...

> OK. probably "minimal code changes" would be more accurate
> than "no code changes.

Yes.

> The formats of VSAs must be well defined, even if not standard.

Yes, each instance is well defined, but often highly varied.

> Well, I think that it would be as clear as we wanted to make it.
> If we publish an RFC that has "MUST" surrounding the formats,
> that seems pretty clear to me.

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.

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


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