Re: RADIUS and complex attributes

[Bernard Aboba <aboba@internaut.com>]

> For many environments, there are very good reasons to prefer and move to
> standards.

VSAs were never intended for general purpose use, which is what I think
the problem is here.  But protocols such as SNMP can be used by SDOs to
create SDO-specific MIBs, and it does seem reasonable to enable SDOs to
create SDO-specific attributes.  So far, they have not done a good job of
this partly because they have chosen the VSA format suggested in RFC 2865
(how silly of them!) which only supports an 8 bit type code field.  But
perhaps with some help and guidelines from the IETF this situation might
be improved.

> Sticking with VSAs for widely need features is simply a mistake.

I'd agree for features that are not specific to a particular access
technology.  However, it's worth noting that Enterprise MIBs are very
widely implemented today;  many of the IEEE 802 MIBs fit in this category,
and interoperability has not been harmed by this.  In the long term it is
not reasonable to force all AAA work to go through the IETF since this
does not scale.  We need a mechanism akin to "MIB Doctors" for review,
"Enterprise MIBs" for legitimate extensions by SDOs (e.g. no new commands
or data types), and "Design guidelines" to provide advice on how to go
about it.


> Allow complex attributes.  Call them subtypes if you like

There is quite a difference between support of "complex attributes" and
"grouped AVPs" (e.g. sub-types).  The former typically requires a data
definition language, while the latter does not.  It is also worth noting
that the Diameter definition of "grouped AVPs" only allows one level of
grouping, so more than this cannot be allowed in RADIUS without breaking
DIAMETER/RADIUS compatibility.


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