jiebi/TextFlow huggingface dataset:
Original text:
Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: <del> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags.  For all other frames, the Frame Type field simply identifies the frame.  These frames are explained in more detail in frame- formats. </del>  The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters: An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. <del> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </del>  The Frame Type field uses a variable-length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient

Reviewer comments:
Less detail above, but a pointer to what follows.

Table 3: Frame Types The notation used in the table took a while to figure out. A little more explanation, and possibly before the table itself might make it clearer.
One suggestion, but LGTM

Revised text:
Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields:  <ins> frame-types lists and summarizes information about each frame type that is defined in this specification.  A description of this summary is included after the table. The format and semantics of each frame type are explained in more detail in frame-formats.  The remainder of this section provides a summary of important and general information. The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags. For all other frames, the Frame Type field simply identifies the frame. </ins> The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters: An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR.  <ins> All frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </ins> The Frame Type field uses a variable-length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient
Original text:
encode 6, 14, 30, or 62 bit values respectively.  integer-summary summarizes the encoding properties. <del> For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte 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 packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding.

Reviewer comments:
if we decide we need/want it.
And yes, this handwaves over coercing the mask into the right size integer for the number of bytes you read.
When you do that, it's probably worth copying the "Code Components" language from -recovery.
hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The Some hex & decimal indication would help. A picture is worth a thousand words and save the reader drawing this out themselves to understand it and getting confused. The conversion pseudo code would be helpful, possibly in an appendix.
I don't think that any change is needed here. It says "in hexadecimal" and "decimal value" right there.
We could put comma separators in the decimal values (i.e. 494878333 => 494,878,333) so they're more readily parsed as decimals rather than digit sequences. And an appendix with a varint decoder might not be the worst idea.

Revised text:
encode 6, 14, 30, or 62 bit values respectively.  integer-summary summarizes the encoding properties.  <ins> Examples and a sample decoding algorithm are shown in sample-varint. </ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding.
Original text:
The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a <del> connection.  The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On- path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </del>  The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. <del> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </del> 18. The extension_data field of the quic_transport_parameters extension

Reviewer comments:
while the client 'spins' it after one RTT. On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. It would be clearer to the reader if the explanation of operation proceeded the detail.
This is fine, but I find that description to be less than ideal. I won't try to suggest an improvement though. It isn't so bad.

Revised text:
The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a  <ins> connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On-path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </ins> The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path.  18. The extension_data field of the quic_transport_parameters extension
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  This document uses terms and notational conventions from QUIC- TRANSPORT.

Reviewer comments:
This is right next to the BCP 14 text. (Based on private conversation with Joel Halpern who expressed the concern that this seems to lack overt normative force.)

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document defines requirements on future QUIC versions, even where normative language is not used. </ins> This document uses terms and notational conventions from QUIC- TRANSPORT.
Original text:
Connection establishment implicitly provides address validation for both endpoints.  In particular, receipt of a packet protected with <del> Handshake keys confirms that the client received the Initial packet from the server.  Once the server has successfully processed a Handshake packet from the client, it can consider the client address to have been validated. </del>  <del> Additionally, a server MAY consider the client address validated if the client uses a connection ID chosen by the server and the </del>  connection ID contains at least 64 bits of entropy.  Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received.  This limits the magnitude of any amplification attack that

Reviewer comments:
The issue suggests that any packet from the server validates the server's address, because it echoes the client's CID. I'm not sure that's correct, because the client might have chosen a zero-length SCID in its initial packet, and the server doesn't echo the ODCID in Initial packets. This PR generalizes the existing rules for servers -- receiving a sufficiently-complex DCID or a valid Handshake packet is actual proof of address ownership.
The address validation section dives right into what a server needs to do to validate the client, but it doesn't really address the client needs. This is pretty simple: any valid packet from the server validates the server address via the client-chosen destination connection ID. We just need to write that down here (it might be elsewhere, I would need to check).

