Diameter Congestion and Filter Attributes
draft-ietf-dime-congestion-flow-attributes-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
02 | (System) | Notify list changed from dime-chairs@ietf.org, "Lionel Morand" to (None) |
2015-10-12
|
02 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-10-05
|
02 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-09-28
|
02 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-08-27
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-08-27
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-08-13
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-08-07
|
02 | (System) | RFC Editor state changed to EDIT |
2015-08-07
|
02 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-08-07
|
02 | (System) | Announcement was received by RFC Editor |
2015-08-07
|
02 | (System) | IANA Action state changed to In Progress |
2015-08-07
|
02 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2015-08-07
|
02 | Cindy Morgan | IESG has approved the document |
2015-08-07
|
02 | Cindy Morgan | Closed "Approve" ballot |
2015-08-07
|
02 | Cindy Morgan | Ballot approval text was generated |
2015-08-07
|
02 | Cindy Morgan | Ballot writeup was changed |
2015-07-09
|
02 | Martin Stiemerling | [Ballot comment] Sorry for taking so long and thank you for addressing David's and my concerns. |
2015-07-09
|
02 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2015-07-02
|
02 | Ben Campbell | [Ballot comment] Thanks for addressing my comments. I still think the abstract is overly long (the first paragraph would have been enough), but that's up … [Ballot comment] Thanks for addressing my comments. I still think the abstract is overly long (the first paragraph would have been enough), but that's up to you. Otherwise, I think all my comments have been covered. |
2015-07-02
|
02 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2015-07-01
|
02 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-07-01
|
02 | Lyle Bertz | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-07-01
|
02 | Lyle Bertz | New version available: draft-ietf-dime-congestion-flow-attributes-02.txt |
2015-06-11
|
01 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-06-11
|
01 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-06-11
|
01 | Joel Jaeggli | [Ballot comment] the opsdir reviewer noted some questions which I think fall in line with some observations about document improvement: from linda dunbar: > I … [Ballot comment] the opsdir reviewer noted some questions which I think fall in line with some observations about document improvement: from linda dunbar: > I have reviewed this document as part of the Operational directorate's> ongoing effort to review all IETF documents being processed by the IESG.> These comments were written primarily for the benefit of the operational> area directors. Document editors and WG chairs should treat these> comments just like any other last call comments.> > > > I have some questions for the proposed AVPs by this document.> > - The ECN is marked on packets by network nodes in the middle.> Is it the Receiver of ECN marked data packets sending the proposed AVPs> to the Diameter Server?> > - If no ECN marked data packets are received, does it mean the> receiver won’t send the AVPs being proposed by the draft?> > - Diameter is the protocol for Authentication, Authorization,> and Accounting. Is it the “originator” sending the AAA request? If yes,> the “Originator” may not even have any ECN marked packets, how does the> flow “Originator” constructed the proposed AVPs?> |
2015-06-11
|
01 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-06-10
|
01 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2015-06-10
|
01 | Spencer Dawkins | [Ballot comment] I support Martin's Discuss, based on David's Gen-ART review. |
2015-06-10
|
01 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-06-10
|
01 | Benoît Claise | [Ballot comment] With some DIAMETER background, I can understand what the document specifies. However, I agree with Martin's COMMENT, and Stephen's abstract-related COMMENT. The document … [Ballot comment] With some DIAMETER background, I can understand what the document specifies. However, I agree with Martin's COMMENT, and Stephen's abstract-related COMMENT. The document should be improved |
2015-06-10
|
01 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-06-10
|
01 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-06-10
|
01 | Martin Stiemerling | [Ballot discuss] No general objection to the publication of the document. However, I am relaying a question from David Black as a DISCUSS point. I … [Ballot discuss] No general objection to the publication of the document. However, I am relaying a question from David Black as a DISCUSS point. I assume that the draft is more than unclear in Section 3.2 about what traffic means. Is it a particular flow, a single packet, etc? "I found an ECN concern, and hence added the TSV ADs to the CC line. Section 3.2 says: The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and indicates how congested traffic, i.e., traffic that has Explicit Congestion Notification Congestion Experienced marking set or some other administratively defined criteria, is treated. That appears to say that the congestion treatment may be applied solely to packets that have the CE (Congestion Experienced) marking. That would be a problem, because the defined semantics of a CE marking is that it applies to the entire flow (e.g., causes TCP to react as if a packet has been dropped), hence the congestion treatment ought to apply to the entire flow. In other words, one wants to be able to use the ECN-IP-Codepoint AVP as part of the condition that determines whether the filter rule matches, but ignore that AVP (i.e., wildcard it) in determining what traffic the action applies to, so that the response to detecting a congested flow (i.e., packets with ECN field containing CE) applies to all packets in the flow, regardless of the value in the CE field. Otherwise, the result may be ineffective, as it won't encompass packets in the congested flow that aren't CE-marked. Am I reading the draft correctly?" |
2015-06-10
|
01 | Martin Stiemerling | [Ballot comment] Section 1, 1st paragraph: It says "The first AVP provides direct support for ECN [RFC3168] in the IP header“. I am … [Ballot comment] Section 1, 1st paragraph: It says "The first AVP provides direct support for ECN [RFC3168] in the IP header“. I am sure that your draft is ot providing any support for ECN in the IP header, as we have ECN in the IP header already, isn't it. I guess you mean something like this "The first AVP provides direct support for filtering ECN marked traffic[RFC3168]“ |
2015-06-10
|
01 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2015-06-10
|
01 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-06-09
|
01 | Alissa Cooper | [Ballot comment] If this means folks are using ECN more then I'm glad to hear it. :) In Section 5.1 there are three instances of … [Ballot comment] If this means folks are using ECN more then I'm glad to hear it. :) In Section 5.1 there are three instances of "ECP-IP-Codepoint." I think these are meant to be "ECN-IP-Codepoint" right? In Section 6, I had the same thought as Ben. There could be some sensitivity about the fact that a particular user experienced congestion, and that's worth calling out. Comment for the WG: I note that RFC 6733 requires Diameter nodes to be able to negotiate TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA (among other cipher suites) for use with TLS and DTLS. Given the publication of RFC 7465, those requirements should be revisited. |
2015-06-09
|
01 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-06-09
|
01 | Ben Campbell | [Ballot comment] This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the … [Ballot comment] This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.) -- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment? "If Excess-Treatment or Congestion-Treatment has occurred..." Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”? --6, first sentence. I’d like to see a little more “show your work" here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs. (I'm probably the other person that Stephen mentioned consider such sentences as a red flag.) Editorial: -- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.) -- 3.2, first paragraph "In case..." I suggest either "If..." or "In the case that..." -- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..." |
2015-06-09
|
01 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2015-06-09
|
01 | Ben Campbell | [Ballot comment] This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the … [Ballot comment] This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.) -- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment? "If Excess-Treatment or Congestion-Treatment has occurred..." Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”? --6, first sentence. I’d like to see a little more “show your work here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs. (I'm probably the other person that Stephen mentioned consider such sentences as a red flag.) Editorial: -- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.) -- 3.2, first paragraph "In case..." I suggest either "If..." or "In the case that..." -- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..." |
2015-06-09
|
01 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-06-09
|
01 | Barry Leiba | [Ballot comment] I think IANA gets what they need to do, but the RFC Editor will have to replace four different "TBD" with four different … [Ballot comment] I think IANA gets what they need to do, but the RFC Editor will have to replace four different "TBD" with four different values. It'd have been better to use "TBD1", "TBD2", "TBD3", and "TBD4", to make it less likely that something will go amiss. It's probably fine to just say that you need to check it closely during AUTH48, to make sure that the right values got into the right places. |
2015-06-09
|
01 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-06-08
|
01 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-06-08
|
01 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-06-08
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Linda Dunbar. |
2015-06-08
|
01 | Stephen Farrell | [Ballot comment] - abstract: This isn't clear enough that you're talking about using Diameter to help manage networks in which ECN may be used, as … [Ballot comment] - abstract: This isn't clear enough that you're talking about using Diameter to help manage networks in which ECN may be used, as opposed to dealing with Diameter packets with the ECN bit set. While that may be obvious when one reads the text, some people will only see the abstract so I'd say maybe consider clarifying that here too. - intro: "the document" in 1st sentence is ambiguous - do you mean 3168 or this document? I assume s/the/this/ would be better. - intro: 2nd last para: what is an "ECN application"? Maybe you mean "networks deploying/using ECN" or something? - 3.3: is a 64-bit counter maybe too big for a number of flows? Would it be worth adding guidance to the effect that Diameter nodes ought have some max-believeable-flows setting just to avoid fat-finger or similar errors resulting in someone thinking there are 2^64-1 flows and trying to iterate over that number of things or allocate O(that) much memory? - 3.4: do you need to specify some kind of wrap-around rule for this? What value do I need to use if I've seen 2^64 packets? - 5.2: Please expand CCR on 1st use and provide a reference if one is needed. (Is it "Credit Control Request"?) - 5.2: 2nd last para, last sentence: Thanks! I think it's good that folks are including this consideration in ongoing work. - Section 6: 1st sentence is not needed and is usually a red flag statement (for me, but not only me:-) Actually, you could just lose the first para entirely. (Two more quite nitty things below, but I'll ask anyway:-) - section 6: does this define any new way in which a bad sending Diameter node could cause bad things to happen elsewhre in the network? (see comment above about section 3.3) - section 6: When I took a glance at the security considerations in 5777, it doesn't seem to consider that the "treatment" field could cause bad things to happen. Is that worth mentioning here (if real) even if it ought be more properly handled in some kind of update of 5777 sometime in the (probably far;-) future? |
2015-06-08
|
01 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-06-05
|
01 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter. |
2015-06-04
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-06-04
|
01 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-06-04
|
01 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2015-06-04
|
01 | Kathleen Moriarty | Ballot has been issued |
2015-06-04
|
01 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2015-06-04
|
01 | Kathleen Moriarty | Created "Approve" ballot |
2015-06-04
|
01 | Kathleen Moriarty | Ballot writeup was changed |
2015-06-04
|
01 | Kathleen Moriarty | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-06-04
|
01 | Lionel Morand | === 1. Summary === The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. This document defines optional Explicit Congestion Notification (ECN) … === 1. Summary === The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. This document defines optional Explicit Congestion Notification (ECN) and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 (Traffic Classification and QoS Attributes for Diameter) defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. In this draft, the Classifier Grouped AVP contained in the Filter-Rule AVP is extended with the new ECN-IP-Codepoint AVP which gives the Explicit Congestion Notification (ECN) codepoint values (defined in RFC3168) to match in the IP header. Moreover, the Filter-Rule Grouped AVP itself is extended with a new Congestion-Treatment AVP that indicates how congested traffic should be treated. The Flow-Count and Packet-Count AVPs are also defined in this document to be sent to report in application specific command information of the group of flows described by the Filter-Rule, IPFilterRule or other Diameter traffic filters. This information can be used by the application for improved decision making, Charging and rudimentary traffic profiling. === 2. Review and Consensus === The proposed extensions for RFC5777 are simple (definition of new AVPs in extendable Grouped AVPs), and there was no difficulty in coming to consensus on all points. As it is only about defining new optional AVPs, there were no real discussion in the WG, considering that the proposed AVP definitions were OK. Comments received in the meeting or on the mailing list have been taken into account and the document is seen as ready for publication. No concern/comment was received during the WGLC. === 3. Intellectual Property === Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. === 4. Other Points === The extensions to the RFC5777 regarding the use of the Filter-Rule and the Classifier Grouped AVPs proposed in this document are optional and compatible with the existing RFC5777. No update of the RFC577 is required. |
2015-06-04
|
01 | Kathleen Moriarty | Ballot writeup was changed |
2015-06-02
|
01 | Kathleen Moriarty | Placed on agenda for telechat - 2015-06-11 |
2015-06-02
|
01 | Kathleen Moriarty | Changed consensus to Yes from Unknown |
2015-06-01
|
01 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-05-31
|
01 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-05-31
|
01 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-dime-congestion-flow-attributes-01. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-dime-congestion-flow-attributes-01. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA understands that upon approval of this document, there is a single action which needs to be completed. In the AVP Codes registry under the Authentication, Authorization, and Accounting (AAA) Parameters heading at https://www.iana.org/assignments/aaa-parameters/ four new AVP codes are to be registered as follows: AVP Code: [ TBD-at-registration ] Attribute Name: ECN-IP-Codepoint Reference: [ RFC-to-be ] AVP Code: [ TBD-at-registration ] Attribute Name: Congestion-Treatment Reference: [ RFC-to-be ] AVP Code: [ TBD-at-registration ] Attribute Name: Flow-Count Reference: [ RFC-to-be ] AVP Code: [ TBD-at-registration ] Attribute Name: Packet-Count Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that this is the only action that needs to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2015-05-28
|
01 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Tero Kivinen. |
2015-05-25
|
01 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. |
2015-05-24
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2015-05-24
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2015-05-21
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2015-05-21
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2015-05-21
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-05-21
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-05-18
|
01 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-05-18
|
01 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Diameter Congestion and Filter Attributes) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Diameter Congestion and Filter Attributes) to Proposed Standard The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Congestion and Filter Attributes' as 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 2015-06-01. 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 optional ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. These optional attributes are forward and backwards compatible with RFC 5777. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-05-18
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-05-18
|
01 | Amy Vezza | Last call announcement was generated |
2015-05-17
|
01 | Kathleen Moriarty | Last call was requested |
2015-05-17
|
01 | Kathleen Moriarty | Ballot approval text was generated |
2015-05-17
|
01 | Kathleen Moriarty | Ballot writeup was generated |
2015-05-17
|
01 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD Evaluation |
2015-05-17
|
01 | Kathleen Moriarty | Last call announcement was changed |
2015-05-17
|
01 | Kathleen Moriarty | Last call announcement was generated |
2015-05-17
|
01 | Kathleen Moriarty | Last call announcement was generated |
2015-04-18
|
01 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2015-03-24
|
01 | Lionel Morand | === 1. Summary === The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. This document defines optional Explicit Congestion Notification (ECN) … === 1. Summary === The document shepherd is Lionel Morand. The responsible Area Director is Kathleen Moriarty. This document defines optional Explicit Congestion Notification (ECN) and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 (Traffic Classification and QoS Attributes for Diameter) defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. In this draft, the Classifier Grouped AVP contained in the Filter-Rule AVP is extended with the new ECN-IP-Codepoint AVP which gives the Explicit Congestion Notification (ECN) codepoint values (defined in RFC3168) to match in the IP header. Moreover, the Filter-Rule Grouped AVP itself is extended with a new Congestion-Treatment AVP that indicates how congested traffic should be treated. The Flow-Count and Packet-Count AVPs are also defined in this document to be sent to report in application specific command information of the group of flows described by the Filter-Rule, IPFilterRule or other Diameter traffic filters. This information can be used by the application for improved decision making, Charging and rudimentary traffic profiling. === 2. Review and Consensus === The proposed extensions for RFC5777 are simple (definition of new AVPs in extendable Grouped AVPs), and there was no difficulty in coming to consensus on all points. As it is only about defining new optional AVPs, there were no real discussion in the WG, considering that the proposed AVP definitions were OK. Comments received in the meeting or on the mailing list have been taken into account and the document is seen as ready for publication. No concern/comment was received during the WGLC. === 3. Intellectual Property === Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. === 4. Other Points === As shepherd and WG chair, I consider that this document should update the RFC5777 as this document will enhance the existing definition of the Filter-Rule and the Classifier Grouped AVP defined in this RFC. |
2015-03-24
|
01 | Lionel Morand | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-03-24
|
01 | Lionel Morand | IESG state changed to Publication Requested |
2015-03-24
|
01 | Lionel Morand | IESG process started in state Publication Requested |
2015-03-24
|
01 | Lionel Morand | Changed document writeup |
2015-01-27
|
01 | Benoît Claise | Shepherding AD changed to Kathleen Moriarty |
2015-01-15
|
01 | Lionel Morand | Notification list changed to dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-congestion-flow-attributes.all@tools.ietf.org, "Lionel Morand" <lionel.morand@orange.com> from dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-congestion-flow-attributes.all@tools.ietf.org |
2015-01-15
|
01 | Lionel Morand | Document shepherd changed to Lionel Morand |
2015-01-15
|
01 | Lionel Morand | no comment/concern raised during the WGLC |
2015-01-15
|
01 | Lionel Morand | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2014-12-17
|
01 | Benoît Claise | Notification list changed to dime@ietf.org, dime-chairs@tools.ietf.org, draft-ietf-dime-congestion-flow-attributes.all@tools.ietf.org |
2014-12-04
|
01 | Lionel Morand | the WGLC has been launched on 11/25/2014 and will end on 12/9/2014 |
2014-12-04
|
01 | Lionel Morand | IETF WG state changed to In WG Last Call from WG Document |
2014-10-29
|
01 | Cindy Morgan | New revision available |
2014-04-18
|
00 | Jouni Korhonen | Intended Status changed to Proposed Standard from None |
2014-04-18
|
00 | Jouni Korhonen | See mails: http://www.ietf.org/mail-archive/web/dime/current/msg07402.html http://www.ietf.org/mail-archive/web/dime/current/msg07325.html |
2014-04-18
|
00 | Jouni Korhonen | This document now replaces draft-bertz-dime-congestion-flow-attributes instead of None |
2014-04-18
|
00 | Lyle Bertz | New version available: draft-ietf-dime-congestion-flow-attributes-00.txt |