Skip to main content

Quality of Service Parameters for Usage with Diameter
RFC 5624

Revision differences

Document history

Date Rev. By Action
2018-12-20
11 (System)
Received changes through RFC Editor sync (changed abstract to 'This document defines a number of Quality of Service (QoS) parameters that can be reused for …
Received changes through RFC Editor sync (changed abstract to 'This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.

The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]')
2016-11-30
11 (System) Closed request for Last Call review by SECDIR with state 'Unknown'
2015-10-14
11 (System) Notify list changed from dime-chairs@ietf.org, draft-ietf-dime-qos-parameters@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2009-08-21
11 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-08-21
11 Amy Vezza [Note]: 'RFC 5624' added by Amy Vezza
2009-08-20
11 (System) RFC published
2009-07-27
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-07-27
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-07-27
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-06-02
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-06-01
11 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-06-01
11 (System) IANA Action state changed to In Progress
2009-06-01
11 Cindy Morgan IESG state changed to Approved-announcement sent
2009-06-01
11 Cindy Morgan IESG has approved the document
2009-06-01
11 Cindy Morgan Closed "Approve" ballot
2009-05-25
11 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-05-25
11 (System) New version available: draft-ietf-dime-qos-parameters-11.txt
2009-04-16
11 Adrian Farrel
[Ballot discuss]
Picking up from Dave Ward's Discuss, I would like to see answers to the following points.

---

I agree with you that there …
[Ballot discuss]
Picking up from Dave Ward's Discuss, I would like to see answers to the following points.

---

I agree with you that there are no requirements expressed for expressing percentage values. You might reasonbaly answer that if someone needs a percentage, they can come along later and define a new AVP in another document.

But where are the requirements expressed for expressing *any* QoS parameters in Diameter? It would really help if you were able to  reference such a document or include a statement about *why* you are making this particular set of QoS parameters available for inclusion in Diameter.

---

While you have given a high-level description of what the TMODs are for, you haven't given any indication of what the Bandwidth might be for.

Since the TMODs are to describe traffic sources, is Bandwidth to describe traffic flows?

---

> This draft defines the parameters and there is a separate document
> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-1
> 1.txt) that discusses the usage of the QoS parameters in context of
> Diameter AVP, without going too much into details on what the AAA
> server could do with each parameter. There are typically many
> options, such as logging, accounting, authorization, statistical
> analysis, charging, etc. Btw, more information regarding
> the priority element is provided in RFC 3181.

It would certainly have been helpful to qualify the Abstract/introduction when it says:
    This document defines a number of Quality of Service (QoS)
    parameters that can be reused for conveying QoS information
    within Diameter.
Including some text such as your paragraph above, and by including the
reference to dime-qos-attributes you could make the purpose of the
document much clearer.

But...
You are trying to define some general-purpose QoS parameters that might be useful in some applications of Diameter. You want to define these without reference to the application, but that may mean that you are defining the wrong parameters or getting their encoding slightly wrong. How do we know?

Where you are able to cite other definitions for the encodings (and semantics) you are giving a strong hint to the potential applicability. Where you are not (e.g. or perhaps i.e., Bandwidth AVP) the reader is left floundering.

Is this something that could be done with a minor mod, or can you argue that it is not necessary?
2009-04-16
11 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes by Adrian Farrel
2009-04-16
11 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel
2009-03-12
11 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2009-03-11
11 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2009-03-09
10 (System) New version available: draft-ietf-dime-qos-parameters-10.txt
2009-02-27
11 (System) Removed from agenda for telechat - 2009-02-26
2009-02-26
11 Amy Vezza State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup by Amy Vezza
2009-02-26
11 David Ward
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior.

I don't understand why the …
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior.

I don't understand why the policer is defined in absolute bandwidth in this draft and doesn't include percentage. If the bw is to describe the actual traffic stream from the source, then absolute value should be sufficient.  If it is used to define a QoS policy for some aggregate traffic, then % can be useful.  Along with %, we also need the reference bandwidth.  The % could be based on a physical port bw or a logical session (with some max rate) in the same box., so a distinction on the reference target needs to be made.

