jiebi/TextFlow huggingface dataset:
Original text:
packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network <del> treatment SHOULD therefore be carried over different five-tuples </del>  (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network  <ins> treatment should therefore be carried over different five-tuples </ins> (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to
Original text:
example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <del> Applications SHOULD define an alternate endpoint discovery mechanism </del>  to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.  <ins> Applications should define an alternate endpoint discovery mechanism </ins> to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and
Original text:
applications using QUIC, as well. Application developers should note that any fallback they use when <del> QUIC cannot be used due to network blocking of UDP SHOULD guarantee </del>  the same security properties as QUIC; if this is not possible, the <del> connection SHOULD fail to allow the application to explicitly handle </del>  fallback to a less-secure alternative.  See fallback. 14.

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
applications using QUIC, as well. Application developers should note that any fallback they use when  <ins> QUIC cannot be used due to network blocking of UDP should guarantee </ins> the same security properties as QUIC; if this is not possible, the  <ins> connection should fail to allow the application to explicitly handle </ins> fallback to a less-secure alternative.  See fallback. 14.
Original text:
stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly <del> close either the ingress or egress direction; these actions are fully independent of each other. </del>  QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed,

Reviewer comments:
This text in is incorrect. An endpoint can abruptly close (reset) egress data, but it can only request that its peer abruptly close ingress (using STOP_SENDING).
is there a missing "not"? Do you mean: s/An endpoint can abruptly close (reset) egress data/An endpoint cannot abruptly close (reset) egress data/ ? Anyway, yes, we need to fix that!

Revised text:
stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly  <ins> close the egress direction or request that its peer abruptly close the ingress direction; these actions are fully independent of each other. </ins> QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed,
Original text:
As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an <del> alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </del>  Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,

Reviewer comments:
Issue: “and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED”. I agree with the intent, but here an RFC2119 keyword is used, but is this intended, and can this please cite the RFC that says this rather than just stating this.
Similarly noted in
PR removes normative language and says "usually ... appropriate" instead. Is that okay? Or should the wording be stronger?

Revised text:
As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an  <ins> alternate mapping to UDP, usually the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is appropriate.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,
Original text:
Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might <del> lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </del>  7.

Reviewer comments:
The proposed text looks OK to me.
The ID said: “blocking or other interference by network elements such as firewalls” I think this language could be seen as having a little attitude that could be avoided. I suggest replacing “interference”, and instead say that this can change the forwarding policy. This also extends it to include action from QoS policies and service level agreements. “by network elements such as firewalls that rely on the port number for application identification.” I’d prefer “use” to “rely” … because they might well use other heuristics in future if they do prove more useful to classify sessions/packets.
Is the wording in better/good?

Revised text:
Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might  <ins> lead to blocking or other changes to the forwarding behavior by network elements such as firewalls that use the port number for application identification. </ins> 7.
Original text:
13. <del> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </del>  clusters. A server that rolls out a new version of QUIC can do so in three

Reviewer comments:
process assumes that the set of versions that a server supports is fixed. This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. This functionality was removed from -transport, and appears to refer to text in draft-ietf-quic-version-negotiation, but that draft isn't referenced at all.
I can add a reference to draft-ietf-quic-version-negotiation and make clear that this is an extension and not part of the base spec.

Revised text:
13.  <ins> QUIC version 1 does not specify a version negotation mechanism in the base spec but I-D.draft-ietf-quic-version-negotiation proposes an extension.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </ins> clusters. A server that rolls out a new version of QUIC can do so in three
Original text:
a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate <del> amplification attacks (see section 9 of QUIC-TRANSPORT).  An NAT </del>  function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and

Reviewer comments:
Some section refs weren't linked to the sections; some objects were defined multiple ways; one reference wasn't actually cited in the text.
Thanks a lot!

Revised text:
a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate  <ins> amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT </ins> function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and
Original text:
to use smaller packets, so that the limited reassembly capacity is not exceeded. <del> For TCP, MSS clamping (Section 3.2 of {?RFC4459}}) is often used to </del>  change the sender's maximum TCP segment size, but QUIC requires a different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery

Reviewer comments:
Some section refs weren't linked to the sections; some objects were defined multiple ways; one reference wasn't actually cited in the text.
Thanks a lot!

Revised text:
to use smaller packets, so that the limited reassembly capacity is not exceeded.  <ins> For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to </ins> change the sender's maximum TCP segment size, but QUIC requires a different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery
Original text:
14. <del> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </del>  QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable

Reviewer comments:
Some section refs weren't linked to the sections; some objects were defined multiple ways; one reference wasn't actually cited in the text.
Thanks a lot!

Revised text:
14.  <ins> I-D.ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </ins> QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable
Original text:
cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. <del> QUIC endpoints support address migration and a QUIC connection can survive a change of the IP address or ports by mapping the connection ID, if present, to an existing connection.  Ideally a new connection ID is used at the same time when the address/port changes to avoid linkability.  As new connection IDs belonging to the same connection are not known to on-path devices, network devices are not able to map QUIC connections after a 4-tuple change.  As such, when the 4-tuple changes, stateful devices lose their state and break connectivity if state is required for forwarding, while the endpoints would otherwise survive such a change. </del> Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-

Reviewer comments:
This paragraph is redundant with the previous paragraph, however, not sure I removed the right one now...

Revised text:
cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established.  Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-
Original text:
impacted by QUIC. QUIC is an end-to-end transport protocol.  No information in the <del> protocol header, even that which can be inspected, is meant to be mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del>  Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer <del> information.  However, it does imply that in-network operations that depend on modification of data are not possible without the cooperation of a QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </del>  Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks

Reviewer comments:
This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.

Revised text:
impacted by QUIC. QUIC is an end-to-end transport protocol.  No information in the  <ins> protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer  <ins> information.  However, it means in-network operations that depend on modification of data are not possible without the cooperation of an QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks
Original text:
which type of header is present.  The purpose of this bit is invariant across QUIC versions. <del> The long header exposes more information.  In version 1 of QUIC, it is used during connection establishment, including version negotiation, retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. </del>  Short headers contain only an optional destination connection ID and the spin bit for RTT measurement.  In version 1 of QUIC, they are

Reviewer comments:
This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.

Revised text:
which type of header is present.  The purpose of this bit is invariant across QUIC versions.  <ins> The long header exposes more information.  It contains a version number, as well as source and destination connection IDs for associating packets with a QUIC connection.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. In version 1 of QUIC, the long header is used during connection establishment to transmit crypto handshake data, perform version negotiation, retry, and send 0-RTT data. </ins> Short headers contain only an optional destination connection ID and the spin bit for RTT measurement.  In version 1 of QUIC, they are
Original text:
identifies the packet as a Version Negotiation packet.  QUIC version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various <del> Internet experiments, future standards, and greasing.  All deployed versions are maintained in an IANA registry (see </del>  Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long packet

Reviewer comments:
This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.

Revised text:
identifies the packet as a Version Negotiation packet.  QUIC version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various  <ins> Internet experiments, future standards, and greasing (RFC7801). All deployed versions are maintained in an IANA registry (see </ins> Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long packet
Original text:
packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path <del> observers.  The offset of the packet number is encoded in long </del>  headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is cryptographically obfuscated.

Reviewer comments:
This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.

Revised text:
packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path  <ins> observers.  The offset of the packet number can be decoded in long </ins> headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is cryptographically obfuscated.
Original text:
Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest <del> of the server's side of the TLS handshake, and initial 1-RTT data, if </del>  present. The Client Completion datagram contains at least one Handshake packet

Reviewer comments:
This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.

Revised text:
Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest  <ins> of the server's side of the TLS handshake, and 1-RTT data, if </ins> present. The Client Completion datagram contains at least one Handshake packet