jiebi/CodeConvo huggingface dataset:
Code change:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Related discussion:
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> <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
Code change:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Related discussion:
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",
Code change:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Related discussion:
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> <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.
Code change:
Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!

Related discussion:
text: 4.1. <del> 4.1.1. </del> <ins> This document registers a new entry under the IETF URN Sub-namespace defined in RFC3553: </ins> <del> Registry name: Captive Portal Unrestricted Identifier </del> <ins> Captive Portal Unrestricted Identifier </ins> <del> URN: urn:ietf:params:capport-unrestricted </del> <ins> urn:ietf:params:capport-unrestricted </ins> <del> Specification: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Repository: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del> <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.
Code change:
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"?

Related discussion:
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> <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
Code change:
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."

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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?

Related discussion:
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> <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"
Code change:
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?

Related discussion:
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> <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
Code change:
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?

Related discussion:
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
Code change:
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?

Related discussion:
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> <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 <del> ack-eliciting packets is greater than or equal to the recorded "Ack-Eliciting Threshold". </del> <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.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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> <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> <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.
Code change:
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.

Related discussion:
text: An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values. <del> 4. An endpoint could receive an ACK-FREQUENCY frame with either or both Time Tolerance and Packet Tolerance values specified.  In addition, the endpoint will have committed a max_ack_delay value to the peer, </del> <ins> An endpoint will have committed a max_ack_delay value to the peer, </ins> which specifies the maximum amount of time by which the endpoint will <del> delay sending acknowledgments; see Section XX of QUIC-TRANSPORT. </del> <ins> 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 Update Max Ack Delay field. </ins> <del> The endpoint MUST send an acknowledgement when any of the three thresholds are met.  Doing so results in the fewest acknowledgements possible within the sender's tolerance and honors the receiver's commitment. loss and batch section describes exceptions to this strategy. </del> <ins> 5. On receiving an ACK-FREQUENCY frame, an endpoint will have an updated maximum delay for sending an acknowledgement, and a packet threshold as well.  The endpoint MUST send an acknowledgement when either of the two thresholds are met. loss and batch section describes exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. <del> 4.1. </del> <ins> 5.1. </ins> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of
Code change:
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.

Related discussion:
text: codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. <del> 4.2. </del> <ins> 5.2. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This
Code change:
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.

Related discussion:
text: whether a threshold has been met and an acknowledgement is to be sent in response. <del> 5. </del> <ins> 6. </ins> An endpoint can send multiple ACK-FREQUENCY frames, and each one of them can have different values.
Code change:
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.

Related discussion:
text: If the enclosing packet number is not greater than the recorded one, the endpoint MUST ignore this ACK-FREQUENCY frame. <del> 6. </del> <ins> 7. </ins> TBD. <del> 7. </del> <ins> 8. </ins> TBD.