jiebi/TextFlow huggingface dataset:
Original text:
1. <del> QUIC QUIC-TRANSPORT is a new transport protocol encapsulated in UDP and encrypted by default.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  The design focused on support of semantics for HTTP, which required changes to HTTP known as HTTP/3 QUIC-HTTP. </del>  Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not

Reviewer comments:
This didn't need to say encrypted twice. And it didn't really require changes to HTTP, just an adaptation. (I'm less happy about that part; it could probably use a tweak or two.)

Revised text:
1.  <ins> QUIC QUIC-TRANSPORT is a new transport protocol that is encapsulated in UDP.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  QUIC version 1 was designed primarily as a transport for HTTP, with the resulting protocol being known as HTTP/3 QUIC-HTTP. </ins> Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not
Original text:
Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a <del> PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, both during the handshake and for connection migration.  Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </del>  6.

Reviewer comments:
“Padding is used by QUIC to ensure” - please add a sentence that DPLPMTUD is another reason why you might expect QUIC Padding of specific packets after connection establishment, and refer to section in QUIC transport - or people may have a surprise when they suddenly see big probe packets in their logs:-)
I thought that this is what the sentence is about? The whole sentence says: "Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, ..." We can add a reference to the right section in the transport draft but sure we need another sentence? However, your point about being surprised to see big packets probably rather belongs into manageability...?
Ah sorry: I was trying to highlight that there are two places where I think QUIC might be expected to use padding... in the initial connection ... to verify the path supports the minimum size, and later whenever DPLPMTUD is invoked, to probe to check for a larger size. Two section refs would likely be useful. ... Yes, it could be mentioned in manageability - since often QUIC packets might be rather uniform in size with occasional DLPMTUD probes?
I created a PR to add references to the respective sections in the QUIC transport draft. Explaining in detail what padding is used for internally in QUIC wasn't really the point here. However, it's probably correct that the sentence should not just omit one usage (PLDMTUD) and reference probably don't hurt. Do we need still something for manageability? Or is that, at least partially, already addressed by ?
Looks good

Revised text:
Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a  <ins> PADDING frame to arbitrarily increase the size of packets.  Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, during the handshake (see Sections 8.1 and 14.1 of QUIC) and for path validation after connection migration (see Section 8.2 of QUIC) as well as for Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see Section 14.3 of QUIC). Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </ins> 6.
Original text:
Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, <del> 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 announce a different port number.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del>  Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

Reviewer comments:
It still says ALPN, though. ALPN doesn't have anything to do with using different ports; it has to do with using different protocols on the same port.
Yes, Martin already pointed this out. Fixed now. Do we need to say still more about ALPN?
I think that this refers to Alt-Svc (RFC 7838), which is mentioned in . You might also mention the not-yet-done SVCB record, but that might not be a good idea if you like the idea of publishing this.
SVCB record would just be an informational reference, no? So that shouldn't hold up publication. In this case I'd be okay to provide a pointer.
What do you meant by "ALPN doesn't enable use of other ports"?
The text here says "specifies the use of ALPN for service discovery which allows the server to use and announce a different port number". ALPN is not a service discovery mechanism, it's a protocol selection mechanism. ALPN is completely orthogonal to choice of ports. The purpose of ALPN is for client and server to agree on the protocol that is used. Your change to references in won't fix this issue. It does correctly cite the Alt-Svc sections of HTTP/3, but the surrounding text still says ALPN.

Revised text:
Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,  <ins> HTTP/3 (QUIC-HTTP Sections 3.1.1 and 3.1.2) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of
Original text:
and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that <del> identifies the packet as a Version Negotiation packet.  Many QUIC versions that start with 0xff implement IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents.  For example, QUIC version 1 uses version 0x00000001. </del>  Operators should expect to observe packets with other version <del> numbers as a result of various internet experiments and future </del>  standards. source and destination connection ID: short and long packet

