jiebi/CodeConvo huggingface dataset:
Change:
Note: Don't merge until the last minute.
I want to do more than just approve this, but this'll have to do

Discussion:
support for one of these versions and can expect that clients ignore the value. <del> [[RFC editor: please remove the remainder of this section before publication.]] The version number for the final version of this specification (0x00000001), is reserved for the version of the protocol that is published as an RFC. Version numbers used to identify IETF drafts are created by adding the draft number to 0xff000000.  For example, draft-ietf-quic- transport-13 would be identified as 0xff00000d. Implementors are encouraged to register version numbers of QUIC that they are using for private experimentation on the GitHub wiki at <https://github.com/quicwg/base-drafts/wiki/QUIC-Versions>. </del> 16. QUIC packets and frames commonly use a variable-length encoding for
Change:
Persistent congestion means that no packets between two ack-eliciting packets was received by the peer. This was codified as all packets between those boundary packets being lost. However, non-ack-eliciting packets can be often never declared as lost, since loss declaration requires a packet to be in-flight (URL). What we really want to say is that none of the packets between these boundary packets were acknowledged. This PR makes this change. Note that the example below the definition already follows this; packets in between the boundary packets are noted as "not acknowledged" rather than marked as lost. (Problem also noted here: URL)

Discussion:
acknowledgement if two packets that are ack-eliciting are declared lost, and: <del> all packets, across all packet number spaces, sent between the send times of these two packets are declared lost; </del> <ins> across all packet number spaces, none of the packets sent between the send times of these two packets are acknowledged; </ins> the duration between the send times of these two packets exceeds the persistent congestion duration (pc-duration); and
Change:
Maybe leftovers from , or newly added text.
I'm sure the document was touched by his noodly appendage of the Octocat :octocat:
How did those slip through!?Yes, I think these are mostly new / imported from other docs.Thanks, NAME !

Discussion:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on <del> an octet boundary </del> <ins> an byte boundary </ins> Indicates that x has a fixed value of C

Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on <del> an octet boundary </del> <ins> an byte boundary </ins> Indicates that x has a fixed value of C with the length described by ?, as above

(RFC6265) MAY be split into separate field lines, each with one or more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be <del> concatenated into a single octet string using the two-octet delimiter </del> <ins> concatenated into a single byte string using the two-byte delimiter </ins> of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application.
Change:
NAME said: >14 "Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC." Generally true, but should be qualified for the presence of arbitrary numbers of tunnels.
This is not one that I have an answer to currently. We could just wave this away as Martin suggests, but I'm not sure that is best. What do tunneling protocols say about ensuring the IPv6 minimum MTU?
I don't know what the IETF tunneling protocols say about MTU, but I don't expect them to violate IPv6 minimum MTU (someone should correct me if I'm wrong). The problem here might not be about what allowances we make for tunneling -- I don't want to create a list of exceptions in this document -- but about wording. I propose changing "will be able to support" to "are expected to support". As long as we are not making assumptions that violate permissions afforded by spec or practice, I think we're good.
Thanks. This is weaker, but truer.

Discussion:
IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 <del> bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC. </del> <ins> bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or
Change:
This is OK, but only in a limited fashion.
NAME said: parameters are not delivered until the handshake is complete. In 8.2 it says that the TPs are "available" but "not fully trusted" before completion. The latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a SETTINGS frame) without any indication of the client transport parameters. I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand.
Proposed resolution is
I think the limitations could be a be clearer, but heading in a good direction.I think the changes add clarity.

Discussion:
Section 7.5 of QUIC-TRANSPORT. Once the TLS handshake is complete, this is indicated to QUIC along <del> with any final handshake bytes that TLS needs to send.  TLS also provides QUIC with the transport parameters that the peer advertised during the handshake. </del> <ins> with any final handshake bytes that TLS needs to send.  At this stage, the transport parameters that the peer advertised during the handshake are authenticated; see quic_parameters. </ins> Once the handshake is complete, TLS becomes passive.  TLS can still receive data from its peer and respond in kind, but it will not need

