jiebi/CodeConvo huggingface dataset:
Change:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.

Discussion:
4.7. <ins> Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP messages (e.g., IPv6 Packet Too Big messages).  Given known attacks with the use of ICMP messages, the use of PLPMTUD in QUIC has been designed to safely use but not rely on receiving ICMP feedback (see Section 14.2.1. of QUIC-TRANSPORT). Networks are recommended to forward these ICMP messages and retain as much of the original packet as possible without exceeding the minimum MTU for the IP version when generating ICMP messages as recommended in RFC1812 and RFC4443. 4.8. </ins> 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

exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. <del> 4.8. </del> <ins> 4.9. </ins> QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding.

timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding. <del> 4.8.1. </del> <ins> 4.9.1. </ins> NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their

violates the best common practice to avoid "port overloading" as described in RFC4787. <del> 4.8.2. </del> <ins> 4.9.2. </ins> Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security

to the attacker address and thus allow an observer to break the connection. <del> 4.9. </del> <ins> 4.10. </ins> RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise
Change:
It still says ALPN, though. ALPN doesn't have anything to do with using different ports; it has to do with using different protocols on the same port.
Yes, Martin already pointed this out. Fixed now. Do we need to say still more about ALPN?
I think that this refers to Alt-Svc (RFC 7838), which is mentioned in . You might also mention the not-yet-done SVCB record, but that might not be a good idea if you like the idea of publishing this.
SVCB record would just be an informational reference, no? So that shouldn't hold up publication. In this case I'd be okay to provide a pointer.
What do you meant by "ALPN doesn't enable use of other ports"?
The text here says "specifies the use of ALPN for service discovery which allows the server to use and announce a different port number". ALPN is not a service discovery mechanism, it's a protocol selection mechanism. ALPN is completely orthogonal to choice of ports. The purpose of ALPN is for client and server to agree on the protocol that is used. Your change to references in won't fix this issue. It does correctly cite the Alt-Svc sections of HTTP/3, but the surrounding text still says ALPN.

Discussion:
Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, <del> HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and announce a different port number.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del> <ins> HTTP/3 (QUIC-HTTP Sections 3.1.1 and 3.1.2) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the binding to QUIC as well as the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of
Change:
The first is not true really. There are 16 million versions that start with 0xff and we only published 34 drafts and implemented far fewer than that. The second is no longer true as we removed the reservation from the registry. Maybe just strike these sentences.
Time of publication statements are not generally useful in this context.

Discussion:
and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that <del> identifies the packet as a Version Negotiation packet.  Many QUIC versions that start with 0xff implement IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents.  For example, QUIC version 1 uses version 0x00000001. </del> <ins> identifies the packet as a Version Negotiation packet.  Upon time of publishing of this document, QUIC versions that start with 0xff implement IETF drafts.  QUIC version 1 uses version 0x00000001. </ins> Operators should expect to observe packets with other version <del> numbers as a result of various internet experiments and future </del> <ins> numbers as a result of various Internet experiments and future </ins> standards. source and destination connection ID: short and long packet
Change:
However there are cases where the congestion window can increase when 0-RTT continues to be sent. Some involve packet loss and so probably won't result in a net increase in the window, though the total number of packets might still exceed the initial window size. Others, like TLS HelloRetryRequest or large certificates, involve additional round trips in the handshake. The total amount of 0-RTT is also limited by remembered flow control values, though this is indirect as this counts stream data only and packets might be further padded.
The original text sounds correct - cwnd doesn't limit the total number of packets sent when some of those packets are declared lost - although we might want to clarify how the sender can still "retransmit" new packets in later RTTs.
I read this as saying that if your initial congestion window is 10 packets, then you can't send more than 10 packets of 0-RTT. That is not the case, even if it might commonly be that way. A client can send 0-RTT over multiple RTTs if you consider HelloRetryRequest and large handshake flights. In the extreme, there is no real limit to the amount of 0-RTT packets that can be exchanged.
qualification worksYou can't ACK 0-RTT packets in 0-RTT, so realistically it's probably 10 packets worth of 0-RTT data at most, but one could construct some edge cases so this is likely better.

Discussion:
data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of <del> the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </del> <ins> the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). </ins> 2.5.
Change:
This mixes two things: damage to packets that cause integrity protection to fail, and modification of Initial packets. How about:

Discussion:
handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del> <ins> QUIC packets.  Such alterations would cause the integrity check to fail, which results in the receiver discarding the packet.  Some parts of Initial packets could be altered by removing and re-applying the authenticated encryption without immediate discard at the receiver.  However, the cryptographic handshake validates most fields and any modifications in those fields will result in connection establishment failing later on. </ins> 2.6.
Change:
This is not a declared invariant, but a property of version 1. As this pertains to version numbers, it might be assumed to be invariant. Maybe by scoping this to v1 explicitly here is the right answer.
lgtm

Discussion:
An in-network observer assuming that a set of packets belongs to a QUIC flow can infer the version number in use by observing the <del> handshake: an Initial packet with a given version from a client to which a server responds with an Initial packet with the same version implies acceptance of that version. </del> <ins> handshake: for QUIC version 1 if the version number in the Initial packet from a client is the same as the version number in Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </ins> Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection
Change:
This implies that the version of QUIC being used in a given flow can be determined simply by linking that flows to one with a handshake. That assumes that all the work we did to make flows difficult to link was for naught. Maybe "can" should be a "might" or something along those lines. I don't really like the implication that the attempt be made to link flows like this either.
In addition to this, the following text from Section 3.4 is not precise enough to be correct: The assumption that the same flow persists might be good in some cases, but this does not necessarily hold in the case that the endpoint address is used by an endpoint that requires non-zero-length connection IDs. This needs to be more precise if the claim is to hold.
Not sure what you mean by your second comment here. Of course if there is no connection ID you cannot associate it to anything...? What's missing? Can you propose something?
On re-reading, it seems to be a little clearer. It seems to be saying that an observer can match a particular connection ID with a flow and then, if the flow changes address at only one end without changing the connection ID, then it was subject to rebinding and can be assumed to be the same flow. However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty.

