jiebi/CodeConvo huggingface dataset:
Change:
6. <del> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. </del> <ins> A sender can use an ACK_FREQUENCY frame to reduce the number of acknowledgements sent by a receiver, but doing so increases the chances that time-sensitive feedback is delayed as well.  For example, as described in loss, delaying acknowledgements can increase the time it takes for a sender to detect packet loss.  The IMMEDIATE_ACK frame helps mitigate this problem. An IMMEDIATE_ACK frame can be useful in other situations as well. For example, it can be used with a PING frame (Section 19.2 of QUIC- TRANSPORT) if a sender wants an immediate RTT measurement or if a sender wants to establish receiver liveness as quickly as possible. An endpoint SHOULD send a packet containing an ACK frame immediately upon receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending an ACK frame despite receiving an IMMEDIATE_ACK frame.  For example, an endpoint might do this if a large number of received packets contain an IMMEDIATE_ACK or if the endpoint is under heavy load. </ins> 7.

Discussion:
Also,
There's nothing odd about an immediate ACK! Perhaps the text should start by saying that the spec allows a receiver to do this anyway? However, the current text doesn't explain why the Immediate ACK might be useful. I could see three places that might benefit from an IMMEDIATE_ACK: Two cases relevant to SCTP [RFC7053] are: When the rate of transmission was very low and packets might be lost and not detected (something not uncommon in some SCTP uses); as an alternative to detect connectivity failure and trigger path failover. I'm not sure how important these specific cases are for QUIC, because the discussion at the time in TSVWG appeared to centre around use for signalling traffic? There could also be real opportunity to use this to get more precise timing/congestion information. A set of per-packet ACKs might be useful while a CC is probing to confirm available capacity, etc. Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used. (aside: I am actually uncertain whether this would really be a good change to TCP, especially with the heterogeniety of TCP middleboxes and senders,... that's another story, but I'd think it might be nice to not rely on draft-gomez-tcpm-ack-pull as a reference. I could suggest RFC7053, where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response.)
We use an immediate ACK to support CC by delayed ACKs.
URL adds two use cases that uses IMMEDIATE_ACK.
Seems would benefit from a little polish and some improvement in the examples.
Change:
computed as described in issuer-configuration. Challenge value "challenge", an opaque byte string.  For example, <del> this might be provided by the redemption protocol in HTTP- Authentication. </del> <ins> this might be provided by the redemption protocol in AUTHSCHEME. </ins> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.  This section uses notation

Discussion:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!
Change:
Endpoints will take measures to mitigate the adverse effects of denial of service attacks (refer to attacks) from other entities, including from other endpoints, to a level equal to or better than <del> traditional conference (i.e., pre-PERC) deployments. </del> <ins> traditional conference (i.e., non-PERC) deployments. </ins> 3.2.2.

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
<del> Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 </del> <ins> Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2 </ins> draft-ietf-tls-md5-sha1-deprecate-07 Abstract

Discussion:
Addresses , , and .
Replace Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 with Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2
Add the following to the WANG reference: URL Replace: URL with URL and URL with URL
replace Dell with CIS/Center for Internet Security (CIS)
Change:
8.11. <del> IANA has added the media type "application/edhoc" to the Media Types registry. </del> <ins> IANA has added the media type "application/edhoc" to the "Media Types" registry. </ins> Type name: application

Discussion:
A new Resource Type (rt=) Link Target attribute like "URL" may be registered in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
That seems like a good idea.
Marco, do you want to provide a PR? Then we could merge that for -11
Done, see URL Note that the first commit is just about removing trailing whitespace to avoid compiling errors. The content you need is in the commit URL
Looks good. I tried to align the whole IANA section with RFC 8126. Then I merged.
Change:
Expired Event contains a reference to the Message to which it applies. <del> 8.2.3.3. </del> <ins> 8.2.2.3. </ins> A SendError occurs when a Message was not sent due to an error condition: an attempt to send a Message which is too large for the

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
SETTINGS, the encoder must treat this as a connection error of type QPACK_DECODER_STREAM_ERROR. <del> For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the maximum table capacity is 0 until the encoder processes a SETTINGS frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY. </del> <ins> For clients not using 0-RTT data (whether 0-RTT is not attempted or is rejected) and for all HTTP/3 servers, the maximum table capacity is 0 until the encoder processes a SETTINGS frame with a non-zero value of SETTINGS_QPACK_MAX_TABLE_CAPACITY. </ins> When the maximum table capacity is zero, the encoder MUST NOT insert entries into the dynamic table and MUST NOT send any encoder

