RE: QoS attributes

[<john.loughney@nokia.com>]

Hi all,

My 2 cents are as follows: RADext/AAAext (or whatever) shouldn't define QoS signaling, 
NSIS is already doing that:

http://www.ietf.org/html.charters/nsis-charter.html

There has been some discussion on AAA issues for QoS:

http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-00.txt

Looking into QoS issues, my feeling is that we want to specify QoS classes.
These classes may support a set of QoS parameters.  I think that QoS
will be an area that vendors try to differentiate on; service providers
may create services that support different QoS parameters, etc.  I don't
think that we can get into the QoS signaling / provisioning / definition
of QoS parameters, as that excedes the scope of AAA (either RADIUS or
Diameter).  I would prefer that RADIUS / Diameter would contain a 
QoS class parameter, which could make use something like a IANA QoS
class registry. 

Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
defined seperate QOS classes.  One could imagine registering these classes
in IANA, and service providers could support, in various degrees, different
QoS classes.  It would then be in scope of AAA to provide authorization for
these classes.

John

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