Revised text:
Connection establishment implicitly provides address validation for both endpoints.  In particular, receipt of a packet protected with  <ins> Handshake keys confirms that the peer successfully processed an Initial packet.  Once an endpoint has successfully processed a Handshake packet from the peer, it can consider the peer address to have been validated. </ins>  <ins> Additionally, an endpoint MAY consider the peer address validated if the peer uses a connection ID chosen by the endpoint and the </ins> connection ID contains at least 64 bits of entropy. <ins> For the client, the value of the Destination Connection ID field in its first Initial packet allows it to validate the server address as a part of successfully processing any packet.  Initial packets from the server are protected with keys that are derived from this value (see Section 5.2 of QUIC-TLS).  Alternatively, the value is echoed by the server in Version Negotiation packets (version-negotiation) or included in the Integrity Tag in Retry packets (Section 5.8 of QUIC- TLS). </ins> Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received.  This limits the magnitude of any amplification attack that
Original text:
path is unusable.  This does not necessarily imply a failure of the connection - endpoints can continue sending packets over other paths as appropriate.  If no paths are available, an endpoint can wait for <del> a new path to become available or close the connection. </del>  A path validation might be abandoned for other reasons besides failure.  Primarily, this happens if a connection migration to a new An endpoint has reached the confidentiality or integrity limit for the AEAD algorithm used by the given connection.  The cryptographic handshake failed.  A range of 256 values is reserved for carrying error codes specific to the cryptographic handshake that is used.  Codes for errors occurring when TLS is

Reviewer comments:
This is a bit of a niche code, as it is only narrowly useful for signaling loss of paths. But people wanted it and it doesn't code that much. Note the target of this pull request. For .
I'm going to leave this for a bit, but if people like the idea, I plan to merge it into .
Thank you for the PR. This error code will be useful, as the only other way of closing the connection would be to use NO_ERROR. Then, it would be impossible to know why the connection was abruptly closed.Yes, there's value in having a way to fail URL suggestion, but lgtm

Revised text:
path is unusable.  This does not necessarily imply a failure of the connection - endpoints can continue sending packets over other paths as appropriate.  If no paths are available, an endpoint can wait for  <ins> a new path to become available or close the connection.  An endpoint that has no valid network path to its peer MAY signal this using the NO_VIABLE_PATH connection error, noting that this is only possible if the network path exists but does not support the required MTU datagram-size. </ins> A path validation might be abandoned for other reasons besides failure.  Primarily, this happens if a connection migration to a new An endpoint has reached the confidentiality or integrity limit for the AEAD algorithm used by the given connection. <ins> An endpoint has determined that the network path is incapable of supporting QUIC.  An endpoint is unlikely to receive CONNECTION_CLOSE carrying this code except when the path does not support a large enough MTU. </ins> The cryptographic handshake failed.  A range of 256 values is reserved for carrying error codes specific to the cryptographic handshake that is used.  Codes for errors occurring when TLS is
Original text:
migration, as the peer will be unable to respond if the pool is exhausted.  5.1.2. An endpoint can change the connection ID it uses for a peer to

Reviewer comments:
For all packets. For all network paths.
You are right it's not really incorrect , I just found it confusing giving potentially the impression that using multiple paths without CID is "easily" possible. How about this phrasing to be even more clear: "A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint and this cannot be changed even if the network path changes."
Yes, good to call out this implicit exception.

Revised text:
migration, as the peer will be unable to respond if the pool is exhausted. <ins> An endpoint that selects a zero-length connection ID during the handshake cannot issue a new connection ID.  A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint over any network path. </ins> 5.1.2. An endpoint can change the connection ID it uses for a peer to
Original text:
4.3. <del> QUIC starts a loss epoch when a packet is lost and ends one when any packet sent after the epoch starts is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </del>  4.4.

Reviewer comments:
This isn't critical, but it's clearer and easier to parse. All to the good.
Derrell Piper writes:
The one nit here regards this sentence: This seems right to me. You might rewrite this as: But I don't think that is appreciably better. I think we can close this with no action unless we get some enthusiasm for rewording.
I think the issue is that "epoch starts is" looks like either an extra word or subject/verb agreement error. It's not actually; if you diagram the sentence out, "after the epoch starts" is in a dependent clause and "any packet ... is acknowledged" is correct agreement. That said, the rewording is easier to read because it doesn't look wrong and you don't have to try different possible parsings in your head before you find the one which works. We've tried to avoid trial decryption; let's avoid it in grammar, too.
Thanks, this seems like an improvement to me.

