Re: Strawman RADIUSEXT WG charter - Take Three

[Bernard Aboba <aboba@internaut.com>]

> As a practical matter, server vendors have to update code regularly anyway
> because of new VSA implementations.  I think the question here is really
> whether we should simply accept new types, and possible reduce the pressure
> on new VSAs (but, as Bernard has noted in another posting, increasing the
> pressure on the "standard" attributes) or just stay with VSAs as a way of
> accommodating the need for new types.
>
> Personally, I'd vote to leave it as-is and stick with the well known, and
> imperfect VSA route.

The issue with VSAs is that they tend to be un or under-documented, which
creates problems in implementation or even in maintaining compatibility
with Diameter.

Also, multiple VSAs are sometimes produced to handle the same function in
slightly different ways, which impacts interoperability.

Here's what RFC 2865, Section 6.2 says about VSAs:

   Note that RADIUS defines a mechanism for Vendor-Specific extensions
   (Attribute 26) and the use of that should be encouraged instead of
   allocation of global attribute types, for functions specific only to
   one vendor's implementation of RADIUS, where no interoperability is
   deemed useful.

The problem is that VSAs are used today even where interoperability is
required (as in SDO specifications).  The result is that those
specifications may not obtain adequate review.

So perhaps the best argument for attribute expansion (and perhaps even
the existence of a RADIUSEXT WG) is that it would make it more likely that
the review process envisaged in RFC 2865 will actually take place.

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