jiebi/TextFlow huggingface dataset:
Original text:
Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the <del> network without risking connection failure.  Further, the reply from </del>  the server cannot be observed, so observers on the network cannot know which parameters are actually in use.

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:
Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the  <ins> network without causing connection failure.  Further, the reply from </ins> the server cannot be observed, so observers on the network cannot know which parameters are actually in use.
Original text:
3.2. <del> This document focuses on QUIC version 1, and this section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </del>  Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain

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:
3.2.  <ins> This document focuses on QUIC version 1, and this Connection Confirmation section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </ins> Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain
Original text:
detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client <del> Hello.  Since these packets may be reordered in the network, 0-RTT </del>  packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets

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:
detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client  <ins> Hello.  Since packets may be reordered or lost in the network, 0-RTT </ins> packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets
Original text:
3.4.1. <del> If the ClientHello is not encrypted, it can be derived from the </del>  client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello.

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:
3.4.1.  <ins> If the ClientHello is not encrypted, SNI can be derived from the </ins> client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello.
Original text:
Connection IDs), the short header exposes at most only a single Connection ID. <del> 6.1. </del>  QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
Connection IDs), the short header exposes at most only a single Connection ID.  <ins> 7.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).
Original text:
The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 6.2. </del>  While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection.

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  <ins> 7.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection.
Original text:
migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 6.3. </del>  QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means.  <ins> 7.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new
Original text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 7. </del>  Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool.  <ins> 8. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared
Original text:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 8. </del>  This document has no actions for IANA. <del> 9. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  <ins> 9. </ins> This document has no actions for IANA.  <ins> 10. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for
Original text:
connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 10. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  <ins> 11. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture
Original text:
QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire <del> 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

Reviewer comments:
URL , can we be more specific here about the control signal we are talking about is QUIC protocol control signal not really other kind of control signal that the network might have? also here it is compared with TCP, should it also mention TCP with TLS?
I added the term "transport-layer" in PR . Does that help. I don't think TLS needs to be mentioned here.

Revised text:
QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire  <ins> image WIRE-IMAGE.  Encryption of most transport-layer 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
Original text:
it describes what is and is not possible with the QUIC transport protocol as defined.  QUIC-specific terminology used in this document is defined in QUIC- TRANSPORT.

Reviewer comments:
hi NAME NAME NAME PTAnotherL, reviewed the thread and I do think an additional 9065 ref here would be helpful.

Revised text:
it describes what is and is not possible with the QUIC transport protocol as defined. <ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on observation with active measurement techniques, for example, is therefore out of scope.  A more generalized treatment of network management operations on encrypted transports is given in RFC9065. </ins> QUIC-specific terminology used in this document is defined in QUIC- TRANSPORT.
Original text:
2.4. New QUIC connections are established using a handshake, which is <del> distinguishable on the wire and contains some information that can be passively observed. </del>  To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern

Reviewer comments:
Could the first 1200-byte QUIC packet be used to suspect a QUIC connection establishment ? [MK] Yes, I think if you look at the first packet as a whole you can be reasonably sure that you look at a quic packet. I guess this is an assumption throughout the whole document, as section 2.4 says: "New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed." [MK] Do we need to say more? EV> hummm I guess not even if the text in 2.4 is rather generic while the point in 3.1 is really specific. Perhaps adding which handshake properties are 'distinguishable' already in section 2.4 ?
proposes to fix this with a forward reference.

Revised text:
2.4. New QUIC connections are established using a handshake, which is  <ins> distinguishable on the wire (see sec-identifying for details), and contains some information that can be passively observed. </ins> To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern