jiebi/CodeConvo huggingface dataset:
Change:
Definitions of terms that are used in this document: <del> Any packet containing only one or more ACK frame(s). Packets are considered in-flight when they have been sent and are not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys. </del> All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered ack-eliciting.

Discussion:
ACK-only was only even used in the definition part and in-flight can also be defined using ack-eliciting.
I just realised that padding is the "complicating" thing here. I still don't think we need to define "act-only" just for that but can rather be explicit about padding frames because otherwise this is easy to miss (as I did initially).
While the defined term is not used elsewhere, the phrases "Packets containing only ACK frames" and "Packets only containing ACK frames" are used. We should either eliminate the definition or explicitly use the defined term in those places.
Of Mike's options, I think that this makes sense. Fewer defined terms means lower fixed cognitive load when reading this. Less jargon = good.I re-read the other spots NAME mentioned and I believe the text is still correct, so I'm going to accept this. Thanks for the simplification.
Change:
These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446: <ins> The hash used for the MLS transcript hash is the one referenced in the ciphersuite name.  In the ciphersuites defined above, "SHA256" and "SHA512" refer to the SHA-256 and SHA-512 functions defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established

Discussion:
Addresses ambiguity pointed out on the mailing list by NAME
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Change:
6.2.2. <ins> Server push is an optional feature introduced in HTTP/2 that allows a server to initiate a response before a request has been made.  See server-push for more details. </ins> A push stream is indicated by a stream type of "0x01", followed by the Push ID of the promise that it fulfills, encoded as a variable- length integer.  The remaining data on this stream consists of HTTP/3

Discussion:
The transition to "Push Streams" has no preceding mention of server push. This adds a reference to the correct section of RFC7540.
If mention of server push is desired before mention of push stream, would it be simpler to move the final sentence of the paragraph to the start?
Maybe this would be better if section 4 was moved after section 6? Then the concepts would be explained before going into the framing. I'd also like to reorder/renumber all the push frame types so they're all adjacent to one another and in a sensible order. Is there a reason they're numbered as they are? If not, I'll open an issue to renumber them.
There's already an issue to reorder some of the sections, so I'm happy to consider this as part of the same discussion. As to the numbering, the primary reason is maintaining the same frame IDs for things that stayed over from HTTP/2 -- PUSHPROMISE has the same ID, CANCELPUSH has the ID that HTTP/2 used for RSTSTREAM, and DUPLICATEPUSH is brand new and so pushes into unallocated space.
Given that is in now, do you still see this as a problem?
I think the Server Push section still lacks a simple explanation of what the push does. A sentence like what I added in this PR at the beginning would help that. Currently the Server Push section goes directly into mechanics. URL "HTTP/3 server push is similar to what is described in HTTP/2 {{!HTTP2}}, but uses different mechanisms. Each server push is identified by a unique Push ID. ..." I'd add more to the first paragraph in case people don't want to read the H2 draft.
I think I'd prefer for the reference to be to 4.4 of the current draft instead, since that does point to RFC7540 and has more context as well.
Whoops -- which also doesn't have the two-sentence explanation of what push is. That's up in the intro. Let me copy that over to 4.4.
Thanks for the added text Mike, it looks great. I'm happy with this, so it's up to you to decide when this is ready to merge.
Change:
4.1. <del> When using variable-bitrate codecs without an internal FEC, RFC2198 redundant encoding with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED.  This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. </del> <ins> When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in redundant-encoding) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED.  This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. </ins> When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED.  This provides reasonable protection of the audio stream against individual losses, with minimal overhead.  Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned <del> RFC2198 redundancy with reduced-bitrate Opus encodings SHOULD be used </del> <ins> redundant encoding with reduced-bitrate Opus encodings SHOULD be used </ins> instead. When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED.  This provides slightly more efficient protection of <del> the audio stream than RFC2198. </del> <ins> the audio stream than redundant encoding. </ins> <del> When using constant-bitrate codecs, e.g.  PCMU, use of RFC2198 redundant encoding MAY be used, but note that this will result in a potentially significant bitrate increase, and that suddenly increasing bitrate to deal with losses from congestion may actually make things worse. </del> <ins> When using constant-bitrate codecs, e.g., PCMU RFC5391, redundant encoding MAY be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse. </ins> Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher

