jiebi/CodeConvo huggingface dataset:
Change:
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:

Discussion:
12. <del> QUIC, as defined in RFC9000, has a single congestion controller and </del> <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
Change:
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:

Discussion:
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> <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 <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> <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 <del> RFC8899, including IP packets carrying protocols other than QUIC. </del> <ins> DPLPMTUD, including IP packets carrying protocols other than QUIC. </ins> The representation of an IP path is implementation-specific RFC8201. 5.
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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> <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.
Change:
URL, what is a pure-acknowledgment (ACK) packet?

Discussion:
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> <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.
Change:
URL, clarify that the CE marking is observed at IP packet header and also provide a ref to CE marking

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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-
Change:
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

Discussion:
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> <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-
Change:
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.

Discussion:
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> <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
Change:
Section 4.8 of manageability draft expects that a per-flow basis DSCP and ECMP routing policy is used to ensure same treatment for all the packets belonging to same QUIC connection. I was wondering how does path migration impacts this? As the new path ,potentially via another network, has no idea about QUIC connection insuring all packets belonging to the same QUIC connection get uniform treatment will be difficult. what am I missing here?
During path migration the congestion control is reset and therefore there is no assumption anymore that those packets need to be treated similarly.
Ok then packets belonging to same QUIC connection can be treated differently after path migration. I think it would be good to clarify it.
This is effectively already what the manageability draft says because it says QoS handling should be applied on a per flow basis where a flow is the 5 tuple. If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID.
NAME can we close this issue?
Potentially yes, but would have been better to put a ref. here to the section where this "If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID." is discussed. if things are not discussed or referred in one place then one has to infer the same reasoning/conclusion, which I think not always obvious.
Okay, I added another clarifying sentence and a reference to section 3.5 in PR

Discussion:
It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not <del> per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment. </del> <ins> per-packet) and as such that all packets belonging to the same active QUIC connection get uniform treatment. </ins> Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to

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 connnection can change due to migration.  In this case different flows are observed by the path and maybe be treated differently, as congestion control is usualy reset on migration (see also sec-flow-association). </ins> 4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by
Change:
As this document does not use normative language and still makes number of recommendations, I think it is best that the abstract and/or introduction of thid document need some text to clarify how the readers should interpret those recommendations URL
What exactly would you propose?
hmm, the reason for not using normative language would be sufficient I think.
Not sure what to write. There is no requirement that normative language must be used in RFC and moreover this is not a protocol specification. However, these are not something that we should note in the abstract.
Can you make a proposal?
I would simply expect the reason of not using normative language in this document (I remember there was some discussions on it), perhaps best fit in the introduction section.
There is nothing really specific here. If you look at the other issue they don't say much other than that we only provide recommendation and therefore don't need normative language. I would prefer to not say anything as that could rather give a wrong impression.

Discussion:
This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on <del> network operations involving QUIC traffic.  Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. </del> <ins> network operations involving QUIC traffic.  It is intended as a "user's manual" for the wire image, providing guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. </ins> 1.
Change:
URL, why are we so specific about TLS crypto operations here, it could be anything like later mentioned (waiting for a response to be send) or simply work load in the endpoints. Overall the inclusion of the transport- and application-layer delay in RTT measurements has been described in different ways without mentioning why one matters more than the others in certain context while pointing to same thing. This need to be fixed.
The section you noted, is about the the handshake. As there is no data during the handshake, the main app-layer delay would be the crypto. Yes, there can always be additional random delays due to processing also on the NIC but these are usually smaller and therefore less relevant. Not sure what kind of change would be needed here.
it would be good to refer to same events that may cause application-layer delay, rather giving two different examples for the same application-layer delay.
Still not sure what you would like to see here. Can you make a proposal?
Alternate proposal: remove the example?
would actually work, but there are examples of application-layer delay in that later section, may be you want to bring that up here and only use one set of potential reasons for application-layer delay for the whole section.

Discussion:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay (the latter mainly caused by the asymmetric crypto operations associated with the TLS handshake) at both sides. </del> <ins> necessarily includes any transport- and application-layer delay at both endpoints. </ins> 3.8.2.
Change:
This is a good piece of information. However, I could not put it into the context of this document. Please clarity how this TAPS arch matters here. URL
looks good to me. Now it is more clear that the following paragraph is actually about giving more context to fallback mechanism.

Discussion:
is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system <del> with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network. Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> with a common API for multiple protocols.  This is particularly relevant for QUIC as it addresses the implications of fallback among multiple protocols. Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided.  In general, a application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the