Reviewer comments:
The first is not true really. There are 16 million versions that start with 0xff and we only published 34 drafts and implemented far fewer than that. The second is no longer true as we removed the reservation from the registry. Maybe just strike these sentences.
Time of publication statements are not generally useful in this context.

Revised text:
and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that  <ins> identifies the packet as a Version Negotiation packet.  Upon time of publishing of this document, QUIC versions that start with 0xff implement IETF drafts.  QUIC version 1 uses version 0x00000001. </ins> Operators should expect to observe packets with other version  <ins> numbers as a result of various Internet experiments and future </ins> standards. source and destination connection ID: short and long packet
Original text:
data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of <del> the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </del>  2.5.

Reviewer comments:
However there are cases where the congestion window can increase when 0-RTT continues to be sent. Some involve packet loss and so probably won't result in a net increase in the window, though the total number of packets might still exceed the initial window size. Others, like TLS HelloRetryRequest or large certificates, involve additional round trips in the handshake. The total amount of 0-RTT is also limited by remembered flow control values, though this is indirect as this counts stream data only and packets might be further padded.
The original text sounds correct - cwnd doesn't limit the total number of packets sent when some of those packets are declared lost - although we might want to clarify how the sender can still "retransmit" new packets in later RTTs.
I read this as saying that if your initial congestion window is 10 packets, then you can't send more than 10 packets of 0-RTT. That is not the case, even if it might commonly be that way. A client can send 0-RTT over multiple RTTs if you consider HelloRetryRequest and large handshake flights. In the extreme, there is no real limit to the amount of 0-RTT packets that can be exchanged.
qualification worksYou can't ACK 0-RTT packets in 0-RTT, so realistically it's probably 10 packets worth of 0-RTT data at most, but one could construct some edge cases so this is likely better.

Revised text:
data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of  <ins> the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </ins> 2.5.
Original text:
handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del>  2.6.

Reviewer comments:
This mixes two things: damage to packets that cause integrity protection to fail, and modification of Initial packets. How about:

Revised text:
handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in  <ins> QUIC packets.  Such alterations would cause the integrity check to fail, which results in the receiver discarding the packet.  Some parts of Initial packets could be altered by removing and re-applying the authenticated encryption without immediate discard at the receiver.  However, the cryptographic handshake validates most fields and any modifications in those fields will result in connection establishment failing later on. </ins> 2.6.
Original text:
An in-network observer assuming that a set of packets belongs to a QUIC flow can infer the version number in use by observing the <del> handshake: an Initial packet with a given version from a client to which a server responds with an Initial packet with the same version implies acceptance of that version. </del>  Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection

Reviewer comments:
This is not a declared invariant, but a property of version 1. As this pertains to version numbers, it might be assumed to be invariant. Maybe by scoping this to v1 explicitly here is the right answer.
lgtm

Revised text:
An in-network observer assuming that a set of packets belongs to a QUIC flow can infer the version number in use by observing the  <ins> handshake: for QUIC version 1 if the version number in the Initial packet from a client is the same as the version number in Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </ins> Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection
Original text:
Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection <del> migration; however, these flows can be associated with flows for which a version has been identified; see sec-flow-association. </del>  This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of

Reviewer comments:
This implies that the version of QUIC being used in a given flow can be determined simply by linking that flows to one with a handshake. That assumes that all the work we did to make flows difficult to link was for naught. Maybe "can" should be a "might" or something along those lines. I don't really like the implication that the attempt be made to link flows like this either.
In addition to this, the following text from Section 3.4 is not precise enough to be correct: The assumption that the same flow persists might be good in some cases, but this does not necessarily hold in the case that the endpoint address is used by an endpoint that requires non-zero-length connection IDs. This needs to be more precise if the claim is to hold.
Not sure what you mean by your second comment here. Of course if there is no connection ID you cannot associate it to anything...? What's missing? Can you propose something?
On re-reading, it seems to be a little clearer. It seems to be saying that an observer can match a particular connection ID with a flow and then, if the flow changes address at only one end without changing the connection ID, then it was subject to rebinding and can be assumed to be the same flow. However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty.

