RE: Extending RADIUS Attribute Space

[Bernard Aboba <aboba@internaut.com>]

> > A) As a minimum, create a mechanism to create more RADIUS
> > attribute types in a way that is backwards compatible with
> > existing RADIUS.
>
> why?  i.e. which of the two critical target applications asked for
> that, why, and can it be done with less change to existing
> protocol?

There might be an argument that pressure on the attribute space has so far
been relieved only because VSAs have been used for the majority of new
applications.  If use of standard attributes were to be encouraged, then
conceivably the rate of attribute exhaustion would greater than it is
today.  However, that's more of an argument for a future issue than an
argument for why attribute space expansion is needed to allow an existing
draft to go forward (which is the argument that is being made).

> who?  which of the two critical target applications?  note that the
> set of "someone asked for that" is often not numerable and does not
> tend to shrink over time.

So far, the only example that has been put forward is the Cable Lab spec,
which apparently solved the problem without extending the length.  Based
on that, a standard way of concatenating the existing attributes seems to
make sense, but it's hard to see why anything beyond that is required.

> > C) Optionally address the issue of how to extend a message again
> > using EAP.
>
> again, which of the two critical target applications asked for
> that, why, and can it be done with less change to existing
> protocol?

Certainly, EAP users have never asked for this -- and would probably be
horrified at the thought, since it would break interoperability.

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