Discussion:
While reading the document, I wrote down the following notes that the editor may take into account when revising the document: in 3.1, expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on (I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific). Acknowledged. stylistic: I am not a big fan of using citations like '[RFC2198]' as ordinary words or nouns, it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly. This makes texts more difficult to read for outsiders. Example: This mechanism is similar to the [RFC2198] mechanism described above. I prefer this: This mechanism is similar to the redundant encoding mechanism described above. There are couple of such usages of [RFCXXXX] in the document OK. add reference for PCMU OK. Reminder to self, RFC 5391.
Change:
Finally, an extension might define additional frame types which could be present. <del> Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </del> 3.5. The QUIC connection ID (see rebinding) is designed to allow a

Discussion:
Addresses
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.
Much better. My comment here is mostly a nit. I think that you are implicitly talking about the first packet from the client, so maybe you can avoid using the "Client Initial" thing here (if you are using the abstract concept you introduced), "client Initial" (that is, Initial packets sent by a client), or anything that might be confusing.
Change:
be informed when Early Data has been accepted or rejected by a server. <del> When implementing the server role, applications need to be able to: </del> <ins> When implementing the server role, an application protocol can: </ins> listen for incoming connections, which prepares for the exchange described in handshake;

Discussion:
The strong requirements here were wrong. What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present. Levying the requirement on implementations was incorrect. As some application protocols don't use certain QUIC features, it is not necessary to require implementations to support features if they are not general purpose. This rephrases these requirements without normative language, instead concentrating on what services the application protocol can depend on. This translates into requirements on implementations, but only via the application protocols they intend to support.
S 5.4 requires that the application be able to control resource allocation of various types, including flow control and the number of permitted streams of each type; This seems like a good idea, but it seems like one could have a reasonable QUIC stack that did not do this.
I would prefer to leave this. Noting that the level of control is not specified. This also suggests that the stack provide a keep-alive control, but there are likely cases (I'm thinking here of DNS over QUIC) where that is unlikely to be a useful feature. The goal is to list things that the specification believes a generic stack will provide. Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API.
NAME willing to fight for this one?
After discussing with editors, we think that it would be better to remove the MUST in this section and say something like: "A general purpose QUIC implementation provides the following functions:" and add "A specialized implementation might provide a subset of these." The same applies to the stream operations.
I think that is a positive change. Borderline design issue by the sound of it. It would be good to see the PR once its available.
Change:
SECG-SEC2 or in CFRG-EdDSA. EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the <del> Ed25519 curve, and Ed448 and Ed448ph keys MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA. </del> <ins> eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </ins> 5.10.

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
3.1.2.3. The mDNS name of an mDNS candidate MUST be used in the connection- <del> address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </del> <ins> address field of its candidate attribute.  However, when an mDNS candidate would be the default candidate, typically because there are no other candidates, its mDNS name MUST NOT be used in the connection-address field of the SDP "c=" line, as experimental deployment has indicated that many remote endpoints will fail to handle such a SDP.  In this situation, the IP address values "0.0.0.0"/"::" and port value "9" MUST instead be used in the c= and m= lines, similar to how the no-candidates case is handled in ICESDP, Section 4.3.1. </ins> Any candidates exposed to the application via local descriptions MUST be identical to those provided during candidate gathering (i.e., MUST

Discussion:
ping
NAME , PTAL
LGTM too
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)
Change:
TLS.  Without such support, Http2Transport connections cannot survive network transitions. <del> 8. </del> <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a

Discussion:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.
Change:
(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension <del> (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </del> <ins> (RFC8446, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (RFC8446, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use

Discussion:
When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.
Change:
and quality of service for MLS. *RECOMMENDATION:* If unidirectional transport is used for the <del> secure transport channel, prefer using a protocol which provides Forward Error Correction. </del> <ins> secure transport channel, prefer using a transport protocol which provides Forward Error Correction. </ins> 7.2.

Discussion:
Comment by NAME Again I am confused there are users with expectations of the MLS protocol, which is still in a draft form only? Is this mixing MLS and non-MLS?
Comment by NAME Is this the equivalent of proprietary IM clients "auto delete" or "view once" type messaging? "MLS deletation schedule" has not been defined before it is mentioned here. What is this?
It is not the equivalent of "expiring messages" features. It's a forward security provision.
The is defined in the protocol document. Perhaps a pointer would be useful.
Comment by NAME This seems a bit of gloating about the MLS protocol/client. Why not just state why the attack is impossible and require that MLS clients do this? I don't see other features being compared to other/older/worse solutions?
Comment by NAME It feels a bit odd to think of a compromised user sending an honest Commit message. If the user doesn't know they are compromised, they will still be compromised and this new Commit message won't help. If the user did know they were compromised and undid that, then sure this honest Commit message helps. I think perhaps "honest Commit" should be expanded and say something about de-compromised client sending a Commit message. My issue with "honest" is that compromised user with a passive attacker is still "honest". Similarly confusing is:
I think these cases mean "formerly compromised".
Comment by NAME This "recall" is misplaced. It is not mentioned before until this point.
Comment by NAME Is this saying a protocol within MLS, eg some application protocol? Or is this saying in this case, do not use MLS but another protocol at the messaging layer?
I understand "a protocol" as "a transport protocol". Because MLS does not provide FEC, and its integrity checks will fail if the packet is corrupted.
Comment by NAME It states any "secure channel" can be used, but it is kinda says any insecure channel can be used too. It also feels a little odd to describe these properties of MLS in the Security Considerations section, and not like in the introduction.
This is no different from how you can run TLS over a bare TCP/IP connection or you can run it over IPsec, and you get better security properties in the latter case.

Comment by NAME Wouldn't this PSK that is the result of a membership be part of the "state lost or corrupted" ? What is the exact kind of failure mode one would address with this? Also, how often would such a PSK get updated as it needs to be known to add group members (and doing this too often would I assume lead to long dormant group members from losing access?) If one could remove once's old self without the PSK, than everyone could delete any member?
Change:
QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see TLS.  New versions that also use TLS 1.3 SHOULD <del> mandate that their session tickets are rightly scoped to one version of QUIC; i.e., require that clients not use them across version and that servers validate this client requirement. </del> <ins> mandate that their session tickets are tightly scoped to one version of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. </ins> 6.3.

Discussion:
s/and therefore/, thereby/
s/rightly/tightly s/across version/across multiple versions
s/Alternatively, t/T/
Change:
7.3. The following value [will be/has been] registered in the "IETF URN <del> Sub- namespace for Registered Protocol Parameter Identifiers" </del> <ins> Sub-namespace for Registered Protocol Parameter Identifiers" </ins> registry, following the template in RFC3553: Initial contents: The types and descriptions in the table in errors

Discussion:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.
Change:
an asynchronous interface using the Socket API generally uses a try- and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The <del> application then waits and can try again later.  In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous and use an event-driven model (see events).  For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </del> <ins> application then waits and can try again later. In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous.  The API is defined around an event-driven model (see events) in order to model this asynchronous interaction, though other forms of asynchronous communication may be available to applications depending on the platform implementing the interface. For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </ins> This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously

Discussion:
in architecture.
Per slide 14 in Thorben Krüger's presentation at IETF 113: URL, clarify that the API is defined in terms of events to be general, not because you have to implement an event system if you're going to implement TAPS.
LGTM