Also on the usage of Bandwidth AVP, is it merely a different unit of measurement from the Rate parameter in the TMOD AVP ? It would be good to clarify.

For the Priority AVP, is it to be used with RSVP for on-path CAC or for local CAC decision or something else?  It would be good to provide some background information in the draft.
2009-02-26
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-02-26
11 David Ward
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior. I don't understand why the …
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior. I don't understand why the policer is defined in absolute bandwidth in this draft and doesn't include percentage. Also on the usage of Bandwidth AVP, is it merely a different unit of measurement from the Rate parameter in the TMOD AVP ? It would be good to clarify.

For the Priority AVP, is it to be used with RSVP for on-path CAC or for local CAC decision or something else?  It would be good to provide some background information in the draft.
2009-02-26
11 David Ward
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior. I don't understand why the …
[Ballot discuss]
Fundamentally this seems to be an interface for configuring a 2 rate 3-color marker and other QoS behavior. I don't understand why the policer is defined in absolute bandwidth in this draft and doesn't include percentage.
2009-02-26
11 David Ward [Ballot Position Update] New position, Discuss, has been recorded by David Ward
2009-02-26
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-02-26
11 Pasi Eronen
[Ballot discuss]
The text about QoS Profile IDs (in last paragraph of Section 4 and
Section 5.2) doesn't make sense as is. The intent probably …
[Ballot discuss]
The text about QoS Profile IDs (in last paragraph of Section 4 and
Section 5.2) doesn't make sense as is. The intent probably is that the
first four octets are an IANA-assigned Enterprise Number, and for the
latter four octets, IANA maintains a registry for Enterprise Number 0
(but for other Enterprise Numbers, it's up to the owner how they're
used).

But that's not quite what the text currently says (in 4.2, the
sentence "If the four octets.." does not parse, and in 5.2, it
suddenty starts talking about OIDs ).

Also, what's the IANA assignment policy for numbers 4096..4294967295?
2009-02-26
11 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-02-26
11 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-02-25
11 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-02-25
11 Chris Newman
[Ballot discuss]
This document has the following flaws:

1. It names the "Diameter" protocol without providing a reference to
the protocol specification.

2. This uses …
[Ballot discuss]
This document has the following flaws:

1. It names the "Diameter" protocol without providing a reference to
the protocol specification.

2. This uses a formal grammar to define protocol elements without
providing a reference to the definition of the formal grammar.

I believe both problems are resolved by adding the missing normative
reference to the Diameter base specification.
2009-02-25
11 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2009-02-25
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2009-02-25
11 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-02-25
11 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-02-24
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-02-24
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-02-23
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-02-19
11 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-02-17
11 Dan Romascanu Placed on agenda for telechat - 2009-02-26 by Dan Romascanu
2009-02-17
11 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2009-02-17
11 Dan Romascanu Ballot has been issued by Dan Romascanu
2009-02-17
11 Dan Romascanu Created "Approve" ballot
2009-01-22
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-01-22
09 (System) New version available: draft-ietf-dime-qos-parameters-09.txt
2009-01-22
11 Dan Romascanu State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup by Dan Romascanu
2008-12-18
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-12-18
08 (System) New version available: draft-ietf-dime-qos-parameters-08.txt
2008-11-24
11 Dan Romascanu State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Dan Romascanu
2008-11-17
11 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-13
11 Amanda Baber
IANA Last Call comments:

IANA has questions:

- In Action 1, the specifier field is declared as four (4) octets,
but the registry only specifies …
IANA Last Call comments:

IANA has questions:

- In Action 1, the specifier field is declared as four (4) octets,
but the registry only specifies values 0-4095. What about the
rest of the values?

- In Action 2, the parameter table in the IANA Considerations section
does not match the numbers described in Sections 4.2 through 4.15.
Which is correct?


Action 1:

Upon approval of this document, the IANA will create the registry
"QoS Profile" at http://www.iana.org/assignments/TBD

Registration Procedures:

QoS Profile Registration Procedure
----------- ----------------------
0-511 Standards Action
512-4095 Specification Required

Initial contents of this registry will be:


QoS Profile Description Reference
----------- --------------- ----------
0 AAA Framework [RFC-dime-qos-parameters-07]
1-511 Available for Assignment [RFC-dime-qos-parameters-07]
512-4095 Available for Assignment [RFC-dime-qos-parameters-07]


Action 2:

Upon approval of this document, the IANA will create the registry
"Parameter ID" located at http://www.iana.org/assignments/TBD

The allocation policies for further values are as follows:
0-127: Standards Action
128-255: Private/Experimental Use
255-4095: Specification Required

Initial contents of this registry will be:

ID Description Reference
--- ------------ --------------
0 TMOD-1 [RFC-dime-qos-parameters-07]
1 TMOD-2 [RFC-dime-qos-parameters-07]
2 Path Latency [RFC-dime-qos-parameters-07]
3 Path Jitter [RFC-dime-qos-parameters-07]
4 Path PLR [RFC-dime-qos-parameters-07]
5 Path PER [RFC-dime-qos-parameters-07]
6 Slack Term [RFC-dime-qos-parameters-07]
7 Preemption Priority & Defending Priority [RFC-dime-qos-parameters-07]
8 Admission Priority [RFC-dime-qos-parameters-07]
9 ALRP [RFC-dime-qos-parameters-07]
10 Excess Treatment [RFC-dime-qos-parameters-07]
11 PHB Class [RFC-dime-qos-parameters-07]
12 DSTE Class Type [RFC-dime-qos-parameters-07]
13 Y.1541 QoS Class [RFC-dime-qos-parameters-07]


Action 3:

Upon approval of this document, the IANA will create the registry
"Excess Treatment Parameter" at http://www.iana.org/assignments/TBD

The 8 bit Remark Value allocation policies are as follows:
0-63: Specification Required
64-127: Private/Experimental Use
128-255: Reserved

Initial contents of this registry will be:

Value Description Reference
----- --------------- -------------
0 drop [RFC-dime-qos-parameters-07]
1 shape [RFC-dime-qos-parameters-07]
2 remark [RFC-dime-qos-parameters-07]
3 no metering or policing is permitted [RFC-dime-qos-parameters-07]
4-63 Available for Assignment [RFC-dime-qos-parameters-07]
64-127 Private/Experimental Use [RFC-dime-qos-parameters-07]
128-255 Reserved [RFC-dime-qos-parameters-07]


We understand the above to be the only IANA Actions for this
document.
2008-11-11
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2008-11-11
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2008-11-03
11 Amy Vezza Last call sent
2008-11-03
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-11-03
11 Dan Romascanu State Changes to Last Call Requested from Publication Requested::AD Followup by Dan Romascanu
2008-11-03
11 Dan Romascanu Last Call was requested by Dan Romascanu
2008-11-03
11 (System) Ballot writeup text was added
2008-11-03
11 (System) Last call text was added
2008-11-03
11 (System) Ballot approval text was added
2008-11-03
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-11-03
07 (System) New version available: draft-ietf-dime-qos-parameters-07.txt
2008-08-28
11 Dan Romascanu
AD Review by Dan Romascanu:

This is the AD review of dime-qos-parameters-06.txt. I believe that the document needs more work before it can be sent …
AD Review by Dan Romascanu:

This is the AD review of dime-qos-parameters-06.txt. I believe that the document needs more work before it can be sent to IETF Last Call. I am placing it in Revised ID Needed.

1. Although it is the work of the DIME Working Group, the document includes in its scope according to the Introduction section the
definition of parameters    that can be reused for conveying QoS
information within RADIUS and Diameter. I believe that there is a need to add text that shows how specifically these parameters will be used in each of the two protocols. Is there a need for any supplementary documents to describe protocol specific mapping and IANA allocations?

2. Was the document reviewed by the RADIUS WG?

3. This document will trigger again the issue of exceeding the AAA scope of DIAMETER as described by RFC 3588, raised in a number of previous occasions, last by Brian Carpenter in his GenART review for draft-sun-dime-itu-t-rw. I suggest to put text in the Introduction section mentioning the issue of scope and referring to rfc3588bis as an Informational Reference.

4. There are several places in the document where the authors seem to write requirements about the behavior and mode of provisioning of a QoS enabled network. I do not think that an AAA parameters document is a good place for such requirements. I would strongly prefer that the document focuses on describing the QoS parameters carried by AAA protocols, and if examples of usage are left, they be marked clearly as examples. 

