RE: QoS attributes

["Nelson, David" <dnelson@enterasys.com>]

Nagi writes...

> If the attribute space is not precious, then why is that the draft
dealing
> with LAN and WLAN specific attributes are not standardized. I think
the
> reason is VSA provide subtypes and this draft wants to introduce
handful
> of attributes which we don't have space.  Right?

The attribute space is certainly finite.  My perception is that RADIUS
has a finite lifetime (remember we do have Diameter) and that the "good
ideas" for standard attributes will run out before the attribute space
runs out. The limited address space is a secondary, consideration, IMHO.
Of course, future events may prove me wrong.

So why are some proposals "good ideas" and some not?  Well, items that
have broad Internet Community consensus should be standardized.  Items
that are special "tweaks" that allow one vendor to differentiate itself
from the competition (in non interoperable ways) are what the VSA
attribute is for.  In between those extremes, we have the gray areas,
i.e. proposals that are of interest to a specific industry or market
segment or are of interest to a specific vendor.

It an attribute "passes muster" for broad Internet Community consensus
and multi-vendor interoperability it deserves to be a stand-alone,
standardized attribute.  If it does not pass that muster, it should be a
VSA.  Trying to "have it both ways" and bury multiple attributes in one
standard attribute, via sub-types, sub-fields, or whatever, is simply a
disservice to the RADIUS community, IMHO.

Allowing "bad ideas" to be standardized places an extra burden on the
implementers of RADIUS Clients, Servers and Proxies, who will be
pressured to support the new attributes.  That's why the RADUIS IANA
considerations talks about the requirement for IETF Standards Action.

Let's come to consensus on the list of attributes that "pass muster",
and then we can take a head-count to see if the attribute address space
is in imminent risk of exhaustion.
 
-- Dave

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