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 |