5. Section 3.2 - Path PLR and Path PER are defined on packet basis, so the claim that they describe the desired bit error rate seems odd.

6. Same -'where the PLR is defined to be the PLR added by each such node' and 'the PER is defined to be the PER added by each such node'
seem to be broken as definitions - maybe that was intended to be define is 'the Path PLR' and 'the Path PER' respectively.

7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords usage seems unjustified here.

8. Section 4.1 and following - it would be good to mention that Length all over this document is expressed in 32-bit words.

9. It is not clear why there is a need to defined both TMOD-1 and TMOD-2. I suggest to add an explanation.

10. Section 4.2 - I suggest to add a normative reference to IEEE 754 when referring the first time to single-precision IEEE floating point format. It's a good moment, as the IEEE standard was updated in June 2008, after more than two decades of usage of the precedent version (but this does not affect the way it is used here as far as I can tell)

11. The first phrase in 4.3 should appear also in 4.2 as the two TMOD parameters have similar semantics.

12. Section 4.5 - there is no reference for the semantic of the Path Jitter parameter value - probably section 3.4 in RFC2215

13. I do not understand what is the reason to include Path Jitter STAT4 (Reserved).

14. Section 4.6 - I do not believe that a AAA document should include statements like 'The total PLR added across all QoS aware nodes can range as high as 10^-1.'

15. Section 4.7 - in the first phrase s/PLR/PER/

16. Section 4.7 - I do not believe that a AAA document should include statements like 'The total PER added across all QoS aware nodes can range as high as 10^-1.'

17. Section 4.8 - I see no reason to refer here to [RFC2212]

18. Section 4.8 - s/Path PLR/Slack Term/

19. Section 4.11 - I am not sure that quoting RFC4412 as a reference for the semantic of the parameter value is fully accurate. It may be good at most to say that what is referred here is the resource-priority policy element

20. Section 4.11 - This I-D defines similarly ALRP parameter as draft-ietf-tswg-emergency-rsvp and the two documents quote each other with the apparent intent to keep the definitions in sync. However draft-ietf-tswg-emergency-rsvp defines a policy object which is a list of ALRPs, while here there is only one instance. Why the difference?

21. Section 4.11 - if the intent is to keep the definitions here and in draft-ietf-tswg-emergency-rsvp as close as possible what are the ALRP Priority and Reserved octets positions inversed in the two definitions?

22. Section 4.12 should have a reference to the IANA registry required to be defined for this parameter in Section 6.3.

23.  Section 4.12 - what is 'the QoS Desired' object defined here?

24. Section 4.12 includes text about the behavior of the network that looks mis-placed in an AAA document.

25. Section 4.13 could use a reorganization of the description. The 16-bits in the payload have different structure according to the PHB class type - they would better get one generic name and specific descriptions for the three cases covered by the object.

26. Section 4.14 - the semantic described in this section is not identical with the one in RFC 4124 which is provided as reference. 4124 says 0 is a reserved value - what semantics does it have here? It is also not clear why this parameter was defined to have an 8-bit representation

27. Section 4.15 - I strongly advice against presenting the usages of the QoS Class parameters here especially in such firm terms as here.
Actually ITU-T Y.1541 Tables 2 and 3 make clear that these class usages are only guidance (classes 1 to 5) and provisional (classes 6,7). This is completely lost here. I would prefer to just provide a pointer to the ITU-T document and take out all the classes descriptions, or move them in an Appendix, with all necessary description of their guidance and provisional status.

28. Section 5 should provide a reference to the IANA registry for Enterprise Numbers

29. Section 6.4 - It is not clear why there is a need to create a registry for DSTE Class Type Parameters. If IETF WGs or individuals writing RFCs and running them through the IETF process will be allowed to add or modify values by Standards Actions, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters.

30. Section 6.5 -  It is not clear why there is a need to create a registry for Y.1541 Class Parameters. Who would take the responsibility of running the Standard Action to modify or add Object class values? In what conditions? When Y.1541 changes? In any case, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters.

