Updating TCP to Support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
13 | (System) | Received changes through RFC Editor sync (changed abstract to 'This document provides a mechanism to address issues that arise when TCP is used for traffic … Received changes through RFC Editor sync (changed abstract to 'This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced. This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.') |
2015-10-28 |
13 | Jean Mahoney | Closed request for Telechat review by GENART with state 'No Response' |
2015-10-27 |
13 | (System) | RFC published |
2015-10-27 |
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-10-14 |
13 | (System) | Notify list changed from tcpm-chairs@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> to (None) |
2015-09-24 |
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-09-02 |
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-07-23 |
13 | (System) | IANA Action state changed to No IC from In Progress |
2015-07-23 |
13 | (System) | IANA Action state changed to In Progress |
2015-07-23 |
13 | (System) | RFC Editor state changed to EDIT |
2015-07-23 |
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-07-23 |
13 | (System) | Announcement was received by RFC Editor |
2015-07-23 |
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-07-23 |
13 | Cindy Morgan | IESG has approved the document |
2015-07-23 |
13 | Cindy Morgan | Closed "Approve" ballot |
2015-07-23 |
13 | Cindy Morgan | Ballot approval text was generated |
2015-07-22 |
13 | Martin Stiemerling | Ballot writeup was changed |
2015-07-22 |
13 | Martin Stiemerling | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2015-06-30 |
13 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-06-25 |
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-06-25 |
13 | Gorry Fairhurst | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-06-25 |
13 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-13.txt |
2015-06-25 |
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed |
2015-06-25 |
12 | Martin Stiemerling | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-06-24 |
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-06-24 |
12 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-06-24 |
12 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-06-24 |
12 | Kathleen Moriarty | [Ballot comment] It does not appear that the SecDir review got a response, maybe the editor and shepherd didn't see it? https://www.ietf.org/mail-archive/web/secdir/current/msg05697.html He included a … [Ballot comment] It does not appear that the SecDir review got a response, maybe the editor and shepherd didn't see it? https://www.ietf.org/mail-archive/web/secdir/current/msg05697.html He included a bunch of nits that might be helpful. |
2015-06-24 |
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-06-24 |
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-06-24 |
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-06-24 |
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-06-24 |
12 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-06-23 |
12 | Ben Campbell | [Ballot comment] It appears that this draft obsoletes, makes historic, and according to section 1.2, updates 2861 :-) I guess it's okay to obsolete and … [Ballot comment] It appears that this draft obsoletes, makes historic, and according to section 1.2, updates 2861 :-) I guess it's okay to obsolete and make it historic in one fell swoop, but it might be worth removing "updates" from the first sentence of 1.2. My inner pedant concurs with Barry's. |
2015-06-23 |
12 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-06-22 |
12 | Barry Leiba | [Ballot comment] Just a few very minor comments -- nothing that needs any discussion. -- Section 1 -- RFC 2616 is an obsolete reference for … [Ballot comment] Just a few very minor comments -- nothing that needs any discussion. -- Section 1 -- RFC 2616 is an obsolete reference for HTTP. The current reference is RFC 7230 o To incentivise the use of long-lived connections Will you please appease my inner pedant and not say "incentivise" (which, by the way, Chrome doesn't think is a word either)? You can take advantage of the previous bullet's use of "To remove the incentive for" by using this parallel construction: "To provide an incentive for the use of long-lived connections". -- Section 4.2 -- The method RECOMMENDS that the TCP SACK option [RFC2018] is enabled and the method defined in [RFC6675] is used to recover missing segments. Even more ridiculously pedantic than the other: subjunctive mood with "recommends", please. Make both "is" into "be". -- Section 4.4 -- A TCP sender implementing this specification MUST enter the non- validated phase when the pipeACK is less than (1/2)*cwnd. Given that there are "MAY"s and a "SHOULD" involved in how pipeACK is computed, it seems rather odd to have a MUST that relates to its value. You couldn't possibly determine whether an implementation was doing this "right" because there's so much variability in the value of pipeACK anyway. No need to discuss this, but I suggest that you just do this: NEW A TCP sender implementing this specification enters the non- validated phase when the pipeACK is less than (1/2)*cwnd. END |
2015-06-22 |
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-06-22 |
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-06-18 |
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2015-06-18 |
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2015-06-11 |
12 | Gorry Fairhurst | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-06-11 |
12 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-12.txt |
2015-06-10 |
11 | Martin Stiemerling | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-06-10 |
11 | Martin Stiemerling | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-06-08 |
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-06-08 |
11 | Martin Stiemerling | Placed on agenda for telechat - 2015-06-25 |
2015-06-08 |
11 | Martin Stiemerling | Ballot has been issued |
2015-06-08 |
11 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-06-08 |
11 | Martin Stiemerling | Created "Approve" ballot |
2015-06-08 |
11 | Martin Stiemerling | Ballot writeup was changed |
2015-06-08 |
11 | Martin Stiemerling | Changed consensus to Yes from Unknown |
2015-05-22 |
11 | Gorry Fairhurst | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-05-22 |
11 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-11.txt |
2015-05-22 |
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-05-21 |
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Kaduk. |
2015-05-21 |
10 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-05-21 |
10 | Pearl Liang | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tcpm-newcwv-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tcpm-newcwv-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-05-15 |
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2015-05-15 |
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Benjamin Kaduk |
2015-05-14 |
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-05-14 |
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2015-05-08 |
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2015-05-08 |
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2015-05-08 |
10 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-05-08 |
10 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <tcpm@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-tcpm-newcwv-10.txt> … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <tcpm@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-tcpm-newcwv-10.txt> (Updating TCP to support Rate-Limited Traffic) to Experimental RFC The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Updating TCP to support Rate-Limited Traffic' <draft-ietf-tcpm-newcwv-10.txt> as Experimental RFC 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-05-22. 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 provides a mechanism to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-05-08 |
10 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2015-05-08 |
10 | Martin Stiemerling | Last call was requested |
2015-05-08 |
10 | Martin Stiemerling | Ballot approval text was generated |
2015-05-08 |
10 | Martin Stiemerling | Ballot writeup was generated |
2015-05-08 |
10 | Martin Stiemerling | IESG state changed to Last Call Requested from AD Evaluation |
2015-05-08 |
10 | Martin Stiemerling | Last call announcement was generated |
2015-04-29 |
10 | Martin Stiemerling | IESG state changed to AD Evaluation from Publication Requested |
2015-04-29 |
10 | Yoshifumi Nishida | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The intended status of the document is Experimental. This document proposes an algorithm that controls congestion window size for rate-limited applications. WG concluded that Experimental is appropriate status for the document in order to explore its efficiency and feasibility. (2) 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 describes an experimental proposal to allow TCP senders to restart data transfer quickly following an idle or less active period. This approach is expected to benefit applications that unable to send at the maximum rate permitted by the congestion window for some reasons. As a result, it aims to provide incentives for long-lived connections and to remove ad-hoc tweaks in some applications that try to maintain a large cwnd for future data transmissions. The approach can be viewed as an updated version of RFC2861 and it obsoletes RFC2861. Working Group Summary The draft has been discussed for around 4 years. There has been explicit support for the draft since the beginning. Main discussion points were some detailed mechanisms in the logic that are related to estimating path capacity and preserving congestion window size during applications are idle or less active. The initial intended status of the draft was PS, but it has been changed to Experimental as a result of the discussions. Linux kernel has the codes which address the same issue. Their algorithms are slightly different from the document. There had been discussions between the linux kernel implementers and the document authors; however, they haven't reached the consensus to replace the existing kernel codes until more solid evidences are found. The WG's conclusion is to publish the draft as an experimental and explore its efficiency and feasibility of this approach. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Some discussions points raised by reviewers are listed in Section 9.1. The patches to FreeBSD and Linux kernel have been made by the efforts from the authors and other group. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and suggested some editorial chages. I concluded it is ready to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concern about it. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is no need for another reviews. (6) Describe any specific concerns or issues that the Document Shepherd has 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. I don't have specific concern on this document (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. Each author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? The document has been mature during four-years discussions and is supported well. We have seen various positive feedbacks in the WG meetings and the ML. I believe the consensus is solid and clear. (10) 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 publicly available.) No one has indicated discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No issue was found by idnits 2.13.02 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review is required for this document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will obsolete RFC2861 and it is listed in the header and the abstract, also discussed in the following sections. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA considerations for the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains no formal language. |
2015-04-29 |
10 | Yoshifumi Nishida | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-04-29 |
10 | Yoshifumi Nishida | IESG state changed to Publication Requested from AD is watching |
2015-04-29 |
10 | Yoshifumi Nishida | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The intended status of the document is Experimental. This document proposes an algorithm that controls congestion window size for rate-limited applications. WG concluded that Experimental is appropriate status for the document in order to explore its efficiency and feasibility. (2) 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 describes an experimental proposal to allow TCP senders to restart data transfer quickly following an idle or less active period. This approach is expected to benefit applications that unable to send at the maximum rate permitted by the congestion window for some reasons. As a result, it aims to provide incentives for long-lived connections and to remove ad-hoc tweaks in some applications that try to maintain a large cwnd for future data transmissions. The approach can be viewed as an updated version of RFC2861 and it obsoletes RFC2861. Working Group Summary The draft has been discussed for around 4 years. There has been explicit support for the draft since the beginning. Main discussion points were some detailed mechanisms in the logic that are related to estimating path capacity and preserving congestion window size during applications are idle or less active. The initial intended status of the draft was PS, but it has been changed to Experimental as a result of the discussions. Linux kernel has the codes which address the same issue. Their algorithms are slightly different from the document. There had been discussions between the linux kernel implementers and the document authors; however, they haven't reached the consensus to replace the existing kernel codes until more solid evidences are found. The WG's conclusion is to publish the draft as an experimental and explore its efficiency and feasibility of this approach. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Some discussions points raised by reviewers are listed in Section 9.1. The patches to FreeBSD and Linux kernel have been made by the efforts from the authors and other group. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and suggested some editorial chages. I concluded it is ready to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concern about it. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. There is no need for another reviews. (6) Describe any specific concerns or issues that the Document Shepherd has 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. I don't have specific concern on this document (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. Each author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? The document has been mature during four-years discussions and is supported well. We have seen various positive feedbacks in the WG meetings and the ML. I believe the consensus is solid and clear. (10) 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 publicly available.) No one has indicated discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No issue was found by idnits 2.13.02 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review is required for this document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will obsolete RFC2861 and it is listed in the header and the abstract, also discussed in the following sections. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA considerations for the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains no formal language. |
2015-04-20 |
10 | Yoshifumi Nishida | Notification list changed to tcpm-chairs@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> from tcpm-chairs@ietf.org, draft-ietf-tcpm-newcwv@ietf.org |
2015-04-20 |
10 | Yoshifumi Nishida | Document shepherd changed to Yoshifumi Nishida |
2015-04-14 |
10 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-10.txt |
2015-03-06 |
09 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-09.txt |
2015-02-23 |
08 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-08.txt |
2014-09-13 |
07 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-07.txt |
2014-07-05 |
06 | Pasi Sarolahti | Intended Status changed to Experimental from Proposed Standard |
2014-03-21 |
06 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-06.txt |
2014-02-05 |
05 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-05.txt |
2013-12-16 |
04 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-04.txt |
2013-10-09 |
03 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-03.txt |
2013-08-23 |
02 | Martin Stiemerling | Intended Status changed to Proposed Standard |
2013-08-23 |
02 | Martin Stiemerling | IESG process started in state AD is watching |
2013-08-23 |
02 | (System) | Earlier history may be found in the Comment Log for /doc/draft-fairhurst-tcpm-newcwv/ |
2013-07-01 |
02 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-02.txt |
2013-06-19 |
01 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-01.txt |
2013-02-14 |
00 | Gorry Fairhurst | New version available: draft-ietf-tcpm-newcwv-00.txt |