jiebi/TextFlow huggingface dataset:
Original text:
explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation <del> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or protected in any way.  For other kinds of packets, version 1 of QUIC cryptographically obfuscates other information in the packet headers: </del>  packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet

Reviewer comments:
From NAME review.
This PR now as well.
cryptographically obfuscates An odd term. I see obfuscation to be non-cryptographic and cryptographic transformation to not be as weak as to be seen as obfuscation (but as encryption or secure hashing)
I replied by mail to Paul and explained that the header protection is kind of weak, so cryptographically protected might be too strong and this was his reply: Maybe the only thing is finding a better term for “cryptographically obfuscates”? I understand your reasoning but I still feel a little that this is doing a disservice to “cryptography”. But it was a comment, so I will leave it up to the authors. But maybe we can find a better term...?
Also a related comment on the same section from Eric Vyncke:
Note that PR is also editing this same part of the text.
I would say "protects" instead of "obfuscates". We have an analysis to support this claim (now cited in RFC 9001), we don't need to hedge. We used to be less certain (we did basically just invent this off the cuff at an interim meeting), but we're far more confident in stronger claims now.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...
Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it would be good to way that Retry packets are (forgibly) integrity-protected and that QUIC TPs later authenticate most of the contents of these packets.

Revised text:
explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation  <ins> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted.  Retry packets are (forgibly) integrity protected.  Transport parameters are used authenticate the contents of Retry packets later in the handshake.  For other kinds of packets, version 1 of QUIC cryptographically protects other information in the packet headers: </ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet
Original text:
As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to <del> reflection attacks.  Note that the list above is not exhaustive; other source ports might be considered reflection vectors as well. </del>  9.

Reviewer comments:
Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?

Revised text:
As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to  <ins> reflection attacks.  Note that following the general guidance for client implementations given in RFC6335, to use ephemeral ports in the range 49152-65535, has the effect of avoiding these ports.  Note that other source ports might be reflection vectors as well. </ins> 9.
Original text:
tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. <del> Some of the properties of the QUIC header used in network management are irrelevant to application-layer protocol operation and/or user privacy.  For example, packet number exposure (and echo, as proposed in this document), as well as connection establishment exposure for 1-RTT establishment, make no additional information about user traffic available to devices on path. At the other extreme, supporting current traffic classification methods that operate through the deep packet inspection (DPI) of application-layer headers are directly antithetical to QUIC's goal to provide confidentiality to its application-layer protocol(s); in these cases, alternatives must be found. </del> 7. This work is partially supported by the European Commission under

Reviewer comments:
The last two paragraphs of the security considerations section were for a (much earlier, probably pre-WG) version of the document. Now that -manageability is basically a wire image users' guide, they don't belong. So let's cut them.

Revised text:
tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant.  7. This work is partially supported by the European Commission under
Original text:
Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry <del> a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </del>  In version 1 of QUIC, the following additional information is exposed:

Reviewer comments:
clarify why CID is present in all headers but is also optional... see issue
The text appears inconsistent to me: "Short headers contain only an optional destination connection ID""source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ? Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ?

Revised text:
Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long headers carry  <ins> a destination connection ID, a variable-length field which, if not zero-length, can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit and as such need to be known from the long header packets. </ins> In version 1 of QUIC, the following additional information is exposed:
Original text:
version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801). <del> All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). </del>  source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not

Reviewer comments:
Text as proposed by Lars on list.
I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see URL); there is a huge range for experimental versions.
This was discussed on the list and has a proposed resolution; PR to be submitted.
Also this was commented by Eric Vyncke as well:

Revised text:
version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing (RFC7801).  <ins> An IANA registry contains the values of all standardized versions of QUIC, and may contain some proprietary versions (see Section 22.2 of QUIC-TRANSPORT).  However, other versions of QUIC can be expected to be seen in the Internet at any given time. </ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field which, if not
Original text:
a description of how common network management practices will be impacted by QUIC. <del> 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 enforced through integrity protection of the wire </del>  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.

Reviewer comments:
Wire image mutability is more subtle than "is completely immutable", and we get into the details later. New text is sufficient as contrast for TCP.
Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...

Revised text:
a description of how common network management practices will be impacted by QUIC.  <ins> QUIC is an end-to-end transport protocol; therefore, no information in the protocol header is intended to be mutable by the network. This property is enforced 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.
Original text:
to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of <del> acknowledgments. </del>  8.

