jiebi/CodeConvo huggingface dataset:
Change:
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.
Minor editorial nit.

Discussion:
See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for <del> applications using QUIC, as well. </del> <ins> applications using QUIC, as well.  Considerations on linkability, replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee
Change:
to the security considerations section?
Cross protocol attacks, traffic analysis, and migration are discussed as well in the transport draft, so this pointer might not be absolutely necessary. However, we might still want to have it and then I think these are the relevant sections to refer to.
Applicability to me seems to be mostly targeted to non-H3 users of QUIC, so I'm not sure the H3-specific considerations need to be mentioned here.
My thinking was to add that as reference for other applications that might need to consider similar attacks/security issues. At least half of the points in the hhtp/3 sec considerations are really http specific and probably don't have value for other applications but there are a number of points which are more general. Those points are to some extend probably also covered by the transport draft but may be explained in more detail in the h3 draft.

Discussion:
connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <ins> Further QUIC-HTTP provides security considerations specific to HTTP. However, discussions such as on cross protocol attacks, traffic analysis and padding, or migration might be relevant for other applications using QUIC as well. </ins> 14. This work is partially supported by the European Commission under
Change:
This sentence is rather supposed to explain what's done in QUIC then giving any recommendation, therefore we can simply remove the "recommended" phrasing.

Discussion:
endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making <del> these connections identifiable based on the usage of the spin bit, it is recommended that all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </del> <ins> these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </ins> When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).
Change:
The text is good however I don't understand its placement in the draft fully. Shouldn't this paragraph go into the previous section or even in an own section? I know the issue, that this PR is addressing, was about DDoS but if we want to have it in the DDoS section we need probably some more words explaining how Retry should be used in this case. Currently it comes a bit out of nothing and interrupts the reading flow of the rest of the text...
I am not really sure at all that the existing DDoS guidance is good advice; we have a somewhat more robust plan in quic-lb, which perhaps we should reference?
for that matter, the Retry packet does not make an appearance in this section at all, which seems like an oversight.
Yes to both. Can you provide an PR?
Yes, please assign this issue to me.

Discussion:
clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. <ins> TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for
Change:
which is about "Network-visible information about QUIC flows". They are mentioned once, based on a recent edit, but the text before that does not introduce them or explain what they are. Maybe we can add a few more sentences also making sure that even though they could be observed in the client initial, they cannot be changed nor observed form the server (to understand final negotiation/support).

Discussion:
versions of the protocol, or even be negotiated during the handshake via the use of transport parameters. <ins> Even though transport parameters transmitted in the client initial are obserable by the network, they cannot be modified by the network without risking connection failure.  Further, the negotiated reply from the server cannot be observed, so observers on the network cannot know which parameters are actually in use. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a
Change:
The text says: “and are emphatically NOT RECOMMENDED.” I think I would agree with a strong encouragement to not do this, but I would suggest to not use upper case letters at this point, and I’m not sure “emphatically” is a great word in a RFC :-). I’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address, because QUIC over radio (of various types) can be significantly more expensive or lower performant than TCP, precisely because the control/ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods.
I created an PR to address the first point. Regarding the second point: NAME do you want to propose additional text? However, if I think that would go the into applicability...?
Suggestion for text: On network paths where there is significant asymmetry, the transmission of QUIC ACKs can reduce the efficient use of network capacity or transmission opportunities. This effect occurs when the return capacity is significantly more constrained than the forward capacity, or the cost of transmission per packet is a significant component of the total transmission cost. Reducing the ratio of acknowledgements to data at the QUIC receiver can improve link utilization and reduce link transmission costs.

Discussion:
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 <del> packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. </del> <ins> 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> 4.7.
Change:
I think the following sentence has issues: “In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable.” I’m not sure I understand “In case” I’m not sure this should be upper case RFC2119, unless we decide to also make normative recommendations in other places. “allowing”..”unavailable” makes this award to read.
2119 issue also noted in .

Discussion:
payload data. Moreover, while encryption (in this case TLS) is inseparably <del> integrated with QUIC, TLS negotiation over TCP can be blocked.  In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable. </del> <ins> integrated with QUIC, TLS negotiation over TCP can be blocked.  If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </ins> 3.
Change:
Does this make it easier to understand?
NAME is this better?
“Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance. “ could this be: “Server deployments with load balancers and other routing infrastructure that depends on observing the payload of IP packets need to ensure that this infrastructure consistently routes all the QUIC packet belonging to a connection to the same server instance.” Seems like that is helpful. Is there a relevant section in the OPS draft where the reader should be directed?
Not sure if you addition of "that depends on observing the payload of IP packets" is that helpful in the sentence. The whole point here that if you use load balancers with QUIC, looking only at the IP might not be enough. NAME can you have a look how to phrase this?
Is this referring to sec 9.1 of the applicability draft? Why refer to the ops draft when the current reference (QUIC-LB) has everything you would want to know about the subject? I don't understand what Gorry's new clause adds. In fact, the IP address is not in the payload so I don't believe it's even accurate. Are you trying to distinguish between L7 and L4 load balancers here?
I couldn't work out what the current sentence means what does "correctly" mean?
OK, I can reword this.
This is left open as there is a pending rewrite of the NAT section.
looks good to me.

Discussion:
Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently <del> routes packets to the correct server instance.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  This ensures that there is no need to for servers and infrastructure to coordinate routing information for each connection. See QUIC-LB for more information. </del> <ins> routes packets to the server instance that has the connection state, even if addresses, ports, and/or connection IDs change.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  For an example of this technique, see QUIC-LB. </ins> 10.2.
Change:
It seems to me that QUIC is no different to other transports in respect of being able to utilise other port numbers, and it would be worth noting that this is normal. The present text might perhaps suggest this is specific to QUIC. Should the text reference RFC 7605 or something else just to explain ports don't imply specific application behaviour, but could infer this?.
The title of the pull request was cause for a momentary flutter - in that I don't see the port as carrying anything other than a reference to a convention - but the text is very good.

Discussion:
2.3. Applications that have a mapping for TCP as well as QUIC are expected <del> to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </del> <ins> to use the same port number for both services.  However, as for all other IETF transports RFC7605, there is no guarantee that a specific application will use a given registered port, or that a given port carries traffic belonging to the respective registered service, especially when application layer information is encrypted.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </ins> Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the
Change:
I set the ready to merge label but there are merge conflict, so please don't merge before accepting my suggestions...
[Ding2015] and [IPIM] are in the references of the manageability draft, but aren't actually... referenced anywhere. That suggests either some text is missing or these entries are spurious.
Yes this has been already flagged by and is fixed in (which we will all merge on Monday when Brain is back). Thanks anyway!
Unused Reference: 'Ding2015' is defined on line 1272, but no explicit reference was found in the text Unused Reference: 'IPIM' is defined on line 1293, but no explicit reference was found in the text
Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'.
There are two paragraphs that include 2119-language: RFC 2119 keyword, line 578: '... RECOMMENDED. First, it only provid...' RFC 2119 keyword, line 969: '... NOT RECOMMENDED....' Should these be made lowercase or is a 2119 paragraph needed?
I see what was done. Looks ready to go.

Discussion:
The spin bit provides an additional method to measure per-flow RTT from observation points on the network path throughout the duration <del> of a connection.  Endpoint participation in spin bit signaling is </del> <ins> of a connection, following the principles of protocol measurability laid out in IPIM.  Endpoint participation in spin bit signaling is </ins> optional in QUIC.  That is, while its location is fixed in this version of QUIC, an endpoint can unilaterally choose to not support "spinning" the bit.  Use of the spin bit for RTT measurement by

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 <del> packets based on packet size are likely to fail, and are not </del> <ins> packets based on packet size are very likely to fail, and are not </ins> 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.

QUIC is deliberately designed to fail rather than persist when the network cannot support its operation.  For HTTP/3, this extends to recommending a fallback to TCP-based versions of HTTP rather than <del> persisting with a QUIC connection that might be unstable.  And I- D.ietf-quic-applicability recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </del> <ins> persisting with a QUIC connection that might be unstable.  And QUIC- APPLICABILITY recommends TCP fallback for other protocols on the basis that this is preferable to sudden connection errors and time outs.  Furthermore, wide deployment of NATs with this behavior </ins> hinders the use of QUIC's migration function, which relies on the ability to change the connection ID any time during the lifetime of a QUIC connection.
Change:
URL must be postprocessed to become metrics.
Waiting for more reviews, e.g. from NAME before we can merge.
The text describes an example for measuring the average RTT. I like that, but I think we should call out a little that the mean RTT is only one metric. When looking at management info, I'm often interested in min/max and variance... So: “A simple linear smoothing... to get a more stable estimate”. Quite so for a table average RTT. I’d prefer it if we could say something about RTT variance at this point. To me it is important that RTT measurements are clear, and we should never assume in a Spec that RTT is something specific, but more generally an estimate that needs to consider the variance.

