jiebi/CodeConvo huggingface dataset:
Change:
I don't think this sentence was accurate. TFO isn't analogous to 0-RTT session resumption, but it's needed to achieve the same application effect.
maybe analogous wasn't the right term but I'm also not sure about the word "true" here...
NAME "true" meaning "actual", i.e. you can resume a session without a round trip. We could specify that further but it probably has to be more wordy.

Discussion:
difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and <del> network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </del> <ins> network paths often do not support the Fast Open option RFC7413, which enables sending of payload data together with the first control packet of a new connection as also provided by 0-RTT session resumption in QUIC.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to- end, it is limited to a single packet of TLS handshake and application data, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If
Change:
Reset is a directional stream semantic, not a connection one.
Actually the idea here was not necessarily talk about the semantics of how a connection is closed. So maybe using something else like "abort" would avoid any confusion here...?
Oh, I see. Yeah maybe abort is better. For me reading this "reset" made me think of TCP connection and or QUIC stream semantics, which is probably not the intention.

Discussion:
stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually <del> reset the QUIC connection. </del> <ins> terminate the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general
Change:
addresses
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
Phrasing suggestion.

Discussion:
least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. <del> QUIC probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </del> <ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to
Change:
First stab;
Sorry I missed this during the WGLC. URL contains a lot of good stuff but it seems like it could say more about ALPN. 1) As an editorial comment ALPN is mentioned without expanding the acronym. The term is used, which doesn't seem to be defined anywhere other than the HTTP/3 specification (which might be a problem or not) 2) More substantial, there isn't really mention about any of the TLS or negotiation aspects of ALPN. We might see people try to offer multiple Application Protocols on the same UDP port, and using ALPN to select from them. Maybe this is more likely when QUIC can operate as both a stream-based and datagram-based protocol. 3) Related to 2, new application protocols over QUIC need an ALPN protocol identifier. This is distinct from the Alt-Svc discussion in Section 6; since other protocols won't use Alt-Svc, they might overlook things. The ALPN space is large but we might benefit from some text that gives people pointers on how to register the ALPN IDs they want to use before someone gets them. For reference, I started a list of protocols at URL Not all of those need formal registration but it is a nice illustration.
I'm unfortunately not coming up with some useful/actionable text here. Maybe NAME or NAME has some insight that could help?
It feels like the best way to incorporate this is to expand the "protocol doesn't imply port" discussion to also include "port doesn't imply protocol" before concluding with "not being able to safely make this inference is hard." has a first stab at this, though it doesn't cover as much as NAME first suggested. Feel free to expand on it.

Discussion:
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <ins> Additionally, Application-Layer Version Negotiation RFC7301 permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC should register an ALPN token for use in the TLS handshake. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) 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 <del> "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del> <ins> "h3" ALPN token.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also 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:
for signaling priority, such as those defined for HTTP/2 First, if we retain this comment, it should probably have a reference to RFC 7540 and the appropriate section. However, as NAME noted in reply to a previous issue, this document is about QUIC, not TCP; the use of HTTP/2 as an exemplar seems out-of-place, particularly since we're actively deprecating that priority scheme. Perhaps a reference to draft-ietf-httpbis-priority would be more appropriate?
I agree that a reference to draft-ietf-httpbis-priority would be more appropriate.
Yes, sounds good. I'll create a PR if no-one else does it before me.

Discussion:
streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as <del> those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </del> <ins> those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </ins> Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data
Change:
NAME said in PR on section "Passive Network Performance Measurement and Troubleshooting": "I think the caution against using Connection ID needs to be a lot stronger. Things will break, users will notice. I realize that implementations have to use this to enforce that, but I believe some already are. See a comment below as well."
NAME is PR better? Note that you should also review the previous paragraphs as I believe the problems are described there clearly already.

Discussion:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del> <ins> filtering), which potentially triggers a fallback to TCP.  Use of the connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes. </ins> 4.3.
Change:
repeats requirements from the transport spec unnecessarily. It might be easier to just strike this.
This is supposed to give advice to network operators e.g. in a load balancing setup where connection IDs are maybe generated centrally and distributed to the servers.
The surrounding text does. This paragraph does not.
I didn't think network operators who are in control of one of the endpoints would be considered in scope for this I-D. Surely the whole point is to advise network operators about what they should do with traffic they cannot hope to decrypt? If server endpoint operators are in scope, the Introduction should be revised. If they are not in scope, I could propose some words that essentially say "Don't bother trying to infer information from specific parts of the connection ID, for these reasons."
Okay, I think I see the problem now. Is better?
This is fine, but it presumes a lot about the outcome of things that aren't completely resolved in QUIC-LB. I think that I would like to see more of this left to QUIC-LB to deal with, especially if we are planning to publish this before QUIC-LB (which seems likely). That might mean being a lot more aggressive about cutting text here.

