jiebi/CodeConvo huggingface dataset:
Change:
exhaustion attacks.  One way to minimize state is to use the Integrity Protected Timestamp method described in echo-state. <ins> When the Token (or part of the Token) contains a sequence number, the encoding of the sequence number has to be chosen in a way to avoid any collisions.  This is especially true when the Token contains more information than just the sequence number (e.g. serialized state). </ins> 7. Implementations SHOULD NOT put any privacy sensitive information in

Discussion:
"the encoding of the sequence number has to be chosen . . ." Replace "has to" with "MUST"? (I merged now and proposed the commit in the master branch)
I had to resolve a conflict before merging. Hope I did that right.
Change:
An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  The maximum ack delay is communicated in the <del> max_ack_delay transport parameter; see Section 18.1 of QUIC- </del> <ins> max_ack_delay transport parameter; see Section 18.2 of QUIC- </ins> TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the

Discussion:
NAME I added IANA considerations, analogous to those in the HTTP doc for the stream type.
We have space for private transport parameters and a process for assigning new standard transport parameters. However, since we do not apply GREASE to transport parameters, we leave ourselves open to that flexibility ossifying. I'm happy to produce a PR to address this in the spec.
During interop in London we found an implementation that failed the handshake upon seeing an unknown transport parameter. I think applying GREASE to transport parameters is a great idea.
Discussed in London, NAME to prepare a PR
NAME any progress here?
I have prepared something. I can open a pr
NAME sorry I totally dropped the ball here! I had text ages ago and was circling back today finally. Thanks NAME for seeing to it.
Thanks Marten!Thanks for writing this up!Need to fix the examples, but otherwise looks good.
Change:
MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below. </del> <ins> described in sec.parsing-a-desc below. </ins> Finally, the parsed SessionDescription is applied as described in <del> the sec.applying-a-local-desc section below. </del> <ins> sec.applying-a-local-desc below. </ins> 5.6. When a SessionDescription is supplied to setRemoteDescription, the following steps MUST be performed: <del> First, the type of the SessionDescription is checked against the current state of the PeerConnection: </del> <ins> If the description is of type "rollback", follow the processing defined in sec.rollback and skip the processing described in the rest of this section. Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: </ins> If the type is "offer", the PeerConnection state MUST be either "stable" or "have-remote-offer".

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
2.1.1. <del> Implementations of HTTP/3 that are willing to receive HTTP Datagrams can indicate that to their peer by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </del> <ins> Endpoints can indicate to their peer that they are willing to receive HTTP/3 Datagrams by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </ins> The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to

Discussion:
Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric
Change:
the server's (EC)DHE key from the identified configuration and the client's key found in the ClientKeyShare.  If no key from an acceptable group is in the ClientKeyShare, the server MUST ignore the <del> known_configuration extension.  When this mechanism is used, the </del> <ins> "known_configuration" extension.  When this mechanism is used, the </ins> server MUST NOT send a Certificate/CertificateVerify message unless the ServerConfiguration message is also sent. <del> When the known_configuration data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </del> <ins> When the "known_configuration" data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </ins> together. 6.3.1.5.4. <del> The pre_shared_key extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </del> <ins> The "pre_shared_key" extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </ins> %%% Hello Messages

Discussion:
Some fixes for things I didn't catch when I checked for typos in the big patch last time. Of note, you're missing a closing brace for the select in "PreSharedKeyExtension" and a semicolon after "KnownConfigurationExtension". I also corrected things to match the existing (admittedly unusual) indentation style of the document and put quotes around the extension IDs you missed. (some had them; some didn't)
Ok, spaces between cases reverted. I also added a similar bit of whitespace in another new extension.
Change:
The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del> <ins> The token value from the server-provided challenge object </ins> The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
GREASE I-D.ietf-tls-grease "encrypted_client_hello" extension as follows: <del> Select a supported cipher suite, named group, and padded_length value.  The padded_length value SHOULD be 260 (sum of the maximum DNS name length and TLS encoding overhead) or a multiple of 16 less than 260.  Set the "suite" field to the selected cipher suite.  These selections SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session. Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. </del> <ins> Set the "suite" field to a supported cipher suite.  The selection SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session. </ins> Set the "record_digest" field to a randomly-generated string of hash_length bytes, where hash_length is the length of the hash function associated with the chosen cipher suite. <del> Set the "encrypted_client_hello" field to a randomly-generated string of [TODO] bytes. </del> <ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. Set the "encrypted_ch" field to a randomly-generated string of [TODO] bytes. </ins> If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with

Discussion:
Also define the length of the randomly-generated "encrypted_ch" field.
NAME NAME
Change:
When sending the <del> message, the key distributor MUST insert its own value in the </del> <ins> message, the key distributor MUST insert its own unique identifier in the </ins> extension.  This value MUST also be conveyed back to the client via SDP as a

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM
Change:
Value: "uint8", with 0 indicating "false" and 1 indicating "true". If true, handshake messages MUST be conveyed inside a "Handshake" <del> (RFC8446, Section 4) struct on stream transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct on datagram transports, and MAY be broken into multiple records as in TLS and DTLS. Otherwise, each handshake message is conveyed in a "CTLSHandshake" or </del> <ins> (RFC8446, Section 4) struct on reliable, ordered transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct otherwise, and MAY be broken into multiple records as in TLS and DTLS.  If false, each handshake message is conveyed in a "CTLSHandshake" or </ins> "CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the payload of a single record.

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
requests immediately to have a cached result available when the client's Echoed request arrives. <del> Amplification mitigation should be used when the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. </del> <ins> Amplification mitigation is a trade-off between giving leverage to an attacker and causing overheads.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is considered acceptable for unconstrained applications I-D.ietf- quic-transport. When that limit is applied and no further context is available, a safe default is sending initial responses no larger than 136 Bytes in CoAP serialization.  (The number is assuming a 14 + 40 + 8 Bytes Ethernet, IP and UDP header with 4 Bytes added for the CoAP header.  Triple that minus the non-CoAP headers gives the 136 Bytes).  Given the token also takes up space in the request, responding with 132 Bytes after the token is safe as well. </ins> When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or Non-confirmable response,

Discussion:
Closes: URL Not tagging any of you for reviewers because that's a topic that primarily I was active on, but still not merging right away in case you want to chime in.
In the response to URL I promised better wording for the 152 bytes -- but let's see whether anything gets back there first. As Carsten pointed out, this is the derived number from the "three times" part, also accounting for the remainder of the UDP packet. Assuming an attacker wants to maximize the amplification possible by the factor 3, they will send 14 octets Ethernet header 40 octets IP header 8 octets UDP header 4 octets CoAP header 8 octets of token allowsing the server to send Σ 3 = 222 octets. Subtracting everything in the response including the UDP header, that gives 160 octets of UDP data. Given the token is variable length data of up to 8 octets the server implementer can't easily take into account, that leaves 152 octets. (Granted, that last step doesn't follow from the wording, and I'm looing to sharpen that). Having some hard number there (and I'm happy to use better ways to come up with one) is important because for generic server applications, the transports may not be known and the implementer would have to make assumptions; we can't do much more, but at least ours get solid review.
In the course of this, we'll also have to give a citation for the "x 3" (currently URL)
Follow-up note to be factored into the resolution:
Change:
protocol. When User Equipment receives Captive Portal Signals, the User <del> Equipment MAY query the API to check the state.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </del> <ins> Equipment MAY query the API to check its state of captivity.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </ins> The API MUST be extensible to support future use-cases by allowing extensible information elements.

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
m= section, both "a=candidate" and "a=end-of-candidates" MUST be omitted. <del> For RtpTransceivers that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </del> <ins> For RtpTransceivers that are still present, the "a=msid" line MUST stay the same. </ins> For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same.

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [3] for the media types </del> <ins> https://iana.org/assignments/media-types [2] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [4] for the types </del> <ins> https://iana.org/assignments/http-problem-types [3] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.

Discussion:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...
Change:
one server, and that these never switch roles.  If this assumption is violated, then the security properties of TLS are severely weakened. <del> use-cases discusses use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </del> <ins> As discussed in use-cases, there are use cases where it is desirable for multiple clients or multiple servers share a PSK.  If this is done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious weaknesses here: </ins> Any group member can impersonate any other group member.

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
Sent by servers when a client "application_layer_protocol_negotiation" extension advertises <del> protocols that the server does not support. </del> <ins> protocols that the server does not support (see RFC7301). </ins> New Alert values are assigned by IANA as described in iana- considerations.

Discussion:
Follow up to PR . Add a link for the ALPN RFC to the relevant alert's description. (same as with other extension alerts above)
URL & No feature in the TLS 1.3 spec, optional or required, needs ALPN to work. We merely cite places where it needs to be taken into consideration if it is in use. It could be argued that it is an "optional feature" of TLS (as a whole), but not of this document, thus I don't think it meets the qualifications to be normative. I think staying as informative is correct.
There's a bunch of text that specifically mentions ALPN, some of it with normative statements. If those normative statements can't be understood, optional feature or not, then it's normative.
Change:
unreliable delivery (such as when the QUIC DATAGRAM extension DGRAM is available to HTTP/3 H3), HTTP Datagrams can use that capability. <del> In capsule, this document describes the HTTP Capsule Protocol, which allows the conveyance of HTTP Datagrams using reliable delivery. This addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable or where the transport protocol only provides reliable delivery, such as with HTTP/1.1 H1 or HTTP/2 H2 over TCP TCP. </del> <ins> In capsule, this document describes HTTP Datagrams, a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible.  This addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable or where the transport protocol only provides reliable delivery, such as with HTTP/1.1 H1 or HTTP/2 H2 over TCP TCP. </ins> 1.1.

Discussion:
We had the following questions related to the descriptions of "HTTP Datagrams" in a few places throughout the text. a) We see the following similar sentences in the Abstract, Introduction, and , respectively. Please review and let us know if this text should be made more uniform. Original (Abstract): This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. Original (Intro): In , this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange of data inside an HTTP connection. Original (): HTTP Datagrams are a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible. b) Pending changes made in (a) above, we will update the first sentence of the Abstract as follows unless we hear objection Original: This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. Perhaps: This document describes a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection called “HTTP Datagrams”. c) This sentence, which is somewhat related, seems a bit odd in that it seems sending something "unreliably" is desired. Should any clarification here be added? Original: In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension.
a) I'm happy with the abstract being succinct. I think we could probably my the Intro and Section 2 more uniform. Suggest use Section 2 text in the intro. b) I'm not a huge fan of the scary quotes suggested here. I like what we have already TBH. c) This seems fine. No change needed IMO
Fully agree with your comments
Change:
that it wants to receive as a connection identifier in encrypted records, it is possible for an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease <del> parsing and connection lookup, for example by having the length in question be a compile-time constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. </del> <ins> parsing and connection lookup, for example by having the length in question be a compile-time constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. </ins> Note that it is not possible to parse the records without knowing how <del> long the Connection ID is. </del> <ins> long the CID is. </ins> <del> In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post- handshake messages that do not themselves begin other handshakes. </del> <ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes. </ins> DTLS peers switch to the new record layer format, i.e., the record layer format containing the CID, when encryption is enabled.

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.