Discussion:
Negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection <del> migration; however, these flows can be associated with flows for which a version has been identified; see sec-flow-association. </del> <ins> migration; however, it might be possible to associate a flow with a flow for which a version has been identified; see sec-flow- association. </ins> This document focuses on QUIC Version 1, and this section applies only to packets belonging to Version 1 QUIC flows; for purposes of
Change:
addresses
I don’t have comments on the validity of the discussion text in section 12 and the described procedures, but I do wonder why this is information for an application designer, rather than for managing operations. Is this the correct ID for this information? and if its is, could it be explained a little more to what the app designer needs too know. This section seems rather devoid of useful references. please add some.
The split here was see as applicability is addressed at people who want to use QUIC (application designer but also people deploying QUIC at servers) and manageability for people who have to handle QUIC traffic (mainly network operator incl probably data centre operators). I know the split between the two last categories (deploying servers and managing a dc networks) is not always that clear. It's probably this section and the one about load balancing in manageability. I'm open to discuss where which section belongs. Do we need to bring this to the meeting? NAME what kind of reference are you thinking of?
On what to do in Manageability: I'd suggest we write some text that says: "QUIC provides a version negotiation process, that allows new versions to be introduced. The deployment of new versions is discussed in section 12 of [ID. ietf-quic-applicability]." Maybe even just as the first para of Manageability: Sect: 2.8. I meant add reference to section 6 in QUIC Transport - to both these documents
There is already section 2.8 on "Version Negotiation and Greasing" and section 3.1.1. on "Identifying Negotiated Version" in the manageability draft. Ideally the idea is to not have cross reference between manageability and applicability. I added a reference to section 6 of the quic-transport draft in manageability (see PR ). Not sure we need that reference also in the applicability draft because that section actually doesn't require any knowledge of the internals on how version negotiation works...

Discussion:
2.8. <del> Version Negotiation packets are not intrinsically protected, but QUIC versions can 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> <ins> 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 protected, but QUIC versions can 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
Change:
This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)

Discussion:
3. <del> QUIC provides for 0-RTT connection establishment.  This presents opportunities and challenges for applications using QUIC. 3.1. </del> <ins> QUIC provides for 0-RTT connection establishment.  Though the same facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for applications using QUIC. </ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view

closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. <del> Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </del> <ins> An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a risk of replay attack.  Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP- REPLAY. </ins> <del> 3.2. </del> <ins> 3.1. </ins> Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same

partial or even complete replay protection, which could be used to manage replay risk. <del> 3.3. </del> <ins> 3.2. </ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes
Change:
This seeks to address issue: "MTU or Min QUIC Packet Size? "
Sect 2.4: says: “the network path meets minimum Maximum Transmission Unit (MTU) requirements. “ There is text in the QUIC transport spec that the WG perfected a little in the final stages, and I think this use of MTU in sect 2.3 is suspect. As I see it, the requirements in QUIC are for a minimum supported QUIC packet size... not the MTU required to send this on an interface. ... This nuanced might be a really important detail for operations staff - where there is frequently a need to consider encapsulations and tunnels on interfaces of devices. ... A cross reference to the QUIC Spec may also help here.
NAME can you propose text?
Thought to be addressed in PR
PR merged
I think there are only 3 ways to fill up the space, so maybe enumerate them? I also wonder if we need to caution against stripping unused UDP payload or splitting up packets within a UDP datagram?

Discussion:
packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server <del> Hello, and some Initial Completion) must be at least 1200 octets long.  This protects against amplification attacks and verifies that the network path meets minimum Maximum Transmission Unit (MTU) requirements.  This is usually accomplished with either the addition of PADDING frames to the Initial packet, or coalescing of the Initial Packet with packets from other encryption contexts. </del> <ins> Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. </ins> The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the
Change:
I updated the text of the second paragraph. If people could have another look that would be welcome. But I believe we are ready to merge (after the meeting).
So far we don't mention any extension in the ops drafts, however, datagrams actually require a different interface and as such are important for an application to know about, therefore, I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC.
Agreed, mentioning datagram seems very useful.

Discussion:
13. <ins> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC connection. 14. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 14. </del> <ins> 15. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for

analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 15. </del> <ins> 16. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture
Change:
The proposed wording makes sentence stronger, more list a SHOULD requirement. Therefore we wanted to check with others before we merge.
Seems simpler and clearer. I don't see this as normative.

Discussion:
If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by <del> the receiver.  Therefore it can be valuable to expose the maximum number of allowed, currently open, and currently used streams to the application to make the mapping of data to streams dependent on this information. </del> <ins> the receiver.  Therefore, an application can use the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams. </ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream
Change:
This is branched of . NAME said: "However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty."
NAME I created PR . Does that address this point sufficiently?

Discussion:
identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection <del> ID with a given flow, and can associate a known flow with a new flow when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. </del> <ins> ID, if present, with a given flow, and can associate a known flow with a new flow when when observing a packet sharing the same connection ID in the same direction between client and server and sharing one endpoint address (IP address and port) with the known flow. </ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is