error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see tls-errors). <del> While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the handshake completes, and reliance on them should be minimized. However, any tampering with the parameters will cause the handshake to fail. </del> <ins> Transport parameters become available prior to the completion of the handshake.  A server might use these values earlier than handshake completion.  However, the value of transport parameters is not authenticated until the handshake completes, so any use of these parameters cannot depend on their authenticity.  Any tampering with transport parameters will cause the handshake to fail. </ins> Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A
Change:
Though I guess provisioning of a PSK depends on prior communication of a sort, there is no need to be so absolute here.
NAME said:
I will suggest that we strike the "only" here.

Discussion:
Application Data may appear only in the Early Data and Application Data levels.  Handshake and Alert messages may appear in any level. <del> The 0-RTT handshake is only possible if the client and server have </del> <ins> The 0-RTT handshake can be used if the client and server have </ins> previously communicated.  In the 1-RTT handshake, the client is unable to send protected Application Data until it has received all of the Handshake messages sent by the server.
Change:
Important enough to call out in this section.
Roman Danyliw said:
I think that we're OK, and the text added in should help avoid any need for this point.
NAME said:
Should we split this bit out into a separate issue? per §4.8 TLS alerts are translated into QUIC connection errors and are not sent natively. (The prose also says "TLS Handshake and Alert messages are carried directly over the QUIC transport".)
I don't think we need to do anything in response to that. Those messages are carried by QUIC.
I will defer to your preference, but I do not agree that "those messages" are carried by QUIC; QUIC does not carry TLS Alert structures.
a nit but lgtm

Discussion:
Handshake state updates <del> Additional functions might be needed to configure TLS. </del> <ins> Additional functions might be needed to configure TLS.  In particular, QUIC and TLS need to agree on which is responsible for validation of peer credentials, such as certificate validation (RFC5280). </ins> 4.1.1.
Change:
This changes the shape of the requirement from one that proscribes the behaviour of a TLS stack to the reaction of QUIC to a warning level alert. This recommends treating them as fatal as QUIC never deliberately closes TLS. This is a normative change that should have no practical effect on implementations.
NAME said:
I'm going to request that we flag this one "design". I think that we want to say: the TLS connection is never closed using TLS mechanisms QUIC can treat any TLS alert as fatal PR created and email in the pipe.
Marking this as design as requested.
Returning to an open state as the chairs directed in their plan.
Closing this now that the IESG have approved the document(s).
I agree that this is a good improvement, especially for folks who can't modify their TLS stack.

Discussion:
from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. <del> The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. </del> <ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal connection close; see Section 6.1 of TLS13.  As QUIC provides alternative mechanisms for connection termination and the TLS connection is only closed if an error is encountered, a QUIC endpoint MUST treat any alert from TLS as if it were at the "fatal" level. </ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this
Change:
Though people will undoubtedly rely on pseudocode to understand this, there is no reason why we can't also use prose.
NAME said:
That's just an oops. There is a paragraph that almost defines this in prose. It just needs a little push and we don't need to rely exclusively on pseudocode.

Discussion:
The same number of bytes are always sampled, but an allowance needs to be made for the endpoint removing protection, which will not know <del> the length of the Packet Number field.  In sampling the packet ciphertext, the Packet Number field is assumed to be 4 bytes long (its maximum possible encoded length). </del> <ins> the length of the Packet Number field.  The sample of ciphertext is taken starting from an offset of 4 bytes after the start of the Packet Number field.  That is, in sampling packet ciphertext for header protection, the Packet Number field is assumed to be 4 bytes long (its maximum possible encoded length). </ins> An endpoint MUST discard packets that are not long enough to contain a complete sample.
Change:
This is a little pedantic, but it's more correct. Also fix reference format.
NAME said:

Discussion:
Once an endpoint successfully receives a packet with a given packet number, it MUST discard all packets in the same packet number space with higher packet numbers if they cannot be successfully unprotected <del> with either the same key, or - if there is a key update - the next packet protection key (see key-update).  Similarly, a packet that appears to trigger a key update, but cannot be unprotected successfully MUST be discarded. </del> <ins> with either the same key, or - if there is a key update - a subsequent packet protection key; see key-update.  Similarly, a packet that appears to trigger a key update, but cannot be unprotected successfully MUST be discarded. </ins> Failure to unprotect a packet does not necessarily indicate the existence of a protocol error in a peer or an attack.  The truncated
Change:
So it could be unsafe for use in 0-RTT.
NAME said:
STOP_SENDING can be sent in 0-RTT. It should be in the list.

Discussion:
avoid replay attacks on the protocol. Of the frames defined in QUIC-TRANSPORT, the STREAM, RESET_STREAM, <del> and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they carry application data.  Application data that is received in 0-RTT could cause an application at the server to process the data multiple times rather than just once.  Additional actions taken by a server as a result of processing replayed application data could have unwanted consequences.  A client therefore MUST NOT use 0-RTT for application data unless specifically requested by the application that is in use. </del> <ins> STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they carry application data.  Application data that is received in 0-RTT could cause an application at the server to process the data multiple times rather than just once.  Additional actions taken by a server as a result of processing replayed application data could have unwanted consequences.  A client therefore MUST NOT use 0-RTT for application data unless specifically requested by the application that is in use. </ins> An application protocol that uses QUIC MUST include a profile that defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to
Change:
We changed the limits listed here to be based on the maximum packet size, so the note a few paragraphs up citing the appendix is all we need here.
NAME said:
A few things here... The text in DTLS is a copy of this text, so similarities are no accident. However, the text has diverged, so drawing an analogy doesn't seem necessary (and I don't want a downref, even if it were informational). The numbers we are using from TLS is the target advantage probability. QUIC has a larger limit on packet size than TLS has on record size. Larger sizes affects the limits, which is what you see there. The note you quote is old and it should have been removed when we changed the numbers. As noted the analysis for DTLS would be helpful, but not definitive. As you say, the number of blocks in a packet can have an effect (though not for ChaCha20Poly1305 apparently). So l've a PR for the note, but I don't see any other action here.
I have an action item (to pester the DTLS 1.3 authors to reduce the divergence), but I agree there's no other action for this document.

Discussion:
Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD. <del> These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. </del> Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be
Change:
The text was probably backwards, but rather than invert it, remove the indirect reference to the subject of the claim and be explicit.
Erik Kline said:

Discussion:
and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously <del> used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del> <ins> used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses,
Change:
URL the path doesn't provide extra headroom. Includes some rewording of the text.
Éric Vyncke said:
We wanted some space for things like extension headers/options and maybe for tunnels. See which is in response to your peer Erik. And yeah, 1200 is a nice number.
Based on the discussion here and the linked issue, I don't think we need to do anything here.
Erik Kline said:
Seems reasonable to mention. Obviously many paths support a larger MTU and so will support more extensions (or options), but it's worth noting that there isn't a ton of space available.

Discussion:
bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths are expected to be able to support QUIC. <ins> This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes.  This affects Initial packets and path validation. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud).

fragmented or dropped (RFC8085). If a QUIC endpoint determines that the PMTU between any pair of local <del> and remote IP addresses has fallen below the smallest allowed maximum </del> <ins> and remote IP addresses cannot support the smallest allowed maximum </ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
Change:
Éric Vyncke said:
We say it, but it comes a lot later. Too late, I think.

Discussion:
connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt. <ins> Multiple connection IDs are used so that endpoints can send packets that cannot be identified by an observer as being for the same connection without cooperation from an endpoint; see migration- linkability. </ins> Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same
Change:
and part of
Alissa Cooper said:
NAME said:
Good point, also 4.7 currently has TLP in the title, but doesn't use it anywhere else in the section, so I'll add some text on TLP too. URL
Please also update the RACK reference to version 14. draft-ietf-tcpm-rack-14
The version update is part of the toolchain we use, so the newest version of RACK should be referenced automatically.

