jiebi/CodeConvo huggingface dataset:
Code change:
Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks

Related discussion:
text: also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorith is <del> deemed _safe_ for use, but it is still is not _recommended_ for use because it does not perform well for the user. </del> <ins> deemed _safe_ for use, but it is still is _not recommended_ for use because it does not perform well for the user RFC8890. </ins> As examples of such statements, RFC3649 specifying HighSpeed TCP includes a statement in the abstract stating that the proposed congestion control algorithm is Experimental, but may be deployed in <del> the current Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating the mechanism is only being proposed for use in controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start. The Quick-Start method is discussed as an example in RFC9049. Alhough out of the scope of this document, a proponent of a new </del> <ins> the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. Alhough out of the scope of this document, proponents of a new </ins> algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In general, these algorithms are expected to be less mature than ones
Code change:
I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL

Related discussion:
text: 2. <ins> 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. 3. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations
Code change:
I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL

Related discussion:
text: or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). <del> 3. 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. </del> 4. Algorithms can be designed for general Internet deployment or for use
Code change:
The title of section 5.2.1 mentions general-purpose transports but the content really about comparing against standard congestion control algorithms, I suggest to reflect that in the section title. URL
Hmmm: This was originally conceived as General-Purpose v Real-Time (next section). If we change this to "standard general-purpose congestion control algorithms" , does it then make "real-time look non-standard - so ought that now be "standard real-time congestion control algorithms"? Would that help?
It was not that clear that it was supposed to convey "general-purpose" VS "real-time". But my main point was that if this is all about congestion control for general purpose transport then lets say that. Competing with general purpose congestion control Competing with real-time congestion control

Related discussion:
text: 5.2.2. <del> General-purpose protocols need to coexist in the Internet with real- </del> <ins> General-purpose algorithms need to coexist in the Internet with real- </ins> time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available capacity) and more strict latency bounds.  See RFC8836 for a
Code change:
This paragraph is a good summery of what is available related to congestion control when it comes to real-time traffic in the context of this specification. However, all of those referenced resources were developed following the requirements set out by URL , also RFC8836 describes the aspects of real-time conversational media that helps the scope of being real-time. hence, I suggest we add a reference to RFC8836. URL

Related discussion:
text: General-purpose protocols need to coexist in the Internet with real- time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available <del> capacity) and more strict latency bounds. </del> <ins> capacity) and more strict latency bounds.  See RFC8836 for a description of the characteristics of this use case and the resulting requirements. </ins> RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some
Code change:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Related discussion:
text: delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049. <ins> Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a formal recommendation from the community.  Instead, the community judges the publication of Informational RFCs based on the value of their addition to the RFC series. </ins> Although out of the scope of this document, proponents of a new algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In
Code change:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Related discussion:
text: requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and <del> a half BDP.  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del> <ins> a half times the Bandwidth Delay Product (BDP).  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </ins> This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track
Code change:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Related discussion:
text: 5.3.2. <del> The proposed congestion control algorithm ought to discuss whether it </del> <ins> A congestion control algorithm proposal MUST discuss whether it </ins> allows for incremental deployment in the targeted environment.  For a <del> mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </del> <ins> mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </ins> Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the
Code change:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Related discussion:
text: The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control specification explicitly forbids use on the public Internet, the <del> community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </del> <ins> community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </ins> The evaluation in each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of
Code change:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Related discussion:
text: For these reasons, data center congestion controls are often distinct from those running elsewhere on the Internet (see controlled- <del> environments.  A proposed congestion control need not coexist well </del> <ins> environments).  A proposed congestion control need not coexist well </ins> with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it.
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <del> 7.1.1. </del> <ins> 7.2. </ins> Some equipment in the network uses an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: uses excessive resources, and therefore will operate within the envelope set by network transport circuit breaker algorithms. <del> 7.2. </del> <ins> 7.3. </ins> An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: its operation is robust when there is a significant change in the minimum delay. <del> 7.3. </del> <ins> 7.4. </ins> The "Internet of Things" (IoT) is a broad concept, but when evaluating a proposed congestion control algorithm, it is often