Discussion:
acknowledgements) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the <del> application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del> <ins> application. </ins> However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are

edge observed in the upstream direction and that observed in the downstream direction, and vice versa. <ins> Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). </ins> 4. In this section, we review specific network management and
Change:
Beware those who want to do something else.
Isn't this already covered by the next section on "Flow Control Deadlocks"? If not, what's missing? And can we just add a sentence or two there?
Though the specification does not insist upon it, most implementations will assume that stream data is reliably delivered in order. This means that senders will send until every byte is delivered or they decide to reset the stream (possibly based on STOP_SENDING). And it means that receivers won't make data available until a contiguous span of bytes starting at the last unread offset are available. Implementations might act differently, but variations from this behaviour would need to be agreed by both endpoints.
NAME can you propose text?

Discussion:
4.3. <ins> QUIC streams enable ordered and reliable delivery.  Though it is possible for an implementation to provide options that use streams for partial reliability or out-of-order delivery, most implementations will assume that data is reliably delivered in order. Under this assumption, an endpoint that receives stream data might not make forward progress until data that is contiguous with the start of a stream is available.  In particular, a receiver might withhold flow control credit until contiguous data is delivered to the application; see Section 2.2 of QUIC.  To support this receive logic, an endpoint will send stream data until it is acknowledged, ensuring that data at the start of the stream is sent and acknowledged first. An endpoint that uses a different sending behavior and does not negotiate that change with its peer might encounter performance issues or deadlocks. 4.4. </ins> 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
Change:
This didn't need to say encrypted twice. And it didn't really require changes to HTTP, just an adaptation. (I'm less happy about that part; it could probably use a tweak or two.)

Discussion:
1. <del> QUIC QUIC-TRANSPORT is a new transport protocol encapsulated in UDP and encrypted by default.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  The design focused on support of semantics for HTTP, which required changes to HTTP known as HTTP/3 QUIC-HTTP. </del> <ins> QUIC QUIC-TRANSPORT is a new transport protocol that is encapsulated in UDP.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  QUIC version 1 was designed primarily as a transport for HTTP, with the resulting protocol being known as HTTP/3 QUIC-HTTP. </ins> Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not
Change:
“Padding is used by QUIC to ensure” - please add a sentence that DPLPMTUD is another reason why you might expect QUIC Padding of specific packets after connection establishment, and refer to section in QUIC transport - or people may have a surprise when they suddenly see big probe packets in their logs:-)
I thought that this is what the sentence is about? The whole sentence says: "Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, ..." We can add a reference to the right section in the transport draft but sure we need another sentence? However, your point about being surprised to see big packets probably rather belongs into manageability...?
Ah sorry: I was trying to highlight that there are two places where I think QUIC might be expected to use padding... in the initial connection ... to verify the path supports the minimum size, and later whenever DPLPMTUD is invoked, to probe to check for a larger size. Two section refs would likely be useful. ... Yes, it could be mentioned in manageability - since often QUIC packets might be rather uniform in size with occasional DLPMTUD probes?
I created a PR to add references to the respective sections in the QUIC transport draft. Explaining in detail what padding is used for internally in QUIC wasn't really the point here. However, it's probably correct that the sentence should not just omit one usage (PLDMTUD) and reference probably don't hurt. Do we need still something for manageability? Or is that, at least partially, already addressed by ?
Looks good

Discussion:
Similarly, an application has usually no control about the length of a QUIC packet on the wire.  QUIC provides the ability to add a <del> PADDING frame to arbitrarily increase the size of packets. Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, both during the handshake and for connection migration.  Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </del> <ins> PADDING frame to arbitrarily increase the size of packets.  Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size, during the handshake (see Sections 8.1 and 14.1 of QUIC) and for path validation after connection migration (see Section 8.2 of QUIC) as well as for Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see Section 14.3 of QUIC). Padding can also be used by an application to reduce leakage of information about the data that is sent.  A QUIC implementation can expose an interface that allows an application layer to specify how to apply padding. </ins> 6.