31. Section 7 - I disagree that this document does not raise any security concerns. Actually the modification or mis-configuration of the QoS parameters carries security threats similar with the configuration operations that would be performed for example in case the objects would be configured by using a protocol like SNMP. QoS degradation may lead to degradation of service that can make access to the network resources difficult or impossible, or running real-time applications impossible.
We need text that explains what are the sensitive parameters, and the recommended operational and deployment measures to protect against security threats.

32. The description of the [Y.1541] and [Y/1571] references are incomplete.
2008-08-28
11 Dan Romascanu State Changes to Publication Requested::Revised ID Needed from Publication Requested by Dan Romascanu
2008-07-03
11 Dan Romascanu Responsible AD has been changed to Dan Romascanu from Jari Arkko
2008-06-26
11 Amy Vezza
PROTO WRITEUP for draft-ietf-dime-qos-parameters-06.txt
=======================================================


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally …
PROTO WRITEUP for draft-ietf-dime-qos-parameters-06.txt
=======================================================


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?


      Document Shepherd is David Frascone <dave@frascone.com>.
      The document is ready for publications and I have reviewed the
      document personally.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

      This document is part of the work on extending the
      QoSFilterRule AVP functionality of the Diameter Base protocol
      and the functionality of the QoS-Filter-Rule AVP defined in
      RFC 4005.

      The encoding of the attributes is provided in a way to be used
      for a AAA protocol independent Resource Management Function.

      The WGLC was started 2 Oct 2007:
      http://www.ietf.org/mail-archive/web/dime/current/msg02062.html

      The WGLC was sent to NSIS, RADEXT and TSVWG where inconsistencies
      between registries were discovered that lead to the delay of the
      document. The changes are reflected in the subsequent versions
      and were discussed on the mailing list as well as during the
      DIME IETF meetings.

http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-parameters/draft-ietf-dime-qos-parameters-02-from-01.diff.html

http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-parameters/draft-ietf-dime-qos-parameters-03-from-02.diff.html

http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-parameters/draft-ietf-dime-qos-parameters-04-from-03.diff.html


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?
         
      There are no concerns with the document.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

      There are no concerns.
     
  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
         
      There is consensus behind this document.
     


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
         
      No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

      The document does not contain nits.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].


    The document has references split into normative and
    informative references. The document contains references to
    two ITU-T documents:


    [Y.1541]  "Network Performance Objectives for IP-Based Services",
                2006.

    [Y.1571]  "Admission Control Priority Levels in Next Generation
                Networks", July 2006. 


   
  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

  An IANA consideration section exists and is consistent with the rest
  of the document.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  The document does not contain formal languages.
 
 
  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.


Document Announcement Write-Up for "Quality of Service Parameters for
Usage with the AAA Framework" (draft-ietf-dime-qos-parameters-06.txt)

  Technical Summary

  This document defines a number of Quality of Service (QoS) parameters
  that can be reused for conveying QoS information within RADIUS and
  Diameter.

  The payloads used to carry these QoS parameters are opaque for the
  AAA client and the AAA server itself and interpreted by the
  respective Resource Management Function.


  Working Group Summary

      There is consensus in the WG to publish this document.

  Document Quality

      The document has been sent for review to DIME, NSIS, TSVWG and
      RADEXT. This document is part of the solution for extending the
      QoSFilterRule AVP functionality of the Diameter Base protocol
      and the functionality of the QoS-Filter-Rule AVP defined in
      RFC 4005.

     
  Personnel

    David Frascone is the document shepherd for this document.
2008-06-26
11 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2008-05-26
06 (System) New version available: draft-ietf-dime-qos-parameters-06.txt
2008-05-26
05 (System) New version available: draft-ietf-dime-qos-parameters-05.txt
2008-05-26
04 (System) New version available: draft-ietf-dime-qos-parameters-04.txt
2008-02-25
03 (System) New version available: draft-ietf-dime-qos-parameters-03.txt
2008-02-25
02 (System) New version available: draft-ietf-dime-qos-parameters-02.txt
2007-09-29
01 (System) New version available: draft-ietf-dime-qos-parameters-01.txt
2007-06-11
00 (System) New version available: draft-ietf-dime-qos-parameters-00.txt