RE: Issue: Vendor Specifc Attribute Values

[Ignacio Goyret <igoyret@lucent.com>]

>>   2882 uses Vendor-Specific Enumerations (VSE's).  We should use that
>> here.
>
>RFC 2882 is certainly a fact-based document.  It reports existing
>deployment behaviors.  Its abstract reads:
...
>
>IMHO, we should be careful about inferring any desired or implied level
>of standardization of any of the practices reported in 2882.  If there
>is no good reason to the contrary, then following existing convention
>may be a good thing.

>OTOH, the fact that one or more vendors chose to
>implement a needed (or desired) function in a particular fashion should
>not set a binding precedent on the RADEXT WG.  These extensions, in all
>likelihood, received no IETF review, or even third party review, prior
>to their implementation and deployment.  We should look at these "ad
>hoc" extensions with a critical eye.

May be we should note here that some of this vendor behavior was caused
by the attitude in the original RADIUS WG where any idea not implemented
by certain vendor (now defunct) were systematically rejected.

This (probably only apparent) inflexibility of the WG forced many vendors
to find their own way to solve attribute and value assignments, in many
cases, without much thought for multi-vendor interoperability.

That was then, this is now.

The method described in RFC2882 was used by one vendor and it works so long
as the bottom 16-bits of the vendor-id is not repeated, something that was
true then but it hasn't been for a long time. Ignoring this very serious
limitation means that multi-vendor interoperability cannot be guaranteed
nor implied. Please, let's not make that the rule.

My impression is that if assignment of new values was easier, the need for
VSEs would tend to disappear. As it stands, it is a process that takes a
good year at least.

Sorry, I somehow got derailed out of topic.


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