Proportional Rate Reduction for TCP
draft-ietf-tcpm-prr-rfc6937bis-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-05-23
|
14 | Gorry Fairhurst | Last call was requested |
2025-05-23
|
14 | Gorry Fairhurst | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2025-05-23
|
14 | Gorry Fairhurst | Last call announcement was changed |
2025-05-23
|
14 | Gorry Fairhurst | Ballot writeup was changed |
2025-05-23
|
14 | Gorry Fairhurst | Ballot writeup was changed |
2025-05-23
|
14 | Gorry Fairhurst | Ballot writeup was changed |
2025-05-23
|
14 | Gorry Fairhurst | Last call announcement was generated |
2025-05-18
|
14 | (System) | Changed action holders to Gorry Fairhurst (IESG state changed) |
2025-05-18
|
14 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-05-18
|
14 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-14.txt |
2025-05-18
|
14 | Neal Cardwell | New version accepted (logged-in submitter: Neal Cardwell) |
2025-05-18
|
14 | Neal Cardwell | Uploaded new revision |
2025-04-15
|
13 | Gorry Fairhurst | PRR : draft-ietf-tcpm-prr-rfc6937bis Thank you for providing this much needed specification to update the document describing PRR and to help move the specification to the … PRR : draft-ietf-tcpm-prr-rfc6937bis Thank you for providing this much needed specification to update the document describing PRR and to help move the specification to the Standards Track. I have a few Area Director comments below, that I would like to see addressed in a new revision of this I-D before it progresses to IETF LC, please see below: --- Section 1.1 I fully understand the real value of 1.1 during development of the document. I was unsure of the final intent for 1.1. Document and WG Information when this is published as an RFC, please can you clarify the WG intent? (e.g. this could be moved to an appendix) - but I think in this case, the section: “Changes From RFC 6937” provides the necessary background so this section can be marked as to be removed by the RFC-Ed? ---- Section 3: Please avoid “we” in a standards track document,: The words “we” introduce ambiguity about the consensus: “For [RFC6937] we published a companion paper”, could this be rephrased more neutrally, simply stating this was published, or if not state who published this? --- RFC2119 Language: 1) I expected the definition for RFC2119 language, in a separate section, likely after section 3. Please consider moving this to section 5, and see (2) below. 2) I expected the definition to use the current boilerplate. Please would you consider using the latest boiler plate text: “ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.” --- Section 5:. It seems the definition and the reference cited are juxtaposed in: “[RFC9293]: snd.una (send unacknowledged).[RFC5681]: duplicate ACK, FlightSize, Sender Maximum Segment Size (SMSS).[RFC6675]: covered (as in "covered sequence numbers”).” - For consistency, is it possible to rewrite each as a definition followed by the reference? --- At the end of section 4, the I-D finally states: “It is RECOMMENDED that PRR is implemented together with RACK-TLP loss recovery [RFC8985].” 1) Why is this not a MUST, i.e, please explain the conditions where the recommendation is not required, and WHAT are the implications? 2) I suggest placing this as the final sentence of section 4 concerns me that some people may overlook this important. I’d much rather this requirement was moved to the start of section 5 --- Section 6: This section mentions TCP in the opening paragraph. I suggest that although the spec is clearly targeted at TCP, we don’t need to explicitly state this is only for TCP senders. Is it possible to remove the word? MSS is specifically a TCP number, is this actually MPS when using a transport that can detect the current maximum packet size, rather than the MSS negotiated at connection setup? -- Please move and changing the following recommendation to a separate paragraph. Currently it is in a para marked as a note. “As with common scenarios that could allow bursts, such as restarting from idle, it is RECOMMENDED that implementations use pacing to reduce the burstiness of traffic.” - Would it be acceptable to state this something more like: “It is RECOMMENDED that implementations use pacing to reduce the burstiness of traffic. This recommendation is consistent current practice to mitigate bursts, e.g. pacing transmission bursts after restarting from idle. “ ---- Section 7: This example introduces TCP midway through the text and then mentions it several times. 1), if the intent is to scope to only TCP, please state this earlier at the start of the example 2) Could you anyway could you please replace “TCP will send” by “the sender will send..” and similar “TCP immediately retransmits” to “the sender immediately retransmits” --- Section 8: This text mentions TCP, but I do not understand why this might not be generalised to any similar transport: “PRR maintains TCP's ACK clocking” can this be “PRR maintains the sender’s ACK clocking” “Note that as TCP approaches the end of recovery” can this be “Note that as the sender approaches the end of recovery” “catches up while TCP is still in recovery, TCP will” could this be: “catches up while the sender remains in recovery, it will” etc. --- This section later also says: “Although this burst might be viewed as being hard on the network,” 1) could this be made clearer, e.g. something like: “Although such a burst could negatively impact other sharing flows”, or similar? 2) I have a question: Is this type of behaviour limited when using methods such as CWV? --- Please avoid “we” in a standards track document, instead please use the “editors” if you do strongly feel this is controversial for the WG as a whole, or if it had some consensus please just remove “we”: “our earlier measurements [RFC 6937 section 6]” could this be: “earlier measurements [RFC 6937 section 6]” --- “We claim that this Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments.”, ought to be neutral as to who in the WG claim this, I suggest: “This Strong Packet Conservation Bound is the most aggressive algorithm that does not lead to additional forced losses in some environments.” --- “We demonstrate this property with a little thought experiment” , similarly I suggest:: “ This property is demonstrated with a thought experiment:”, similarly “we” can be rephrased in the remaining section, or if strictly necessary because there was no consensus, state that the editors claim this. ---- I hope that this set comments should be easy to address and I will start an IETF-wide Last Call that lasts 2 weeks (3 if overlapping an IETF meeting week). Several directorate reviews are also requested. These reviewers are usually not experts in the document’s topic, and come in with fresh eyes. You are usually responsible for answering these comments – however if any comment that comes up does not have a clear resolution, you should ask for the chairs and the working group’s help. Usually, IETF LC also necessitates document changes, and you will need to publish a new version of the draft. If those changes are major, the status won't change until that version is available. I will then change your document's status to "IESG evaluation" to trigger the IESG to start reviewing the document, with an intention to publish as PS. I look forward to any questions or a revised-ID. Best wishes, Gorry (WIT Area Director) |
2025-04-15
|
13 | (System) | Changed action holders to Matt Mathis, Nandita Dukkipati, Yuchung Cheng, Neal Cardwell (IESG state changed) |
2025-04-15
|
13 | Gorry Fairhurst | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2025-04-15
|
13 | Gorry Fairhurst | Ballot writeup was changed |
2025-04-12
|
13 | Gorry Fairhurst | RFC Editor Note for ballot was generated |
2025-04-12
|
13 | Gorry Fairhurst | RFC Editor Note was cleared |
2025-04-12
|
13 | Gorry Fairhurst | RFC Editor Note for ballot was generated |
2025-04-12
|
13 | Gorry Fairhurst | RFC Editor Note for ballot was generated |
2025-04-12
|
13 | Gorry Fairhurst | Ballot approval text was generated |
2025-04-12
|
13 | Gorry Fairhurst | Ballot writeup was generated |
2025-04-12
|
13 | Gorry Fairhurst | I will review your document, and plan to do this in the next two weeks (subject to other constraints and document length). You should reply … I will review your document, and plan to do this in the next two weeks (subject to other constraints and document length). You should reply to any comments or questions, but replies from others in the WG are also welcome. If major issues are found, your document's progress will be blocked until they are disposed of (possibly requiring a new version of the draft). |
2025-04-12
|
13 | Gorry Fairhurst | IESG state changed to AD Evaluation from Publication Requested |
2025-04-04
|
13 | Yoshifumi Nishida | Document Shepherd Write-Up for Group Documents This version is dated 4 July 2022. # Document History 1) Does the working group (WG) consensus represent the … Document Shepherd Write-Up for Group Documents This version is dated 4 July 2022. # Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was a broad consensus in the WG on the document including from major OS implementers such as Linux, FreeBSD and Windows as the previous version of the algorithm has already been used by these OSes as the default. 2) Was there controversy about particular points, or were there decisions where the consensus was particularly rough? This draft specifies a congestion control algorithm during recovery period which is the updated version of RFC6317 published 12 years ago. The intention of the draft is to promote the specification to a proposed standard based on the experiences accumulated over the period. There were various suggestions and comments which improve the quality of the document, however, most of them focused on improving clarity of the specification such as definitions of the terms used in the documents or clarifying the applicability of the algorithm and relationships with other congestion control standards. One notable technical discussion point was the cwnd size at the end of the recovery period when this algorithm is applied. Our consensus was to leave it to the congestion control algorithms used prior to entering recovery process. This simplifies the scope of the algorithm in the document. We haven't observed any controversial opinions after this decision has been made. 3) 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 publicly available.) No one has threatened an appeal. 4) For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? Linux and FreeBSD supports the specification of this draft. # Additional Reviews 5) Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. We've received various feedback from the implementors of Linux and FreeBSD as well as network protocol experts. 6) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This document does not require any formal reviews. 7) If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? The document does not contain a YANG module. 8) Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No formal language verifications are necessary for the documents. # Document Shepherd Checks 9) Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes, the document is clearly written and ready to be handed off. 10) Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No issue has been identified. 11) What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended status of the document is Proposed Standard as there is a strong consensus in the WG. Datatracker state attributes correctly reflect it. 12) Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. We've confirmed from all authors that there is no IPR related to the contents of the document. 13) Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, all five authors are willing to be listed as such. 14) Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) idnits 2.17.1 reports no errors in the document. There are some warnings, but we've confirmed that we don't need to address them. 15) Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. No, they are classified correctly. 16) List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None 17) Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. None 18) Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No such reference. 19) Will publication of this document change the status of any existing RFCs? The document will obsolete RFC6937 as the new specification for PRR and will move the specification to the Standards Track. 20) 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). This document does not require any IANA actions. 21) List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. This document does not have any new IANA registries. |
2025-04-04
|
13 | Yoshifumi Nishida | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2025-04-04
|
13 | Yoshifumi Nishida | IESG state changed to Publication Requested from I-D Exists |
2025-04-04
|
13 | (System) | Changed action holders to Gorry Fairhurst (IESG state changed) |
2025-04-04
|
13 | Yoshifumi Nishida | Responsible AD changed to Gorry Fairhurst |
2025-04-04
|
13 | Yoshifumi Nishida | Document is now in IESG state Publication Requested |
2025-04-04
|
13 | Yoshifumi Nishida | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2025-04-04
|
13 | Yoshifumi Nishida | IETF WG state changed to WG Consensus: Waiting for Write-Up |
2025-04-04
|
13 | Yoshifumi Nishida | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2025-04-04
|
13 | Yoshifumi Nishida | Document Shepherd Write-Up for Group Documents This version is dated 4 July 2022. # Document History 1) Does the working group (WG) consensus represent the … Document Shepherd Write-Up for Group Documents This version is dated 4 July 2022. # Document History 1) Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There was a broad consensus in the WG on the document including from major OS implementers such as Linux, FreeBSD and Windows as the previous version of the algorithm has already been used by these OSes as the default. 2) Was there controversy about particular points, or were there decisions where the consensus was particularly rough? This draft specifies a congestion control algorithm during recovery period which is the updated version of RFC6317 published 12 years ago. The intention of the draft is to promote the specification to a proposed standard based on the experiences accumulated over the period. There were various suggestions and comments which improve the quality of the document, however, most of them focused on improving clarity of the specification such as definitions of the terms used in the documents or clarifying the applicability of the algorithm and relationships with other congestion control standards. One notable technical discussion point was the cwnd size at the end of the recovery period when this algorithm is applied. Our consensus was to leave it to the congestion control algorithms used prior to entering recovery process. This simplifies the scope of the algorithm in the document. We haven't observed any controversial opinions after this decision has been made. 3) 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 publicly available.) No one has threatened an appeal. 4) For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? Linux and FreeBSD supports the specification of this draft. # Additional Reviews 5) Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. We've received various feedback from the implementors of Linux and FreeBSD as well as network protocol experts. 6) Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. This document does not require any formal reviews. 7) If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? The document does not contain a YANG module. 8) Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No formal language verifications are necessary for the documents. # Document Shepherd Checks 9) Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes, the document is clearly written and ready to be handed off. 10) Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No issue has been identified. 11) What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The intended status of the document is Proposed Standard as there is a strong consensus in the WG. Datatracker state attributes correctly reflect it. 12) Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. We've confirmed from all authors that there is no IPR related to the contents of the document. 13) Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, all five authors are willing to be listed as such. 14) Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) idnits 2.17.1 reports no errors in the document. There are some warnings, but we've confirmed that we don't need to address them. 15) Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References. No, they are classified correctly. 16) List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None 17) Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them. None 18) Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No such reference. 19) Will publication of this document change the status of any existing RFCs? The document will obsolete RFC6937 as the new specification for PRR and will move the specification to the Standards Track. 20) 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). This document does not require any IANA actions. 21) List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. This document does not have any new IANA registries. |
2024-11-09
|
13 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-13.txt |
2024-11-09
|
13 | (System) | New version approved |
2024-11-09
|
13 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Neal Cardwell , Yuchung Cheng |
2024-11-09
|
13 | Neal Cardwell | Uploaded new revision |
2024-10-25
|
12 | Michael Tüxen | Added to session: IETF-121: tcpm Tue-1300 |
2024-07-28
|
12 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-12.txt |
2024-07-28
|
12 | Neal Cardwell | New version accepted (logged-in submitter: Neal Cardwell) |
2024-07-28
|
12 | Neal Cardwell | Uploaded new revision |
2024-07-28
|
11 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-11.txt |
2024-07-28
|
11 | Neal Cardwell | New version accepted (logged-in submitter: Neal Cardwell) |
2024-07-28
|
11 | Neal Cardwell | Uploaded new revision |
2024-07-21
|
10 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-10.txt |
2024-07-21
|
10 | (System) | New version approved |
2024-07-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Neal Cardwell , Yuchung Cheng |
2024-07-21
|
10 | Neal Cardwell | Uploaded new revision |
2024-07-21
|
09 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-09.txt |
2024-07-21
|
09 | (System) | New version approved |
2024-07-21
|
09 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Neal Cardwell , Yuchung Cheng |
2024-07-21
|
09 | Neal Cardwell | Uploaded new revision |
2024-07-19
|
08 | Michael Tüxen | Added to session: IETF-120: tcpm Tue-2000 |
2024-03-16
|
08 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-08.txt |
2024-03-16
|
08 | (System) | New version approved |
2024-03-16
|
08 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Neal Cardwell , Yuchung Cheng |
2024-03-16
|
08 | Neal Cardwell | Uploaded new revision |
2024-03-16
|
07 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-07.txt |
2024-03-16
|
07 | (System) | New version approved |
2024-03-16
|
07 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Neal Cardwell , Yuchung Cheng |
2024-03-16
|
07 | Neal Cardwell | Uploaded new revision |
2024-03-06
|
06 | Michael Tüxen | Added to session: IETF-119: tcpm Mon-0530 |
2024-02-26
|
06 | Neal Cardwell | New version available: draft-ietf-tcpm-prr-rfc6937bis-06.txt |
2024-02-26
|
06 | Neal Cardwell | New version accepted (logged-in submitter: Neal Cardwell) |
2024-02-26
|
06 | Neal Cardwell | Uploaded new revision |
2024-01-29
|
05 | Matt Mathis | New version available: draft-ietf-tcpm-prr-rfc6937bis-05.txt |
2024-01-29
|
05 | Matt Mathis | New version accepted (logged-in submitter: Matt Mathis) |
2024-01-29
|
05 | Matt Mathis | Uploaded new revision |
2024-01-25
|
04 | Martin Duke | Tag Revised I-D Needed - Issue raised by WGLC set. |
2024-01-25
|
04 | Martin Duke | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2024-01-10
|
04 | (System) | Document has expired |
2023-07-17
|
04 | Michael Tüxen | Added to session: IETF-117: tcpm Mon-2230 |
2023-07-09
|
04 | Yuchung Cheng | New version available: draft-ietf-tcpm-prr-rfc6937bis-04.txt |
2023-07-09
|
04 | (System) | New version approved |
2023-07-09
|
04 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Yuchung Cheng , tcpm-chairs@ietf.org |
2023-07-09
|
04 | Yuchung Cheng | Uploaded new revision |
2023-03-26
|
03 | Yuchung Cheng | New version available: draft-ietf-tcpm-prr-rfc6937bis-03.txt |
2023-03-26
|
03 | (System) | New version approved |
2023-03-26
|
03 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Yuchung Cheng , tcpm-chairs@ietf.org |
2023-03-26
|
03 | Yuchung Cheng | Uploaded new revision |
2022-12-05
|
02 | (System) | Document has expired |
2022-10-25
|
02 | Michael Tüxen | IETF WG state changed to In WG Last Call from WG Document |
2022-10-08
|
02 | Michael Tüxen | Changed consensus to Yes from Unknown |
2022-10-08
|
02 | Michael Tüxen | Intended Status changed to Proposed Standard from None |
2022-10-08
|
02 | Michael Tüxen | Notification list changed to nsd.ietf@gmail.com because the document shepherd was set |
2022-10-08
|
02 | Michael Tüxen | Document shepherd changed to Yoshifumi Nishida |
2022-06-03
|
02 | Yuchung Cheng | New version available: draft-ietf-tcpm-prr-rfc6937bis-02.txt |
2022-06-03
|
02 | (System) | New version approved |
2022-06-03
|
02 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Yuchung Cheng |
2022-06-03
|
02 | Yuchung Cheng | Uploaded new revision |
2021-11-02
|
01 | Michael Tüxen | Added to session: IETF-112: tcpm Thu-1200 |
2021-08-26
|
01 | (System) | Document has expired |
2021-02-22
|
01 | Matt Mathis | New version available: draft-ietf-tcpm-prr-rfc6937bis-01.txt |
2021-02-22
|
01 | (System) | New version approved |
2021-02-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Matt Mathis , Nandita Dukkipati , Yuchung Cheng |
2021-02-22
|
01 | Matt Mathis | Uploaded new revision |
2021-01-13
|
00 | Yoshifumi Nishida | This document now replaces draft-mathis-tcpm-rfc6937bis instead of None |
2021-01-13
|
00 | Matt Mathis | New version available: draft-ietf-tcpm-prr-rfc6937bis-00.txt |
2021-01-13
|
00 | (System) | WG -00 approved |
2021-01-13
|
00 | Matt Mathis | Set submitter to "Matt Mathis ", replaces to draft-mathis-tcpm-rfc6937bis and sent approval email to group chairs: tcpm-chairs@ietf.org |
2021-01-13
|
00 | Matt Mathis | Uploaded new revision |