jiebi/CodeConvo huggingface dataset:
Change:
Retry packets (packet-retry), Version Negotiation packets (packet- version), and packets with a short header (short-header) do not contain a Length field and so cannot be followed by other packets in <del> the same UDP datagram. </del> <ins> the same UDP datagram.  Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet. </ins> 12.3.

Discussion:
They don't have a length field, so the only place they could go is at the end of a packet. As the spec currently stands, it's valid to send a packet like this. There's little value in doing that. Do we want to continue to allow this?
My understanding is that they are implicitly forbidden, because coalescing packets belonging to different connections are forbidden, and because there’s nothing to coalesce with when either of the two types of the packets is sent. I am not sure if we need to be more clear on that, considering the fact we generally use MAY for the discarding rules for coalesced packets.
VN certainly causes a new connection based on discussions in Tokyo. Retry does not cause a new connection(ie: same ClientHello). Clarifying this seems wise if it's not already clear.
Yes, however when a Retry packet is being sent, there's nothing a server can send along with. Regarding if we need to clarify, while I do not think it's absolutely necessary, I can see that people might want to have it stated considering the fact that we do utilize corner case rules of coalesced packets (see ).
So, is this editorial?
I'm with NAME but I'm still wondering: what is the clarification that we can provide?
NAME Simply clarifying that "VN and Retry packets will never be coalesced" as part of the changes we would make in might be a good idea. We do not need to use a RFC 2119 word here due to the editorial nature of the issue.
Change:
which includes both public and private data.  An initial state, including an initial set of participants, is set up by a group creator using the _Init_ algorithm and based on information pre- <del> published by the initial members.  The creator sends the _GroupInit_ </del> <ins> published by the initial members.  The creator sends the _Init_ </ins> message to the participants, who can then set up their own group state and derive the same shared secret.  Participants then exchange messages to produce new shared states which are causally linked to

Discussion:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks
Change:
The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm that will be <del> employed in the server's KeyShare extension. </del> <ins> employed in the server's signature_algorithms extension. </ins> An ECDSA or EdDSA public key MUST use a curve and point format supported by the client, as described in RFC4492.

Discussion:
This section has a strange table that looked a little messy. So I cleaned that up. However, I noticed that it used to say this: Which doesn't make any sense. Should this be signature_algorithms extension instead?
Change:
"Ignore Order" value of "true" (0x01), the endpoint does not make this exception.  That is, the endpoint MUST NOT send an immediate acknowledgement in response to packets received out of order, and <del> instead continues to use the peer's "ACK-eliciting threshold" and </del> <ins> instead continues to use the peer's "Ack-Eliciting Threshold" and </ins> "max_ack_delay" thresholds for sending acknowledgements. 6.2.

Discussion:
Part of We still need to decide whether to change 'Update Max Ack Delay' to 'Max Ack Delay'.
Change:
This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no <del> proxy.  These options should be ranked and attempted in succession. </del> <ins> proxy.  As above, these options should be ranked based on preference, system policy, and performance and attempted in succession. </ins> This approach also allows a client to attempt different sets of application and transport protocols that, when available, could

Discussion:
URL I think we should add a similar ranking consideration description as we have for Network paths. Otherwise, I am not sure how to rank the protocol option.
I think here as well that the options should be ranked based on preference, system policy, and performance. I made a pull request to add it.
LGTM, lets of others have any opinion about it..
I agree with NAME
WFM
Change:
new ICE credentials, an error MUST be generated.  If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE <del> channel. </del> <ins> channel.  Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls-id as long as the offer contained an ICE restart.  Thus, JSEP implementations which process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any

Discussion:
In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.
See: URL
We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)
Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked
Change:
2. A naming system associates names with data.  Naming systems have <del> many significant facets that help differentiate them.  Some commonly-identified facets include: </del> <ins> many significant facets that help differentiate them from each other.  Some commonly-identified facets include: </ins> Composition of names

Discussion:
"each other" is clearer in English. I agree that "whole labels" is better and have changed the text.
At line 139, "each other" may be "others" ? At line 358, "full labels" may be "whole labels" or "each label".
Change:
the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. <ins> It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. </ins> 5.1. [[RFC editor: please remove this section before publication.]]

