jiebi/TextFlow huggingface dataset:
Original text:
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- <del> length connection ID is also strongly recommended when migration is supported. </del>  The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC.  Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee the same security properties as QUIC; if this is not possible, the

Reviewer comments:
This would be my proposal of a few small additions based on the discussion on list and at the last meeting (IETF-112) about privacy implications after migration regarding exposure of linkable user IP addresses to the server. The text doesn't give any recommendations but at least mentions it in the relevant sections.
I left a few suggestions, but this is heading in a good direction.

Revised text:
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-  <ins> length connection ID is also strongly recommended when active migration is supported.  If a connection is intentionally migrated to new path, a new connection ID is used to minimize linkability by network observers.  The other QUIC endpoint uses the connection ID to link different addresses to the same connection and entity if a non- zero-length connection ID is provided. </ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. <ins> Further, migration to an new address exposes a linkage between client addresses to the server and may expose this linkage also to the path if the connection ID cannot be changed or flows can otherwise be correlated.  When migration is supported, this needs to be considered with respective to user privacy. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee the same security properties as QUIC; if this is not possible, the
Original text:
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 <del> protected, but future QUIC versions will 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:
Currently the document uses "will". This might be a very valid assumption, but still it is an assumption hence I think it is better to use "May" instead of "Will".

Revised text:
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  <ins> protected, but future QUIC versions could 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:
encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be <del> consistently used by multiple transport protocols, however, these </del>  techniques are often limited to measurements within one or multiple cooperating domains.

Reviewer comments:
well I don't think transport protocol will be using any of the tools rather those tools can be used to observer multiple protocols

Revised text:
encrypt describes use of operations, administration and management (OAM) information).  Using network-layer approaches also has the advantage that common observation and analysis tools can be  <ins> consistently used for multiple transport protocols, however, these </ins> techniques are often limited to measurements within one or multiple cooperating domains.
Original text:
12. <del> QUIC, as defined in RFC9000, has a single congestion controller and </del>  recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, that have the same DiffServ

Reviewer comments:
as well
I didn't expect any other normative reference than RFC 9000, 9001 in this document. Why are other references needed to be listed in the normative reference? The reference list also have duplicate entries (i.e. same ref named differently) this need to be fixed as well.
I added this to PR - changed TLS1.3 and RFC6335 to informative, so only RFC8999, RFC9000, and RFC9001 should bee normative now.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:

Revised text:
12.  <ins> QUIC, as defined in QUIC, has a single congestion controller and </ins> recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, that have the same DiffServ
Original text:
behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC applications are encouraged to fail over to TCP if early packets do <del> not arrive at their destination I-D.ietf-quic-applicability, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec- udp-1312).  Admitting a few packets allows the QUIC endpoint to determine that the path accepts QUIC.  Sudden drops afterwards will result in slow and costly timeouts before abandoning the connection. </del>  4.6. black-holing an active connection when the address changes. Note that some source ports are assumed to be reflection attack <del> vectors by some servers; see Section 8.1 of I-D.ietf-quic- applicability.  As a result, NAT binding to these source ports can result in that traffic being blocked. </del>  4.7. short-term consistency between the PMTU for flows can help avoid an endpoint using a PMTU that is inefficient.  The IP cache can also influence the PMTU value of other IP flows that use the same path <del> RFC8899, including IP packets carrying protocols other than QUIC. </del>  The representation of an IP path is implementation-specific RFC8201. 5.

Reviewer comments:
as well
There are some outdated references those I goes will go away with further revisions. However, there are duplicate references those I believe need to be fixed manually. -- Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'. -- Duplicate reference: RFC8899, mentioned in 'RFC8899', was also mentioned in 'DPLPMTUD'.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:

Revised text:
behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC applications are encouraged to fail over to TCP if early packets do  <ins> not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that the path accepts QUIC.  Sudden drops afterwards will result in slow and costly timeouts before abandoning the connection. </ins> 4.6. black-holing an active connection when the address changes. Note that some source ports are assumed to be reflection attack  <ins> vectors by some servers; see Section 8.1 of QUIC-APPLICABILITY.  As a result, NAT binding to these source ports can result in that traffic being blocked. </ins> 4.7. short-term consistency between the PMTU for flows can help avoid an endpoint using a PMTU that is inefficient.  The IP cache can also influence the PMTU value of other IP flows that use the same path  <ins> DPLPMTUD, including IP packets carrying protocols other than QUIC. </ins> The representation of an IP path is implementation-specific RFC8201. 5.
Original text:
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 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. </del>  Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks

Reviewer comments:
URL, I am not sure I get what this paragraph is supposed to mean. Number of things - first of all it is not clear that integrity protection actually simply the troubleshooting without defining that kind of troubleshooting we are referring to here and who is doing those, even though it is true that now network nodes cannot modify the transport layer information. we are making a statement that in-network operations depends on modification of data, what is the data here? payload? header information? both? I think here we can reference to the I-D.ietf-tsvwg-transport-encrypt to setup the background information required to parse the statement correctly. I am not sure how a proxy here can support modification of data. Yes, that is my read of this last of the statement. Hence, hence we might want to clarify what is the scope of this collaboration that we are referring to .
addressed by

Revised text:
signaling means that less information is visible to the network than is the case with TCP.  <ins> Integrity protection can also simplify troubleshooting at the end points as none of the nodes on the network path can modify transport layer information.  However, it means in-network operations that depend on modification of data (e.g. see RFC9065 are not possible without the cooperation of an QUIC endpoint.  Such cooperation 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:
symmetry of a flow (whether primarily client-to-server, primarily server-to-client, or roughly bidirectional, as input to basic traffic classification techniques) can be inferred through the measurement of <del> data rate in each direction.  While QUIC traffic is protected and ACKs may be padded, padding is not required. </del>  3.8.

Reviewer comments:
URL I am not sure what does the last sentence supposed to add to the context and see it is something more important for the applicability part than manageability part.
I already clarified the sentence in PR related to issue . Or is this the wrong reference?
ok, fine with me.
URL, padding and padding frames have been discussed/mentioned several times but I haven't got a clear indication on what does the padding to the manageability. Please point me to the description if I am mistaken.

Revised text:
symmetry of a flow (whether primarily client-to-server, primarily server-to-client, or roughly bidirectional, as input to basic traffic classification techniques) can be inferred through the measurement of  <ins> data rate in each direction.  Note that QUIC packets containing only control frames (such as ACK-only packets) may be padded.  Padding, though optional, may conceal connection roles or flow symmetry information. </ins> 3.8.
Original text:
3.3. <del> 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 RFC3449.  Distinguishing ACK packets is possible in TCP, but is 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 not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </del>  3.4.

Reviewer comments:
URL, what is a pure-acknowledgment (ACK) packet?

Revised text:
3.3.  <ins> Some deployed in-network functions distinguish packets that carry only acknowledgment (ACK-only) information from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling RFC3449.  Distinguishing ACK packets is possible in TCP, but is 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 not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </ins> 3.4.
Original text:
Limited RTT measurement is possible by passive observation of QUIC traffic; see sec-rtt.  No passive measurement of loss is possible with the present wire image.  Limited observation of upstream <del> congestion may be possible via the observation of CE markings on ECN- enabled QUIC traffic. </del>  On-path devices can also make measurements of RTT, loss and other performance metrics when information is carried in an additional

Reviewer comments:
URL, clarify that the CE marking is observed at IP packet header and also provide a ref to CE marking

Revised text:
Limited RTT measurement is possible by passive observation of QUIC traffic; see sec-rtt.  No passive measurement of loss is possible with the present wire image.  Limited observation of upstream  <ins> congestion may be possible via the observation of CE markings in the IP header RFC3168 on ECN-enabled QUIC traffic. </ins> On-path devices can also make measurements of RTT, loss and other performance metrics when information is carried in an additional
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).  A 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:
instead of sec 9 (migration)
URL, is this referring to the right section? if yes then can it be made specific to a particular subsection? I noted that RFC9000 describes the potential amplification attack in section 21.3
Yes this should probably be section 8; 21.3 is not relevant here.

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 8 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:
either through timers or through least-recently-used eviction, depending on application requirements. <del> While QUIC has no clear network-visible end-of-connection signal and </del>  therefore does require timer-based state removal, the QUIC handshake indicates confirmation by both ends of a valid bidirectional transmission.  As soon as the handshake completed, timers should be