Discussion:
Addresses most of the open RFC Editor questions.
Need to update Buck's contact information to .
Fixed in .
This is a change in the RFC Editor diff that I don't think works; pulling out for separate discussion. Original: Proposed but incorrect: The intended reading is: For... HTTP/3 servers (always, regardless of 0-RTT) and HTTP/3 clients when 0-RTT is not attempted or is rejected URL maximum table capacity is 0.
Fixed in .
Should the following text be formatted using ? See the definition at . Original: Note: Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess. Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Original: Note: Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled. For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table.
Probably yes.
Fixed in .
May we update "Huffman-coded" with "Huffman encoded" in this text to match other uses? Original: They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
Fixed in .
Change:
A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a <del> 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </del> <ins> 403 (Forbidden) error with a problem document of type "orderNotReady".  The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </ins> If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the

Discussion:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:
Change:
In particular, the precise data from one structured information document can only be expressed at the same URI.  However, statements <del> can be added to make a data set that is expressible elsewhere, and subsets of the data can be taken and expressed. </del> <ins> can be added to make a data set that is expressible elsewhere (this document defines the "carries-information-about" relation type leading to the "http://www.iana.org/assignments/relation/carries- information-about" predicate being usable here), and subsets of the data can be taken and expressed. </ins> Null literals are not special compared to other literals - they just happen to work like RDF blank nodes, and are also called blank nodes.

Discussion:
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).
Change:
connection flow control limits and so no advantage is gained by doing so. <del> Endpoints choose the congestion controller that they use.  Though congestion controllers generally treat reports of ECN-CE markings as equivalent to loss (RFC8311), the exact response for each controller could be different.  Failure to correctly respond to information about ECN markings is therefore difficult to detect. </del> <ins> Endpoints choose the congestion controller that they use.  Congestion controllers respond to reports of ECN-CE by reducing their rate, but the response may vary.  Markings can be treated as equivalent to loss (RFC3168), but other responses can be specified, such as (RFC8511) or (RFC8311). </ins> 9.

Discussion:
Includes some changes suggested in (see below) ISSUE: /When a loss or ECN-CE marking is detected, NewReno halves the congestion window, sets the slow start threshold to the new congestion window, and then enters the recovery period./ The requirement is that TCP needs to reduce after CE, The RFC series does not now say it needs to halve, it could for example follow the reduction method specified in RFC8511. e.g. /When a loss or ECN-CE marking is detected, the sender must reduce the cwnd. NewReno halves the congestion window, sets the slow start threshold to the new congestion window, and then enters the recovery period. [RFC8511] specifies an alternate cwnd reduction./ ISSUE: Similar comment in 8.3: /Though congestion controllers generally treat reports of ECN-CE markings as equivalent to loss [RFC8311], the exact response for each controller could be different. / This does not seem correct. Could I suggest: /Congestion controllers respond to reports of ECN-CE by reducing their rate. Markings can be treated as equivalent to loss [RFC3168], but other responses can be specified (e.g. [RFC8511]) [RFC8311]. /
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
As it stands, the recovery draft does not require the congestion window to be reduced on loss. The only part that talks about this is in Section 7.4, which says: We need to require this reduction for the controller to be a NewReno controller.

To clarify, this isn't a change in what we're describing, you just want to add normative language?
Change:
All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce <del> fields, with limits defined for each algorithm. </del> <ins> fields, with limits defined for each algorithm.  When using a given configuration, the server MUST generate CIDs of length equal to the lengths of these three fields. </ins> The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm. <ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. </ins> The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of <del> configuration parameters.  Limits on the length of the nonce are different for each algorithm. </del> <ins> configuration parameters. </ins> <del> The First Octet, Server ID, and Nonce comprise the minimum length Connection ID for any given algorithm.  The load balancer need not know the full connection ID length to successfully process a packet, given that it is of minimum size. </del> <ins> The nonce length MUST be at least 4 octets.  Additional limits on its length are different for each algorithm.  See cid-entropy for limits on nonce generation. </ins> <del> The For Server Use field has any value and length chosen by the server, within the connection ID length limits in the operative QUIC version.  It SHOULD appear random and SHOULD NOT link two connection IDs to the same connection, or indicate they originate from the same server. </del> <ins> As QUIC version 1 limits connection IDs to 20 octets, the server ID and nonce lengths MUST sum to 19 octets or less. </ins> 5.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.9.3. </del> <ins> 7.1.10.3. </ins> sendMsgMaxLen

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream. <ins> If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream that cannot be created due to client-initiated bidirectional stream limits, it SHOULD be treated as a connection error of type H3_ID_ERROR.  Generating an error is not mandatory in this case because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </ins> HTTP/3 datagrams MUST only be sent with an association to a stream that supports semantics for HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP

Discussion:
We say: This has some parallels to Extensible Priorities where we are expected to handling an H3 frame that might reference a stream that has not yet been created (most likely due to reordering). We can't avoid reordering but we can be more conservative on the frames that do get buffered. URL says: We can probably recommend something similar here.
This makes sense, sending an HTTP Datagram for a stream that you're not yet allowed to create violates a MUST in a detectable way so we can recommend punishment. Though I doubt that we'd implement this check.
Change:
that the client has met its requirements, the server will issue the requested certificate and make it available to the client. <del> To revoke a certificate, the client simply sends a revocation request indicating the certificate to be revoked, signed with an authorized key pair.  The server indicates whether the request has succeeded. </del> <ins> To revoke a certificate, the client sends a signed revocation request indicating the certificate to be revoked: </ins> Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case

Discussion:
Several places talked about account key pairs as being the primary notion of an account, while the account is now primary and has a public key associated with it. Updated to clarify that. Clarified that the account request can contain more than just contact information. Fixed the order of operations in protocol summary to reflect new-order flow.
Change:
unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an <del> acknowledgement for one of its Handshake or 1-RTT packets and has not received a HANDSHAKE_DONE frame, even if there are no packets in flight.  When the PTO fires, the client MUST send a Handshake packet if it has Handshake keys, otherwise it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. </del> <ins> acknowledgement for one of its Handshake packets and the handshake is not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a Handshake packet if it has Handshake keys, otherwise it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. </ins> 6.2.3.

Discussion:
This avoids redefinition of the conditions for handshake confirmation. It's fewer words, even with the extra references.
The draft should use "handshake confirmed" and point to the TLS draft instead of describing the conditions individually in various places.
Change:
"extensions" field.  The types of these extensions are omitted when serializing the "extensions" field of the corresponding message. <ins> The "self_delimiting_extensions" field indicates extensions whose data is self-delimiting.  The cTLS implementation MUST be able to parse all these extensions, and all extensions listed in Section 4.2 of RFC8446. </ins> The "allow_additional" field MUST be 0 (false) or 1 (true), indicating whether additional extensions are allowed here.

Discussion:
In the case a cTLS handshake uses a self-delimiting extension (in additional extensions) that is not present in section 4.2 of RFC 8446, its length is always serialized. With this PR, the type of this extension can be stored in and its length can be omitted.
Change:
computing AES-ECB on the first 16 bytes of the ciphertext: When the AEAD is based on ChaCha20, then the mask is generated by <del> treating the first 12 bytes of the ciphertext as the Nonce and the next 4 bytes as the counter, passing them to the ChaCha20 block </del> <ins> treating the first 4 bytes of the ciphertext as the block counter and the next 12 bytes as the nonce, passing them to the ChaCha20 block </ins> function (Section 2.3 of CHACHA): The sn_key is computed as follows:

Discussion:
NAME NAME
... takes its sample inputs in a different order to the one used in QUIC. This issue tracks the possibility of erasing that difference.
Change:
from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, <del> the client MUST set the probe timer if the client has not received an </del> <ins> the client MUST set the PTO timer if the client has not received an </ins> acknowledgment for any of its Handshake packets and the handshake is not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!
Change:
6.2.7. <del> FullChecksumSend </del> <ins> fullChecksumSend </ins> Preference

Discussion:
As discussed at the last interim, but cleaning up the references to use the real property names too.
Yes, because it's just a quote of the minset RFC's name :) can't change that anymore
Works for me. I'm not hugely sold on "end systems" given my recent experience with the word "system" in arch - but it likely is quite OK here.
Change:
implies his endorsement.  This document also benefited from discussions with and review from the following people: Viktor Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick <del> McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </del> <ins> McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </ins>

Discussion:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.
Change:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-26 - Clarify that you can't negotiate pre-TLS 1.3 with supported_versions. </ins> draft-25 - Add the header to additional data (*) Minor clarifications.

Discussion:
LGTM!
This is natural, since if you negotiate prior to 1.3 you must use the ServerHello rules for the negotiated URL