Discussion:
The doc has evolved from just HTTP/3 Datagram, to define Capsule protocol and HTTP datagrams over capsule. In Security Considerations, we say It's a little ambiguous what "this feature" on face value. Arguably, the recommendation to always send the setting could be done in the section that defines the setting. Some editorial work would address these concerns.
Agreed
The intent is much clearer to me now, thanks!
Change:
Protocol.  However, TLS must run over a reliable transport channel - typically TCP RFC0793. <del> There are applications that utilize UDP as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed.  DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. DTLS 1.0 was originally defined as a delta from TLS 1.1 and DTLS 1.2 was defined as a series of deltas to TLS 1.2.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3. </del> <ins> There are applications that utilize UDP RFC0768 as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed. DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. DTLS 1.0 RFC4347 was originally defined as a delta from TLS 1.1 RFC4346 and DTLS 1.2 RFC6347 was defined as a series of deltas to TLS 1.2 RFC5246.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3 I-D.ietf-tls-tls13. </ins> Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of

Discussion:
Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.
Change:
body, the verifier MUST calculate the hash of body just as the signer does, with no normalization or transformation of the request. <ins> Note that this proof method depends on a specific cryptographic algorithm, SHA-256, in two ways: the "ath" hash algorithm is hardcoded, and computing the payload of the detached/attached signature also uses a hardcoded hash.  A future version of this document may address crypto-agility for both these uses by replacing ath with a new header that upgrades the algorithm, and possibly defining a new header that indicates the HTTP content's hash method. </ins> 7.3.4. This method is indicated by the method value "jws".  This method

Discussion:
To edit notification comments on pull requests, go to your ._
There have been several questions about the parameter currently used to convey the hash of an access token in requests to the RS. Right now we use the definition from OpenID Connect: URL In speaking with the DPoP editors I've proposed a simplified claim there: URL It's functionally similar but doesn't require the array truncation step, and it also fixes to a single hash algorithm (SHA-256) instead of having to figure out which hash to use based on the external signing envelope. I think this change makes it both simpler to implement and to understand.
Also, for cryptographic agility here we would rely on defining a new claim name and updating the requirements about inclusion. So would always be SHA-256 and once that hash is sufficiently broken and discarded we would define a new claim like for whatever new target there is.
+1 for that, much more intuitive than truncating (and the comment from DPoP editors seem to go in that direction too). In relation to what would happen if SHA-256 gets deprecated: the current method is already based on SHA-256, so it's not a new downside an idea would be to name it for instance, to give a minimal versioning (would currently relate to SHA2) and would simplify changes later on (like avoiding ;-))
I personally think that naming the next version of the field should be left to the next version. Someone might want to specify or even , but the important thing is that we aren't defining plus parameters, we're just defining and anything else comes along as its own unique string. That kind of guidance can be written around the registry for the claim and how it'd get used.
works too
Reopening this issue: we are not providing cryto-agility, because: We do not indicate how the algorithm could change. Renaming the field to would remedy that. An implementation that did not include would formally be non-compliant, because the field is REQUIRED. We should say something about that. See URL
NAME crypto agility would be provided by defining a new field entirely. The algorithm will not change for . This was discussed in the OAuth WG with DPoP's field which has the same semantics as this. I do not recommend we re-open this.
I'm not asking to reopen it. Just to add a note in the text. The IESG reviewers are bound to comment on this.
Change:
For example, taking a potential extension of server to client communication using server sent events as specified in https://html.spec.whatwg.org/multipage/server-sent- <del> events.html#server-sent-events, the url for connecting to the server </del> <ins> events.html#server-sent-events, the URL for connecting to the server </ins> side event resource for the published stream will be returned in the <del> initial HTTP "201 Created" response with a "Link" header an a "rel" </del> <ins> initial HTTP "201 Created" response with a "Link" header and a "rel" </ins> attribute of "urn:ietf:params:whip:server-sent-events". The HTTP 201 response to the HTTP POST request would look like:

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
balancer uses the first two bits of the connection ID to multiplex incoming DCIDs over these schemes. <ins> Encryption in the algorithms below uses the AES-128-ECB cipher. Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins> This section describes three participants: the configuration agent, the load balancer, and the server.