Discussion:
4.7. QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's <del> RTO computation.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout.  QUIC does not collapse the congestion window until persistent congestion (persistent-congestion) is declared, unlike TCP, which collapses the congestion window upon expiry of an RTO.  Instead of collapsing the congestion window and declaring everything in-flight lost, QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. In doing this, QUIC avoids unnecessary congestion window reductions, </del> <ins> RTO computation; see RFC6297.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC does not collapse the congestion window when the PTO expires, since a single packet loss at the tail does not indicate persistent congestion.  Instead, QUIC collapses the congestion window when persistent congestion is declared; see persistent-congestion.  In doing this, QUIC avoids unnecessary congestion window reductions, </ins> obviating the need for correcting mechanisms such as F-RTO (RFC5682). Since QUIC does not collapse the congestion window on a PTO expiration, a QUIC sender is not limited from sending more in-flight

timer expires.  This is more aggressive than TCP's RTO mechanism when application-limited, but identical when not application-limited. <del> A single packet loss at the tail does not indicate persistent congestion, so QUIC specifies a time-based definition to ensure one or more packets are sent prior to a dramatic decrease in congestion window; see persistent-congestion. </del> <ins> QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. </ins> 4.8.

Acknowledgment-based loss detection implements the spirit of TCP's Fast Retransmit (RFC5681), Early Retransmit (RFC5827), FACK (FACK), <del> SACK loss recovery (RFC6675), and RACK (RACK).  This section provides an overview of how these algorithms are implemented in QUIC. </del> <ins> SACK loss recovery (RFC6675), and RACK-TLP (RACK).  This section provides an overview of how these algorithms are implemented in QUIC. </ins> A packet is declared lost if it meets all the following conditions:
Change:
Barry Leiba said:
The other reference was: — Section 3.5 — An endpoint SHOULD copy the error code from the STOPSENDING frame to the RESETSTREAM frame it sends, but MAY use any application error code. I'm OK with changing to "can".
I don't think we need to do this; I've suggested changes on the PR.
Ok, let's merge this one, and I'll make a separate PR for the second comment.

Discussion:
RESET_STREAM frame instead of retransmitting the data. An endpoint SHOULD copy the error code from the STOP_SENDING frame to <del> the RESET_STREAM frame it sends, but MAY use any application error </del> <ins> the RESET_STREAM frame it sends, but can use any application error </ins> code.  An endpoint that sends a STOP_SENDING frame MAY ignore the error code in any RESET_STREAM frames subsequently received for that stream.

non-probing packet with a new largest packet number on its preferred address, the server begins sending non-probing packets to the client exclusively from its preferred IP address.  It SHOULD drop packets <del> for this connection received on the old IP address, but MAY continue </del> <ins> for this connection received on the old IP address, but can continue </ins> to process delayed packets. The addresses that a server provides in the preferred_address
Change:
They only need to be good for one RTT. Of course, the server doesn't really know what the RTT is, so this isn't something firm, and I don't want to explain ALL of that, but this should do.
Roman Danyliw said:

Discussion:
Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited.  Servers SHOULD ensure that <del> tokens sent in Retry packets are only accepted for a short time. Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times in a short period.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </del> <ins> tokens sent in Retry packets are only accepted for a short time, as they are returned immediately by clients.  Tokens that are provided in NEW_TOKEN frames (frame-new-token) need to be valid for longer, but SHOULD NOT be accepted multiple times.  Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse. </ins> 8.2.
Change:
and the 20-byte overhead too. (If this is superseded, that's cool. Low hanging fruit...)
Éric Vyncke said:

Discussion:
window of 10 times the maximum datagram size (max_datagram_size), limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, <del> increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </del> <ins> increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.