Reviewer comments:
URL, in the section 4.2, end-of-flow and end-of-connection both are used in a way that they both point to the same observation event. if these are same then lets stick to only one of them otherwise lets describe in a way that they point to different observation points.
let's use end-of-flow consistently.

Revised text:
either through timers or through least-recently-used eviction, depending on application requirements.  <ins> While QUIC has no clear network-visible end-of-flow signal and </ins> therefore does require timer-based state removal, the QUIC handshake indicates confirmation by both ends of a valid bidirectional transmission.  As soon as the handshake completed, timers should be
Original text:
acceptable to not support migrations of active QUIC connections that are not visible to the network functions performing the DDoS detection.  As soon as the connection blocking is detected by the <del> client, the client may be able to rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del>  Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS

Reviewer comments:
Section 4.7 of the manageability draft needs a reference to the fast resumption mechanism.
this s 0-RTT session resumption as explained early in the doc and respectively referred there to the QUIC spec. Would it help to change "fast resumption" to "0-RTT session resumption"?
I think so.
where was in the document 0-RTT session resumption explained? I might have missed it.
He have separate figures for that in the handshake section
However it seems we use the term "0-RTT connection resumption" there so, we should probably do a s/connection/session/ there as well.

Revised text:
acceptable to not support migrations of active QUIC connections that are not visible to the network functions performing the DDoS detection.  As soon as the connection blocking is detected by the  <ins> client, the client may be able to rely on the 0-RTT session resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS
Original text:
distinguishable from other UDP traffic by a passive observer in the network. <del> The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del>  While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

Reviewer comments:
Looks good to me. thanks
URL, this needs examples. what about DNS over QUIC as some defined over QUIC? but I would love to get educated on the deployment part and refer that from this doc to support this statement.

Revised text:
distinguishable from other UDP traffic by a passive observer in the network.  <ins> At the time of writing, two application bindings for QUIC have been published or adopted by the IETF: HTTP/3 QUIC-HTTP and DNS I-D.ietf- dprive-dnsoquic.  These are both known to have active internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-
Original text:
RFC4787 requires a network state timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, a QUIC endpoint <del> can experience lower timeouts, in the range of 30 to 60 seconds. </del>  In contrast, RFC5382 recommends a state timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-

Reviewer comments:
Looks good to me
URL, where does this data come from? any reference will be great here.
NAME is there something we can cite here?
The best public data I'm aware of is slide 10 of: URL

Revised text:
RFC4787 requires a network state timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, a QUIC endpoint  <ins> can experience lower timeouts, in the range of 30 to 60 seconds QUIC- TIMEOUT. </ins> In contrast, RFC5382 recommends a state timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-
Original text:
4.4. <del> QUIC flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or deadlock. </del>  Deadlocks in flow control are possible for any protocol that uses QUIC, though whether they become a problem depends on how

Reviewer comments:
addresses
LGTM
URL should this be pointing to Section 2.2 or section 4.0 , flow control credit is described there? I also think it will be good if section 4.4 of this document points to Section 4.0 of RFC9000. specially when it talks about flow control credit updates.
I believe this reference was supposed to point to the following normative statement in 2.2: Section 4 is also relevant but there is also a pointer to section 4 at the end of section 2.2....
I don't think it is obvious here, also introducing "flow control credit" here does not help much without referencing to section 4.0 of RFC9000.
PR add a reference to section 4 of RFC9000 in section 4.4. of the applicability draft. I still think having the link to section 2.2 of RFC900 in section 4.3 is more clear. flow control credit is not a QUIIC specific term.

Revised text:
4.4.  <ins> QUIC flow control Section 4 of QUIC provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or deadlock. </ins> Deadlocks in flow control are possible for any protocol that uses QUIC, though whether they become a problem depends on how