Discussion:
Addresses
The stream and block cipher configuration are locked to AES-ECB. AES-128-ECB too (this needs to be clear). This is a fine design. If a better design is required, that can be achieved by adding a new arm to . It might pay to say that and cite URL at the same time.
LGTM. A suggestion, but I'm OK either way.
Change:
If the number of necessary server IDs per next hop is uniform, a simple implementation would use successively longer server IDs at each tier of load balancing, and the server configuration would match <del> the last tier.  The forward load balancers would simply treat the least significant bits of the server ID as part of the nonce. </del> <ins> the last tier.  Load balancers closer to the client can then treat any parts of the server ID they did not use as part of the nonce. </ins> 6.2.

Discussion:
Better not to deal with creating a new definition here. Especially one that uses the word "forward". Reword.
Change:
11.4. <del> This document will request IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </del> <ins> This document requests IANA to add the following values to the "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol>>. All of these new entries use the following values for these fields: RFC Editor: please remove the rest of this subsection before publication. Since this document has not yet been published, it might still change before publication as RFC.  Any implementer that wishes to deploy IP proxying in production before publication MUST use the following temporary codepoints instead: 0x2575D601 for ADDRESS_ASSIGN, 0x2575D602 for ADDRESS_REQUEST, and 0x2575D603 for ROUTE_ADVERTISEMENT. </ins>

Discussion:
NAME as capsule type registry expert, are you OK with this text?
URL registers 3 capsules that use 0x1ECA6A00, 0x1ECA6A01, and 0x1ECA6A02. Its good practice to use the provisional registration space while developing a document, so you have my appreciation. But its not clear if you intend to change these into the permanent registration space prior to publication. CONNECT-UDP followed that approach and noted it with . Please clarify if you intend to change the values and, if so, when.
That's a good point, I was planning on changing them right after WGLC but I guess that's not written in the draft. Let's keep this issue open during the WGLC and close it once we move to the final values
Plan is to have: 0x01 for ADDRESSASSIGN 0x02 for ADDRESSREQUEST 0x03 for ROUTE_ADVERTISEMENT assuming NAME agrees since we're the two IANA experts on that registry
in principle that's fine by me. We should be wary of using them too early in case things have to change even after WGLC. So late binding once publication is impending is the least risky and works for me.
On one hand I agree with you that assigning them sooner avoids the risk of dealing with interop failures if IESG review leads to unavoidable wire-format changes. On the other, waiting until after IESG approval means that now we have interop issues between the folks that deployed before or after that - that's what we're seeing with QUIC version negotiation. So I would prefer to get provisional registrations for the low codepoints after WGLC personally
reasonable
LGTM. I was going to suggest ot would be nice to articulate the codepoint change in the changelog, but I guess you don't have one anyway...
Change:
transmitted over one stream is mapped into frames or how those frames are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize <del> bandwidth consumption and computational costs (see section 8 of </del> <ins> bandwidth consumption and computational costs (see section 13 of </ins> QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or

Discussion:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.
Change:
On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the <del> Destination Connection ID for subsequent packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </del> <ins> Destination Connection ID for subsequent packets, including any subsequent 0-RTT packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </ins> A client MUST only change the value it sends in the Destination Connection ID in response to the first packet of each type it

Discussion:
For and NAME
Thanks
Note that section 17.2.3. 0-RTT does not mention 0-RTT CID but the following section 7.2.4. Handshake Packet does mention Handshake CID's. In existing draft.
LGTM, given the incorporated changes.
Change:
For fixed_size tasks, the batch selector is the batch ID assigned sent in the response. <ins> The "OpenBase()" function is as specified in HPKE for the ciphersuite indicated by the HPKE configuration. </ins> 4.5.5. Collect sub-protocol messages must be confidential and mutually

Discussion:
I only tried searching for it, but all I found were places that it was used. This makes it difficult to determine which inputs are which. Which is the AAD, which is the plaintext, and which is the nonce? Please also describe the inputs in text. Note that at least one of the code blocks that use this is too wide at 76 characters.
SealBase() and SealOpen() refer to the "single-shot APIs" from URL I notice that we don't reference this explicitly. Would a reference suffice?
Change:
is the concatenation of that node's parent along with the parent's direct path.  The _copath_ of a node is the node's sibling concatenated with the list of siblings of all the nodes in its direct <del> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </del> <ins> path. </ins> For example, in the below tree:

Discussion:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.