jiebi/TextFlow huggingface dataset:
Original text:
authenticating to, and interacting with the captive portal is out of scope of this document. <del> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </del>  [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of

Reviewer comments:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Revised text:
authenticating to, and interacting with the captive portal is out of scope of this document.  <ins> This document replaces RFC 7710.  RFC 7710 used DHCP code point 160. Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of
Original text:
clients that they are behind a captive-portal enforcement device and how to contact an API for more information.  1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Revised text:
clients that they are behind a captive-portal enforcement device and how to contact an API for more information. <ins> This document replaces RFC 7710 RFC7710. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this <del> purpose (see ietf_params_capport-unrestricted).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time- consuming forms of captive portal detection. </del>  2.1.

Reviewer comments:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Revised text:
Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this  <ins> purpose (see iana-urn).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time-consuming forms of captive portal detection. </ins> 2.1.
Original text:
4.1. <del> 4.1.1. </del>  <del> Registry name: Captive Portal Unrestricted Identifier </del>  <del> URN: urn:ietf:params:capport-unrestricted </del>  <del> Specification: RFC TBD (this document) </del>  <del> Repository: RFC TBD (this document) </del>  <del> Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del>  4.2.

Reviewer comments:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Revised text:
4.1.  <ins> This document registers a new entry under the IETF URN Sub-namespace defined in RFC3553: </ins>  <ins> Captive Portal Unrestricted Identifier </ins>  <ins> urn:ietf:params:capport-unrestricted </ins>  <ins> RFC TBD (this document) </ins>  <ins> RFC TBD (this document) </ins>  <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.
Original text:
To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends <del> or it can simply send an IMMEDIATE_ACK frame, which is a non-probing </del>  frame. An endpoint's congestion controller and RTT estimator are reset upon

Reviewer comments:
Connection Migration .... " it sends or it can simply send an IMMEDIATE_ACK frame" What is the intended difference between the words "it sends" or "it can simply send"?

Revised text:
To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends  <ins> or it can send only an IMMEDIATE_ACK frame, which is a non-probing </ins> frame. An endpoint's congestion controller and RTT estimator are reset upon
Original text:
ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude <del> the peer's 'max_ack_delay' from its PTO calculation.  Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. </del>  9.

Reviewer comments:
Provides more details on why excluding maxackdelay when Ignore Order is used may cause premature PTOs.
I'm merging this -- I think this is good, but if we need to add more cautionary text, we can still do that.
When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its maxackdelay period before sending an acknowledgement. In such cases, the endpoint MAY therefore exclude the peer's 'maxackdelay' from its PTO calculation. Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when ignoreorder is enabled. Isn't this oversimplifying things so that the aspect of time until an ACK is expected to be sent is removed? To me it is not that maxackdelay is removed completely from URL PTO = smoothedrtt + max(4*rttvar, kGranularity) + maxackdelay Instead it is replaced with expected time until the sender have sent ACK-Eliciting Threshold number of packets when that is less than maxackdelay that is configured. Secondly, are you expecting the sender to make an estimate of how many packets more are received before an ACK is sent, i.e. care about what phase it is currently when calculating the PTO in regards to which packet is expected to trigger the next ACK? However, that is clearly prone to be wrong if there is a loss occurring currently who's loss indicating ack has not yet been received by the sender. So it appears to me that this allowance is by default creating a situation which will cause premature PTOs, and it would be better to put some restrictions on it.
On the second point, the sender always knows how many packets are outstanding. So, it always knows whether the PTO computation -- which is always on the latest sent packet -- should include maxackdelay or not. That said, you are right the ignoreorder causes trouble here, so how about "MAY therefore exclude the peer's 'maxackdelay' from its PTO calculation unless ignoreorder is enabled. When ignore_order is enabled, premature PTOs are significantly more likely under packet loss."

Revised text:
ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude  <ins> the peer's 'max_ack_delay' from its PTO calculation.  When Ignore Order is enabled and loss causes the peer to not receive enough packets to trigger an immediate acknowledgement, the receiver will wait 'max_ack_delay', increasing the chances of a premature PTO. Therefore, if Ignore Order is enabled, the PTO MUST be larger than the peer's 'max_ack_delay'. </ins> 9.
Original text:
A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no <del> ACK_FREQUENCY frames have been received, this value defaults to 3, which is the recommended packet threhold for loss detection in (Section 18.2 of QUIC-RECOVERY).  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </del>  ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Reviewer comments:
Sec #ack-frequency-frame says: and Sec #out-of-order says:
It seems optimal to default it to 3, because that's the default packet threshold, but the principle of least surprise argues for 1 (ie: no behavior change until an ACK_FREQUENCY frame is received), so I lean toward 1.
This PR adds a SHOULD NOT, but it seems sensible.

Revised text:
A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no  <ins> ACK_FREQUENCY frames have been received, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the default value is 1.  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger
Original text:
reordered ack-eliciting packet.  This extension modifies this behavior. <del> If an endpoint has not yet received an ACK_FREQUENCY frame, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC- TRANSPORT.  An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </del>  If the most recent ACK_FREQUENCY frame received from the peer has a "Reordering Threshold" value of 0x00, the endpoint does not make this

Reviewer comments:
Sec #ack-frequency-frame says: and Sec #out-of-order says:
It seems optimal to default it to 3, because that's the default packet threshold, but the principle of least surprise argues for 1 (ie: no behavior change until an ACK_FREQUENCY frame is received), so I lean toward 1.
This PR adds a SHOULD NOT, but it seems sensible.

Revised text:
reordered ack-eliciting packet.  This extension modifies this behavior.  <ins> In order to ensure timely loss detection, the Reordering Threshold provided in the ACK_FREQUENCY frame SHOULD NOT be larger than the re- ordering threshold used by the data sender for loss detection. (Section 18.2 of QUIC-RECOVERY) recommends a default packet threshold for loss detection of 3. An endpoint, that receives an ACK_FREQUENCY frame with a Reordering Threshold value other than 0x00, MUST immediately send an ACK frame when the packet number of largest unacknowledged packet since the last detected reordering event exceeds the Reordering Threshold. </ins> If the most recent ACK_FREQUENCY frame received from the peer has a "Reordering Threshold" value of 0x00, the endpoint does not make this
Original text:
receivers to ignore obsolete frames. A variable-length integer representing the maximum number of ack- <del> eliciting packets the recipient of this frame can receive without sending an acknowledgment.  In other words, an acknowledgement is sent when more than this number of ack-eliciting packets have been received.  Since this is a maximum value, a receiver can send an acknowledgement earlier.  A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet. </del>  A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay"

Reviewer comments:
We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?

Revised text:
receivers to ignore obsolete frames. A variable-length integer representing the maximum number of ack-  <ins> eliciting packets the recipient of this frame receives before sending an acknowledgment.  A receiving endpoint SHOULD send at least one ACK frame when more than this number of ack-eliciting packets have been received.  A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet.  By default, an endpoint sends an ACK frame for every other ack-eliciting packet, as specified in Section 13.2.2 of QUIC-TRANSPORT, which corresponds to a value of 1. </ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay"
Original text:
which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type <del> PROTOCOL_VIOLATION. </del>  A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no

Reviewer comments:
We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?

Revised text:
which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type  <ins> PROTOCOL_VIOLATION.  On receiving a valid value in this field, the endpoint MUST update its "max_ack_delay" to the value provided by the peer. </ins> A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no
Original text:
the Sequence Number value in the frame is not greater than the largest processed thus far. <del> An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value proposed by the peer in the Request Max Ack Delay field. </del> 5. A sender can use an ACK_FREQUENCY frame to reduce the number of

Reviewer comments:
We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?

Revised text:
the Sequence Number value in the frame is not greater than the largest processed thus far.  5. A sender can use an ACK_FREQUENCY frame to reduce the number of
Original text:
Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK_FREQUENCY frame and updating its recorded "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency- frame), the endpoint MUST send an acknowledgement when one of the following conditions are met: </del>  Since the last acknowledgement was sent, the number of received <del> ack-eliciting packets is greater than or equal to the recorded "Ack-Eliciting Threshold". </del>  Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.

Reviewer comments:
We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?

Revised text:
Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.  <ins> On receiving an ACK_FREQUENCY frame and updating its "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency-frame), the endpoint sends an acknowledgement when one of the following conditions are met: </ins> Since the last acknowledgement was sent, the number of received  <ins> ack-eliciting packets is greater than the "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.
Original text:
3.  Delaying acknowledgements as much as possible reduces both work done by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
3. <ins> Endpoints advertise their support of the extension described in this document by sending the following transport parameter: A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an acknowledgement.  Values of 0 and 2^14 or greater are invalid, and receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is specified in microseconds. 4. </ins> Delaying acknowledgements as much as possible reduces both work done by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this
Original text:
ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields: <del> An optional variable-length integer representing the maximum number of ack-eliciting packets after which the receiver sends an acknowledgement. </del>  <del> An optional variable-length integer representing the maximum amount of time, in microseconds, after which the receiver sends an acknowledgement.  The value of the Time Tolerance field is scaled by multiplying the encoded value by 2 to the power of the value of the "ack_delay_exponent" transport parameter set by the sender of the ACK-FREQUENCY frame (see Section XX in QUIC-TRANSPORT). Scaling in this fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. </del>  ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.

Reviewer comments:
This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.

Revised text:
ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields:  <ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid. A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 in QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the min_ack_delay advertised by this endpoint is invalid. </ins>  <ins> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.