RE: Issue with Guidelines document

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Bernard Aboba writes...

> It would be good for the Extended Attributes draft to clear this up
> (I've filed on issue on this).  However, a number of existing
> Documents (including RFC 2866 and RFC 5176) make statements about
> the allowable uses of Attribute 26.  Since Extended Attribute
> use Attribute 26, those statements will by default apply.

Well... yes.  That's a logical inference.  I wonder, however, if it's the
inference that we desire.  I think if we fail to separate the restrictions
of the "classic" VSA from the intended use model of the Extended Attributes,
we will have failed in some significant way.  Yes, the Extended Attributes
"overload" the use of the VSA type code, but IMHO they are not VSAs, as we
know them.  Another way of saying this is that all the current references to
type code 26 and/or VSA in the RFCs are in the context of "classic" VSAs,
i.e. "proprietary secret sauce" attributes.

Is it possible to make a meaningful and logical distinction between Extended
Attribute and Vendor Specific Attribute?  If not, I think that the utility
of Extended Attributes will be substantially lessened.



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