Revised text:
4.3.  <ins> QUIC starts a loss epoch when a packet is lost.  The loss epoch ends when any packet sent after the start of the epoch is acknowledged. TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </ins> 4.4.
Original text:
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path. <del> Datagrams are required to be of a minimum size under some conditions. However, the size of the datagram is not authenticated.  Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints, though the endpoint MAY discard such datagrams. </del>  14.1.

Reviewer comments:
NAME I think you missed the change proposed to the reference. It should point to somewhere that imposes minimum datagram size (e.g., {{validate-handshake}}, not {{version-negotiation}}).
Urgh. Thanks for catching that, NAME sent.
([IPv4]), the DF bit MUST be set if possible, to prevent fragmentation on the path. However, the size of the datagram is not authenticated. Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints, though the endpoint MAY discard such datagrams. I really think this section needs re-writing for clarity.
I find this text perfectly clear, so I will need help in identifying in what ways the text lacks clarity.
Other than kazuho's nit which I regard as minor, this is good.

Revised text:
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path.  <ins> QUIC sometimes requires datagrams to be no smaller than a certain size; see version-negotiation as an example.  However, the size of a datagram is not authenticated.  That is, if an endpoint receives a datagram of a certain size, it cannot know that the sender sent the datagram at the same size.  Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints; the endpoint MAY however discard such datagrams. </ins> 14.1.
Original text:
The creation of a registry MAY identify a range of codepoints where registrations are governed by a different registration policy.  For <del> instance, the registries for 62-bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63. </del>  Any stricter requirements for permanent registrations do not prevent provisional registrations for affected codepoints.  For instance, a <del> provisional registration for a frame type (iana-frames) of 61 could be requested. </del>  All registrations made by Standards Track publications MUST be permanent.

Reviewer comments:
NAME You have a comment here pending. I'm planning to merge this PR in ~15 hours from now, so please say something now if you still would prefer a change.
Section 22.1.4: "For instance, the registries for 62-bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63." Looking then at 22.2 it states: The "QUIC Transport Parameters" registry governs a 62-bit space. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]). No mention of the special registration rule for values in the 0-63 range. Section 22.3 and 22.4 do have these special rules. So should 22.1.4 be changed to state "may"/"sometime" have this rule. Or should a special rule be added to 22.2 and the version registry?

Revised text:
The creation of a registry MAY identify a range of codepoints where registrations are governed by a different registration policy.  For  <ins> instance, the frame type registry in iana-frames has a stricter policy for codepoints in the range from 0 to 63. </ins> Any stricter requirements for permanent registrations do not prevent provisional registrations for affected codepoints.  For instance, a  <ins> provisional registration for a frame type of 61 could be requested. </ins> All registrations made by Standards Track publications MUST be permanent.
Original text:
The payload of a packet that contains frames MUST contain at least one frame, and MAY contain multiple frames and multiple frame types. <del> Frames always fit within a single QUIC packet and cannot span multiple packets. </del>  Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields:

Reviewer comments:
Sec 12.4 says: There is no specification of error handling in the case of zero frame. I would like to know what kind of error MUST be sent. Also, the packet formats contains the following field: Should we change this to the following?

Revised text:
The payload of a packet that contains frames MUST contain at least one frame, and MAY contain multiple frames and multiple frame types.  <ins> An endpoint MUST treat receipt of a packet containing no frames as a connection error of type PROTOCOL_VIOLATION.  Frames always fit within a single QUIC packet and cannot span multiple packets. </ins> Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields:
Original text:
New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of QUIC-TRANSPORT. These registries all include the common set of fields listed in <del> Section 22.1.1 of QUIC-TRANSPORT. </del>  The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the

Reviewer comments:
Please see the for full context. This issue is tracking the following IANA question:
Responded to e-mail as well, but for GitHub tracking purposes, I believe HTTP/3 should be its own registry page, separate from QUIC and analogous to HTTP/2.
NAME I think that is a good proposal.
Can we put that in the draft then?

Revised text:
New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of QUIC-TRANSPORT. These registries all include the common set of fields listed in  <ins> Section 22.1.1 of QUIC-TRANSPORT.  These registries [SHALL be/are] collected under a "Hypertext Transfer Protocol version 3 (HTTP/3) Parameters" heading. </ins> The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the