Reviewer comments:
Section 7 talks about acknowledgment strategy, but it is not actually giving any examples of what the application can do. Since it is kind of a transport layer property and not an application layer property, it is unclear how an application [developer] can replace the "TCP like ack every other packet" functionality. Are there QUIC options to consider that do this? If so, why not mention those here?
I guess there is draft URL but not sure we want to add a reference...?
I guess we should at least add a reference to URL however that is currently expired :-(
I've sent a reply to Paul by email and waiting for a response now.
Unsure why we would specifically reference this rather than other work: draft-li-quic-optimizing-ack-in-wlan/, I expect the correct thing is to reference a WG RFC, and section 2.5 of RFC9065 is one way. Citing the WG ack frequency draft might additionally be useful.
For the record, this is what I replied by mail: "[MK] This is a whole research area of its own... however, I create an issue to see if people think adding some reference might be useful. There is a wg draft in QUIC for an extension to negotiate the ack frequency and there is another individual draft about strategies for WLANs. Still, this is also not really QUIC specific. Similar proposals also exists for TCP. The difference is that with TCP the network can also do ACK thinning which is not possible with QUIC anymore."
NAME but RFC9065 section 2.5 doesn't talk about acks at all... I still propose to add a reference to URL as this is a wg doc at least.

Revised text:
to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of  <ins> acknowledgments.  I-D.ietf-quic-ack-frequency describes an extension to signal the desired delay of acknowledgments and discusses use cases as well as implications for congestion control and recovery. </ins> 8.
Original text:
application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today <del> due to encapsulation, mechanisms for dynamic port assignments, and NATs. </del>  As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For

Reviewer comments:
The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR

Revised text:
application protocol and associated service to which processes connect" RFC6335.  The assumption that an application can be identified in the network based on the port number is less true today  <ins> due to encapsulation and mechanisms for dynamic port assignments, as also noted in RFC6335. </ins> As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For
Original text:
is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- <del> ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </del>  Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and

Reviewer comments:
Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded"

Revised text:
is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-  <ins> ordering than typical TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> Note that the 5-tuple of a QUIC connection can change due to migration.  In this case different flows are observed by the path and
Original text:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  14. QUIC version 1 does not specify a version negotiation mechanism in

Reviewer comments:
addresses
-- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? [MK] I guess that is the whole point here and I think the answer is no. You might see new experimental version that come and go quickly and are deployed only by one vendor but I don't think that will give you necessarily much insights about the application within the encrypted payload. Also experimental version are expected to be around for short times only and change quickly, thus you would be very busy to adapt your fingerprinting continuously. That's why the recommendation is to not do it. [Christian Huitema] Application developers will try to evolve the version number. If that cause the packets to be somehow discarded, this will have a very predictable result: all QUIC implementations will set the version number to 1 in the clear text header, while the "real" version number will be negotiated as part of the encrypted payload. If we follow that path, the network managers will not have any usable signal about the QUIC version, and the application developers will have to use more complex software and carry four useless bytes in the initial packets. Truth is, this is most likely what will happen, given natural trends. I don't know whether the text in the applicability statement will be enough to avoid that fate.
I don't think we can say more about not using the version number to identify QUIC. However do we want to mention the risk of fingerprinting? However, I guess that would rather something to add to the spec considerations in the applicability statement?

Revised text:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <ins> The QUIC Versions Registry established in QUIC allows for provisional registrations for experimentation.  Registration, also of experimental versions, is important to avoid collision.  Experimental versions should not be used long-term or registered as permanent to minimize the risk of fingerprinting based on the version number. </ins> 14. QUIC version 1 does not specify a version negotiation mechanism in
Original text:
existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional <del> change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del>  Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-

Reviewer comments:
Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable?

Revised text:
existing transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional  <ins> change of the local interface, the expiration of a temporary IPv6 address RFC8981, or the server indicating a preferred address Section 9.6 of QUIC. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-
Original text:
1.1. <del> The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document.  It's not shouting; when these words are capitalized, they have a special meaning as defined in RFC2119. </del>  2. 4.5.  [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on

Reviewer comments:
...addressing NAME
Middlebox vendors (and others as well) used to TCP want to assume that the smallest packet might be ack packets. This is not true in QUIC, and manageabiity draft may want to say something about it.
Thanks for writing this up!

Revised text:
1.1.  <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2. 4.5. <ins> Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. 4.6. </ins> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on