Discussion:
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection. <del> Server-generated connection IDs should seek to obscure any encoded routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the connection ID in the connection ID itself, instead of remembering it. QUIC_LB further specifies possible algorithms to generate connection IDs at load balancers. </del> <ins> QUIC_LB specifies algorithms for encoding the server mapping in a connection ID in order to share this information with selected on- path devices such as load balancers.  Server mappings should only be exposed to selected entities.  Uncontrolled exposure would allow linkage of multiple IP addresses to the same host if the server also supports migration which opens an attack vector on specific servers or pools.  The best way to obscure an encoding is to appear random to any other observers, which is most rigorously achieved with encryption.  As a result any attempt to infer information from specific parts of a connection ID is unlikely to be useful. </ins> 2.7.
Change:
I couldn't immediately parse, and I'm assuming this is a NiT, but I can always be surprised by nuances in security-related text, so I'm writing this as an issue: /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./ If TLS over TCP cannot be supported, the connection should be aborted, and the application should present a suitable prompt to the user that secure communication is unavailable./
I guess we can remove the "instead" but why did you change the "in order to"? The reason to abort instead of just moving on without security is, so that the application recognises and can tell the user.
NAME ?
OK on removing instead Is this better?: /If TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable./

Discussion:
Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If <del> 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. </del> <ins> TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable. </ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not
Change:
We recently added this sentence but the text two paragraphs up already says this. Here is my proposed change, however, maybe we can shorten this paragraph even further.

Discussion:
classification. Note that the use of a connection ID to support connection migration <del> renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </del> <ins> renders 5-tuple based filtering insufficient to detect active flows and requires more state to be maintained by DDoS defense systems if support of migration of QUIC flows is desired.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </ins> It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can

learning instead of processing observed header information. However, it is questionable whether connection migrations must be <del> supported during a DDoS attack.  However, for unintentional mitigations, as is usually the case for NAT rebindings, the connection ID can be used to track connections (see sec-flow- association).  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may 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> supported during a DDoS attack.  While unintended migration without a connection ID change can be more easily supported, it might be 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 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. </ins> Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS
Change:
These two sections are slightly redundant, and could easily be merged because the advice they give is more or less identical.
I think better to group these two! The current filtering text describes "possible packet filtering behaviors that relate to NATs". I suggest an initial series of packet ALSO traverse other domain edge devices (such as DDOS detection, NIDS, etc) in the same way, so we should be clear that NAT/NAPT is an example:-)
discussion on 19 April editor's meeting: there's been a lot of minor editorial refactoring that improves the flow of the doc, making this merge less necessary. Still need to make sure we have examples other than NAT, though.
multiple-examples fixed in

Discussion:
4.5. RFC4787 describes possible packet filtering behaviors that relate to <del> NATs.  Though the guidance there holds, a particularly unwise </del> <ins> NATs but is often also used is other scenarios where packet filtering is desired.  Though the guidance there holds, a particularly unwise </ins> behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at
Change:
It is sort of redundant (because it says connection) and maybe sort of misleading (QUIC connections only use a single 5-tuple at a time, so it is maybe correct, but also maybe not).

Discussion:
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line <del> blocking between streams, associated at a point in time with a single five-tuple.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </del> <ins> blocking between streams.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </ins> Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a
Change:
This is the editorial convention we adopted for connection ID and what the RFC editor correctly inferred also.

Discussion:
of allowed, currently open, and currently used streams when determining how to map data to streams. <del> QUIC assigns a numerical identifier to each stream, called the Stream </del> <ins> QUIC assigns a numerical identifier to each stream, called the stream </ins> ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, <del> the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream </del> <ins> the stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the stream </ins> ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, <del> HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way </del> <ins> HTTP/3 uses stream IDs to refer to streams that have already been opened, but makes no assumptions about future stream IDs or the way </ins> in which they are assigned Section 6 of QUIC-HTTP). 4.1.
Change:
You can associate packets with connections without a connection ID. So rather than say something that is factually incorrect, let's just leave the next paragraph to establish the right impression (that a connection ID is highly recommended). This text works without talking about zero-length connection IDs.

Discussion:
QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing <del> transport connection using the destination connection ID field (see also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del> <ins> transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-