Re: RADIUS and complex attributes

[Greg Weber <gdweber@cisco.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.

I think it would be very helpful to produce some more modern
recommendations on how to format/tag/concatenate/encrypt/etc VSAs
and when to pursue IETF space use vs. vendor (SDO) specific.
Perhaps this is worthy of charter work-item inclusion.

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

That is not my understanding based on Section 4.4 of RFC 3588:
  "It is possible to include an AVP with a Grouped 
   type within a Grouped type, that is, to nest them."

I thought they could be recursive; please correct me if I'm wrong.

Greg


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


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