Revised text:
Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection  <ins> migration; however, it might be possible to associate a flow with a flow for which a version has been identified; see sec-flow- association. </ins> This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of
Original text:
2.8. <del> Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </del>  Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid

Reviewer comments:
addresses
I don’t have comments on the validity of the discussion text in section 12 and the described procedures, but I do wonder why this is information for an application designer, rather than for managing operations. Is this the correct ID for this information? and if its is, could it be explained a little more to what the app designer needs too know. This section seems rather devoid of useful references. please add some.
The split here was see as applicability is addressed at people who want to use QUIC (application designer but also people deploying QUIC at servers) and manageability for people who have to handle QUIC traffic (mainly network operator incl probably data centre operators). I know the split between the two last categories (deploying servers and managing a dc networks) is not always that clear. It's probably this section and the one about load balancing in manageability. I'm open to discuss where which section belongs. Do we need to bring this to the meeting? NAME what kind of reference are you thinking of?
On what to do in Manageability: I'd suggest we write some text that says: "QUIC provides a version negotiation process, that allows new versions to be introduced. The deployment of new versions is discussed in section 12 of [ID. ietf-quic-applicability]." Maybe even just as the first para of Manageability: Sect: 2.8. I meant add reference to section 6 in QUIC Transport - to both these documents
There is already section 2.8 on "Version Negotiation and Greasing" and section 3.1.1. on "Identifying Negotiated Version" in the manageability draft. Ideally the idea is to not have cross reference between manageability and applicability. I added a reference to section 6 of the quic-transport draft in manageability (see PR ). Not sure we need that reference also in the applicability draft because that section actually doesn't require any knowledge of the internals on how version negotiation works...

Revised text:
2.8.  <ins> Version Negotiation packets are used by the server to indicate that a requested version from the client is not supported (see section 6 of QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </ins> Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid
Original text:
3. <del> QUIC provides for 0-RTT connection establishment.  This presents opportunities and challenges for applications using QUIC. 3.1. </del>  A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. <del> Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </del>  <del> 3.2. </del>  Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same partial or even complete replay protection, which could be used to manage replay risk. <del> 3.3. </del>  Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes

Reviewer comments:
This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)

Revised text:
3.  <ins> QUIC provides for 0-RTT connection establishment.  Though the same facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for applications using QUIC. </ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive.  <ins> An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a risk of replay attack.  Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP- REPLAY. </ins>  <ins> 3.1. </ins> Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same partial or even complete replay protection, which could be used to manage replay risk.  <ins> 3.2. </ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes
Original text:
packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server <del> Hello, and some Initial Completion) must be at least 1200 octets long.  This protects against amplification attacks and verifies that the network path meets minimum Maximum Transmission Unit (MTU) requirements.  This is usually accomplished with either the addition of PADDING frames to the Initial packet, or coalescing of the Initial Packet with packets from other encryption contexts. </del>  The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the

Reviewer comments:
This seeks to address issue: "MTU or Min QUIC Packet Size? "
Sect 2.4: says: “the network path meets minimum Maximum Transmission Unit (MTU) requirements. “ There is text in the QUIC transport spec that the WG perfected a little in the final stages, and I think this use of MTU in sect 2.3 is suspect. As I see it, the requirements in QUIC are for a minimum supported QUIC packet size... not the MTU required to send this on an interface. ... This nuanced might be a really important detail for operations staff - where there is frequently a need to consider encapsulations and tunnels on interfaces of devices. ... A cross reference to the QUIC Spec may also help here.
NAME can you propose text?
Thought to be addressed in PR
PR merged
I think there are only 3 ways to fill up the space, so maybe enumerate them? I also wonder if we need to caution against stripping unused UDP payload or splitting up packets within a UDP datagram?

Revised text:
packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server  <ins> Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. </ins> The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the