Diameter Priority Attribute-Value Pairs
draft-ietf-dime-priority-avps-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-07-18
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-07-18
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-07-16
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-07-13
|
06 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-07-12
|
06 | (System) | IANA Action state changed to In Progress |
2012-07-12
|
06 | Cindy Morgan | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-07-12
|
06 | Cindy Morgan | IESG has approved the document |
2012-07-12
|
06 | Cindy Morgan | Closed "Approve" ballot |
2012-07-12
|
06 | Cindy Morgan | Ballot approval text was generated |
2012-07-12
|
06 | Cindy Morgan | Ballot writeup was changed |
2012-07-12
|
06 | Benoît Claise | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-07-12
|
06 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
2012-06-29
|
06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-06-28
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-06-28
|
06 | Cindy Morgan | New version available: draft-ietf-dime-priority-avps-06.txt |
2012-05-08
|
05 | Benoît Claise | Ballot writeup was changed |
2012-03-29
|
05 | Benoît Claise | Responsible AD changed to Benoit Claise from Dan Romascanu |
2012-03-29
|
05 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2012-01-12
|
05 | Jean Mahoney | Request for Telechat review by GENART Completed. Reviewer: Joel Halpern. |
2012-01-12
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2012-01-12
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2011-12-04
|
05 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Steve Hanna. |
2011-12-01
|
05 | Cindy Morgan | Removed from agenda for telechat |
2011-12-01
|
05 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-12-01
|
05 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-01
|
05 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-01
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
05 | David Harrington | [Ballot comment] 1) I agree with other comments about the confusion surrouding integrity-protected values. 2) The second paragraph of section 5 says "Use .. MUST … [Ballot comment] 1) I agree with other comments about the confusion surrouding integrity-protected values. 2) The second paragraph of section 5 says "Use .. MUST take into consideration ..." I think this is an incorrect usage for MUST; MUST is for implementers. (Since an operator might choose to NOT consider the issues and security of Diameter base, this document should warn users what vulnerabilities might exist in their network if another operator ignores these issues.) 3) In acknowledgements, you credit a number of people with resolving the "problems", but don't mention what problems those were. |
2011-11-30
|
05 | David Harrington | [Ballot discuss] 1) The Introduction says "The influence attributed to prioritization may also affect QoS, but it is not to be confused with QoS." … [Ballot discuss] 1) The Introduction says "The influence attributed to prioritization may also affect QoS, but it is not to be confused with QoS." but section 4 records this in the IANA QoS Profile registry, and section 5 says this documents describes an extension for conveying QoS information. Doesn't this confuse prioritization with QoS? 2) I am unclear on the relation between 3GPP-defined AVPs and the AVPs defined here. The last paragraph of 1.1 says the 3GPP work is not relevant to the current document; then why mention it? I think it is relevant in that it impacts prioritization, but the 3GPP prioritization is limited to within a walled garden. You don't say so, but I assume this means the AVPs defined in this document do NOT operate in a walled garden. Do the ETSI AVPs also operate in a walled garden? I suggest that this should be made clearer by specifying more clearly the intended scope of the ETSI, 3GPP, and IETF AVPs. 3) I think an important missing element here is the impact these different scopes have on operational considerations. What does an operator need to know about the prioritization caused by these AVPs from different SDOs, and how do they interact if multiple types of prioritization is present? Which ones take precedence, assuming comparable values of prioritization? 4) The 3GPP is supposed to be for use in a walled garden; what happens if it "escapes into the wild"? Is there anything an operator can/should do to make sure this doesn't happen, such as configuring a firewall to prevent the AVPs from crossing network boundaries? 5) prioritization might affect QoS. What sort of operational impact might this have, if some traffic prioritized by, for example, a diffserv codepoint is overridden by an AVP? Are there certain types of traffic that operators should make sure AVPs do not override the protocol-defined QoS? 6) What is the persistence of these AVP settings? Do these AVPs only affect the current session, and the AVP-driven prioritization is removed when the authorized session ends, or does the AVP-driven prioritization continue after the current session closes? 7) in 3.1, passive vocie is used to state "Defending-priority is set when the reservation has been admitted." That is a bit ambiguous to me. Do I understand correctly that the defending-priority AVP is **set** by the client in the request message before admission, but the prioritization is only **set** by the NAS in its internal enforcement calculations when the session is admitted? Can the text clarify who the actors are, and when and what each of them sets? 8) in 3.1.1, "value that would be encoded in the signaled ... element." encoded in what message? where is this policy element encoded? Can you provide a reference? 9) in 3.2, "The admission priority of the flow is used to increase the probability of session establishment for selected flows." I don't understand the relationship between "the flow" and "selected flows", and the relationship between these flows and AAA sessions. Is "the flow" the AAA-authorized session flow? Are the "selected flows" in the same authorized session? or does this AVP afffect flows in other AAA-sessions? Is the admission priority of the flow refering to the admission-prioirty-AVP, or the admission-priority parameter that the AVP models? |
2011-11-30
|
05 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
2011-11-30
|
05 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
05 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-30
|
05 | Robert Sparks | [Ballot discuss] The first paragraph of the Security Considerations section is unclear. It appears to instruct elements (not clear which elements) to ignore integrity protected … [Ballot discuss] The first paragraph of the Security Considerations section is unclear. It appears to instruct elements (not clear which elements) to ignore integrity protected values. Does it mean integrity protected values that fail integrity check? It indicates that protocol specific error messages should be sent when these values are ignored - which protocol(s)? Is the paragraph trying to say something more than "local policy can override the policy requested by protocol messages"? |
2011-11-30
|
05 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded |
2011-11-29
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
05 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-29
|
05 | Sean Turner | [Ballot comment] s3.4 includes the following: Consequently, SIP-Resource-Priority and Application-Level-Resource-Priority AVPs convey the same priority semantics, but with differing syntax. Should guidance … [Ballot comment] s3.4 includes the following: Consequently, SIP-Resource-Priority and Application-Level-Resource-Priority AVPs convey the same priority semantics, but with differing syntax. Should guidance be given about what happens when the two conflict (i.e., where high =11, one says high and the other says 10)? Also should some guidance be given as to when to use one or the other? |
2011-11-29
|
05 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-27
|
05 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-17
|
05 | Joel Halpern | Request for Telechat review by GENART Completed. Reviewer: Joel Halpern. |
2011-11-17
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2011-11-17
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2011-11-11
|
05 | Stephen Farrell | [Ballot comment] - The document assumes I already know what a "priority parameter" is, I don't, and that's a problem for the reader. I think … [Ballot comment] - The document assumes I already know what a "priority parameter" is, I don't, and that's a problem for the reader. I think at least a reference to where this is defined would be good. If there's no single definition then just explaining why a bunch of new AVPs are needed would be fine. - is the title of 3.3.1 correct? The other sections are named for the AVP but this isn't. Maybe a typo? The AVP in 4.1 matches the section title but not the AVP name in the body of 3.3.1. 3.4.2 seems to have the same problem. |
2011-11-11
|
05 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-11-08
|
05 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Steve Hanna |
2011-11-08
|
05 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Steve Hanna |
2011-11-06
|
05 | Dan Romascanu | Placed on agenda for telechat - 2011-12-01 |
2011-11-06
|
05 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2011-11-06
|
05 | Dan Romascanu | Ballot has been issued |
2011-11-06
|
05 | Dan Romascanu | Created "Approve" ballot |
2011-11-06
|
05 | Dan Romascanu | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
2011-10-31
|
05 | (System) | Sub state has been changed to AD Follow up from New ID Needed |
2011-10-31
|
05 | (System) | New version available: draft-ietf-dime-priority-avps-05.txt |
2011-08-03
|
05 | David Harrington | Request for Last Call review by TSVDIR is assigned to Gorry Fairhurst |
2011-08-03
|
05 | David Harrington | Request for Last Call review by TSVDIR is assigned to Gorry Fairhurst |
2011-08-03
|
05 | David Harrington | Request for Last Call review by TSVDIR is assigned to James Polk |
2011-08-03
|
05 | David Harrington | Request for Last Call review by TSVDIR is assigned to James Polk |
2011-08-03
|
05 | Dan Romascanu | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
2011-08-03
|
05 | Dan Romascanu | New revision required to solve the Last Call comments - specifically from SecDir review |
2011-08-01
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Steve Hanna. |
2011-07-20
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-07-19
|
05 | Amanda Baber | IANA understands that, upon approval of this document, there are two IANA actions which need to be completed. First, in the AVP Codes registry located … IANA understands that, upon approval of this document, there are two IANA actions which need to be completed. First, in the AVP Codes registry located in the Authentication, Authorization, and Accounting (AAA) Parameters registry located at: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-1 a series of new registrations will be made as follows: AVP Code Attribute Name Reference ========= ====================================== ============= tbd1 Dual-Priority [ RFC-to-be ] tbd2 Preemption-Priority [ RFC-to-be ] tbd3 Defending-Priority [ RFC-to-be ] tbd4 Admission-Priority [ RFC-to-be ] tbd5 SIP-Resource-Priority [ RFC-to-be ] tbd6 SIP-Namespace [ RFC-to-be ] tbd7 SIP-Value [ RFC-to-be ] tbd8 Application-Level-Resource-Priority [ RFC-to-be ] tbd9 ALRP-Namespace [ RFC-to-be ] tbd10 ALRP-Value [ RFC-to-be ] Second, First, in the QoS Profiles registry located in the Authentication, Authorization, and Accounting (AAA) Parameters registry located at: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-1 a new QoS profile will be registered as follows: Value: tbd11 Name: Resource priority parameters Reference: [ RFC-to-be ] IANA understands that these two actions are the only ones required upon approval of this document. |
2011-07-09
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2011-07-09
|
05 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2011-07-06
|
05 | Cindy Morgan | Last call sent |
2011-07-06
|
05 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Diameter Priority Attribute Value Pairs) to Proposed Standard The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Priority Attribute Value Pairs' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-priority-avps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-priority-avps/ No IPR declarations have been submitted directly on this I-D. |
2011-07-06
|
05 | Dan Romascanu | Last Call was requested |
2011-07-06
|
05 | Dan Romascanu | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2011-07-06
|
05 | Dan Romascanu | Last Call text changed |
2011-07-06
|
05 | (System) | Ballot writeup text was added |
2011-07-06
|
05 | (System) | Last call text was added |
2011-07-05
|
05 | (System) | Sub state has been changed to AD Follow up from New ID Needed |
2011-07-05
|
04 | (System) | New version available: draft-ietf-dime-priority-avps-04.txt |
2011-06-15
|
05 | Jouni Korhonen | Submitted to IESG a while ago. |
2011-06-15
|
05 | Jouni Korhonen | IETF state changed to Submitted to IESG for Publication from WG Document |
2011-06-01
|
05 | Dan Romascanu | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-05-16
|
05 | Dan Romascanu | State changed to AD Evaluation from Publication Requested. |
2011-03-31
|
05 | Cindy Morgan | (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 … (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? -- Lionel Morand (lionel.morand@orange-ftgroup.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. (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? -- The document has had an extensive review by the DIME WG. This document has been also reviewed and discussed by people from 3GPP. The lastest version is the result of the consensus reached after discussion. The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. (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? -- No. (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. -- No. (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 Dime WG consensus behind the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 the Internet-Drafts Checklist 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? -- The shepherd has checked the document with the idnits tool and found no critical issues. However several lines exceed the maximum length of 72 characters. The document does not need MIB doctor review. The document does not contain any media and URI types. (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]. -- References are split accordingly. There is a normative reference to a draft (draft-ietf-tsvwg-emergency-rsvp-14) but this draft is already in the RFC ed queue. There are no other references to documents with unclear status or are in progress. (1.i) Has the Document Shepherd verified that the document IANA consideration 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 [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? -- This document defines 10 new Diameter AVP codes and requests IANA for code value assignment in an existing registry. This document defines several new Diameter AVPs. IANA is requested to allocate values for the AVP codes. No new registry is defined.. (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? -- Yes. Note that the ABNF used in this document follows the modified ABNF syntax defined in RFC3588. (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. The approval announcement contains the following sections: Technical Summary -- This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. Working Group Summary --- The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. Document Quality --- The document is complete, straightforward, simple and well-written. |
2011-03-31
|
05 | Cindy Morgan | Draft added in state Publication Requested |
2011-03-31
|
05 | Cindy Morgan | [Note]: 'Lionel Morand (lionel.morand@orange-ftgroup.com) is the document shepherd' added |
2010-10-20
|
03 | (System) | New version available: draft-ietf-dime-priority-avps-03.txt |
2010-07-08
|
02 | (System) | New version available: draft-ietf-dime-priority-avps-02.txt |
2010-06-14
|
01 | (System) | New version available: draft-ietf-dime-priority-avps-01.txt |
2010-03-01
|
00 | (System) | New version available: draft-ietf-dime-priority-avps-00.txt |