jiebi/TextFlow huggingface dataset:
Original text:
be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames.  13.2.2. A receiver determines how frequently to send acknowledgements in

Reviewer comments:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Revised text:
be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. <ins> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </ins> 13.2.2. A receiver determines how frequently to send acknowledgements in
Original text:
packets, the ACK Delay field in acknowledgements for those packet types SHOULD be set to 0. <del> 13.2.7. </del>  ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged; see packet-protected.

Reviewer comments:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Revised text:
packets, the ACK Delay field in acknowledgements for those packet types SHOULD be set to 0.  <ins> 13.2.6. </ins> ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged; see packet-protected.
Original text:
Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <del> 13.2.8. </del>  Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only

Reviewer comments:
It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.

Revised text:
Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys.  <ins> 13.2.7. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only
Original text:
path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets. <del> Unlike the attack described in on-path-spoofing, the attacker can ensure that the new path is successfully validated. </del> This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if

Reviewer comments:
This text could be read to imply that an off-path attacker is more capable than an on-path attacker, which is rarely true. What it was meant to point out was that it is easier to move traffic onto a path that you are on. What it fails to acknowledge is that it is also easier to move traffic off a path that you are on. In other words, the treatment of this in 21.12 is more thorough and we don't need to talk about limitations. Mike suggested that there is some duplication between this attack and the more comprehensive analysis in 21.12. That is true, but these serve different purposes. This is to describe attacks and the normative requirements on endpoints necessary to avoid them. The other section is a thorough and hollistic analysis. I couldn't see any truly straightforward changes. That doesn't mean that we won't find a way to clean this up, or that it would be undesirable to have fewer words, but I've not the time for that right now.
I find the text in 9.3.3 confusing, because it says: Unlike the attack described in {{on-path-spoofing}}, the attacker can ensure that the new path is successfully validated. This is odd because on-path attackers are generally regarded as stronger than on-path attackers. Why can't an on-path attacker complete this attack.
I think you're right that the text is confusing, if not quite incorrect. An on-path attacker can rewrite a source address, causing an apparent migration, but can't cause path validation to succeed with that source address unless it is actually on-path from both endpoints to the spoofed addresses as well. An off-path attacker which can race packets successfully can cause migration with successful path validation to a path which includes it, becoming a limited on-path attacker. This also feels slightly duplicative of 21.12.3; it might be worth condensing some text between these sections.

Revised text:
path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets.  This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if
Original text:
between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port. <del> Path validation tests that packets can be both sent to (PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the path.  Importantly, it validates that the packets received from the migrating endpoint do not carry a spoofed source address. </del>  Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession

Reviewer comments:
The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .

Revised text:
between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port.  <ins> Path validation tests that packets sent on a path to a peer are received by that peer.  Path validation is used to ensure that packets received from a migrating peer do not carry a spoofed source address. Path validation does not validate that a peer can send in the return direction.  The peer performs independent validation of the return path. </ins> Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession
Original text:
8.3. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame <del> containing a random payload on the path to be validated. </del>  An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss.  However, an endpoint SHOULD NOT send multiple

Reviewer comments:
The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .

Revised text:
8.3. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame  <ins> containing an unpredictable payload on the path to be validated. </ins> An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss.  However, an endpoint SHOULD NOT send multiple
Original text:
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a <del> PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </del>  An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-

Reviewer comments:
The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .

Revised text:
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a  <ins> PATH_RESPONSE frame.  A PATH_RESPONSE frame does not need to be sent on the network path where the PATH_CHALLENGE was received; a PATH_RESPONSE can be sent on any network path.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </ins> An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-
Original text:
8.5. <del> A new address is considered valid when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.  Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </del>  8.6.

Reviewer comments:
The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .

Revised text:
8.5.  <ins> Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame. This validates the path on which the PATH_CHALLENGE was sent. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </ins> 8.6.
Original text:
initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is:  Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.

Reviewer comments:
I believe these two cases are both 3*PTO to allow the PTO to expire at least once before declaring path validation failure and idle timeout.
Thanks for your suggestions, I'm quite happy with this now.
NAME says in : This is reasonable. I don't know which document needs the text though.
This looks like it should go into -recovery, since -transport mostly only refers to as a TP, except in Section 13.2.1 ("sending-acknowledgements"), but that text is very general.
I would suggest that this should go where a value of X PTOs is suggested for each specific timer.
Relabeling, since ended up being against -transport and not -recovery.

Revised text:
initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is: <ins> This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame does not cause path validation failure. </ins> Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.
Original text:
To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO). </del>  10.1.1.

Reviewer comments:
I believe these two cases are both 3*PTO to allow the PTO to expire at least once before declaring path validation failure and idle timeout.
Thanks for your suggestions, I'm quite happy with this now.
NAME says in : This is reasonable. I don't know which document needs the text though.
This looks like it should go into -recovery, since -transport mostly only refers to as a TP, except in Section 13.2.1 ("sending-acknowledgements"), but that text is very general.
I would suggest that this should go where a value of X PTOs is suggested for each specific timer.
Relabeling, since ended up being against -transport and not -recovery.

Revised text:
To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the  <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </ins> 10.1.1.
Original text:
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). <del> Versions (versions) and error codes (error-codes) are described using integers, but do not use this encoding. </del>  17.

Reviewer comments:
Error codes do use varints, but packet numbers (in the header) don't.

Revised text:
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25).  <ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </ins> 17.