jiebi/CodeConvo huggingface dataset:
Change:
a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] <del> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure.  For the purpose of computing the checksum, the value of the "checksum" field MUST be set to zero. </del> The non-empty name of the entity trusted to update these encryption keys.  This is used to repair misconfigurations, as described in handle-server-response.

Discussion:
The checksum seems to add little value with the retry mechanism and record_digest. I think we should remove it. See for some context.
The I-D says: "recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with suite." From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys (after base64 decode) including the version and checksum. Is that correct? IOW, does the following also produce the right value (for CF and sha256)? `
proposes removing the checksum, which should clear this up.
Closing since landed. NAME please re-open if this is still an issue!
The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.
I support the change, if that makes people feel more comfortable about having the checksum field in ESNIKeys.
I'm not opposed, but it doesn't help as much as you might think, because you need to compute the label with the cipher hash and not (necessarily) with SHA-256.
So, if you take my suggestion in (which I know NAME doesn't like, but we simply disagree about that), then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake. But that just suggests that this is either not-helpful because we chose not to do anything in , or it is not necessary because we did. I'm OK closing this on that basis.
Checksum is now gone. Closing this issue. NAME thanks for filing it!
I agree that we can now and should make this simplification. The PR looks good to me.
Change:
it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp. <ins> This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> This field can be sent in a trailer section. An example of RateLimit-Reset field use is below.

Discussion:
Parameters are not allowed, and if they appear they MUST be ignored.
Why not just 'If Parameters appear they MUST be ignored'?
NAME we wanted to stress the fact that servers are not expected to provide parameters, otherwise some clients could just consider the whole field value malformed and ignore it.
The normal way to do that is something like:
Ok, I'll rebase this PR tomorrow :) Late night now in Italy. Thanks for all this support :)
In a few places, the specification says "Parameters are not allowed" but does not spell out what should happen if they appear.
Change:
Therefore it needs to respond to the request without waiting for a packet from the target.  However, if the target_host is a DNS name, the proxy MUST perform DNS resolution before replying to the HTTP <del> request.  If DNS resolution fails, the proxy MUST fail the request and SHOULD send details using the Proxy-Status header field PROXY- STATUS. </del> <ins> request.  If errors occur during this process (for example, a DNS resolution failure), the proxy MUST fail the request and SHOULD send details using the Proxy-Status header field PROXY-STATUS. </ins> Proxies can use connected UDP sockets if their operating system supports them, as that allows the proxy to rely on the kernel to only

Discussion:
Section 3.1 mentions proxy handling requirements and notes a DNS failure SHOULD be communicated in the response using Proxy-Status. Is that the only case? Maybe it's worth mentioning that the header can be used for any other type of failure too.
It's linked to a SHOULD requirement
Fair enough. Let it be known that by this issue, NAME has volunteered to become Area Director.
I have been volunteered many times by other people, I don't think this one will change anything
Change:
values. In addition, various RFCs put different conditions on the format of <del> offers versus answers.  For example, a offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </del> <ins> offers versus answers.  For example, an offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </ins> Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, it is possible for the

Discussion:
Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM
Change:
[RFCthis] <ins> 6.5. IANA is requested to register the WebSocket CoAP subprotocol under the "WebSocket Subprotocol Name Registry": coap Constrained Application Protocol (CoAP) [RFCthis] </ins>

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
those in the GroupInfo object, according to the definitions of those extensions. <ins> Any field containing a list of extensions MUST NOT have more than one extension of any given type. </ins> Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group MUST be supported by all members of the group.

Discussion:
A GroupInfo (or a PublicGroupState) should only ever contain one RatchetTreeExtension. Either that or it should be specified what happens if there is more than one.
Seems like we should be able to make a general proclamation that extension IDs MUST be unique in a given vector of extensions, whether that's GroupContext, KeyPackage, GroupInfo, GroupContextExtensions, etc.
Sounds good to me. I'll draft a PR.
SGTM, one minor rephrasing for more clarity.
Change:
where "pk" is the aggregator's public key; "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper), "task_id" is the task ID, "metadata" is the report metadata, <del> and "input_share" is the Aggregator's input share. </del> <ins> and "input_share" is the Aggregator's input share.  The "SealBase()" function is as specified in HPKE for the ciphersuite indicated by the HPKE configuration. </ins> The order of the encrypted input shares appear MUST match the order of the task's "aggregator_endpoints".  That is, the first share

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:
Initial contents: The codes and descriptions in the table in errors above, with the Reference field set to point to this specification. <del> 8.6.2. </del> <ins> 8.6.4. </ins> This registry lists the types of resources that ACME servers may list in their directory objects.

Discussion:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..
Change:
5.2. <ins> The generic "$HTTPFrame" is defined here as a CDDL extension point (a "socket" or "plug").  It can be extended to support additional HTTP/3 frame types. The HTTP/3 frame types defined in this document are as follows: </ins> 5.2.1. 5.2.2.

Discussion:
In doing the exercise to try and define a new DATAGRAM extension for qlog (at URL), it became clear that we only had a CDDL extension point for the events themselves () but NOT for the individual QUIC and HTTP/3 frames. This is needed so we can add the CDDL definitions for new frames in other documents and have them properly matched to the CDDL expectations of "main document" events like and .
LGTM modulo some editorial nits
Change:
agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent as above. <del> ** RECOMMENDATION:** Have an explicit group policy setting the </del> <ins> *RECOMMENDATION:* Have an explicit group policy setting the </ins> conditions under which external joins are allowed. 5.5.

Discussion:
WGLC comments to Functional Requirements Section: Include text for case when external joins are authorized by members autonomously Fix formatting of one RECOMMENDATION section Reference the mls-federation document (informational)
Following on from discussion in Even once a GroupInfo has been published to a prospective new joiner, there are still a few opportunities to apply authorization policy to the join: The DS can block the external Commit from reaching the group members (requires intelligent DS) The clients in the group can all refuse to apply the external Commit (requires consistent policy) Any client can remove the member after allowing them to join (might expose some group comms to the joiner)
Comment by NAME This seems rather risky? What could such a member do in the short time between getting added and getting kicked? Would they see message history? Group membership? How many devices a user has? When members were last online? Why support such a group type? Wouldn't it be better to not support this and have an automated "special member" being a bot that handles member addition?
Until someone else sends a message, a new joiner doesn't learn anything non-public. If you think about it, how would they? They're outside the group before they send an external join, and the external join just establishes a new shared secret with the group for future communications. More specifically: Message history - MLS's forward secrecy guarantees mean that new joiners don't get message history. Group membership - This is public anyway via the GroupInfo that an external joiner needs to join How many devices - To the degree this is exposed, it would be in the group membership Last online - MLS doesn't have any notion of this As for an "add me bot", it's a useful idea, but not applicable to a bunch of cases. The bot has to be a member of the group and has to be always-online. So now you have the group's secrets on a server somewhere, instead of just in the communicating endpoints, already an additional point of compromise. And it can't be the DS's server, since the whole point is to protect against the DS.
This statement in the draft is just plain wrong. In our implementation, we actually do validation of External joins at the application layer.

I addressed this in (dating from WGLC) which says the following: "External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail."
Change:
logically independent of each other even if some transports can share same connection underneath. <del> A transport protocol (WebTransprot protocol in context where this </del> <ins> A transport protocol (WebTransport protocol in context where this </ins> might be ambiguos) is a protocol that can be used to back a transport on the wire.  It can provide the transport features described in this document, and is expected to fulfill all of the

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
by publishing different DNS records containing ECHConfig values with different keys using a short TTL. <del> 10.8.3. </del> <ins> 10.9.3. </ins> This design requires servers to decrypt ClientHello messages with ClientECH extensions carrying valid digests.  Thus, it is possible

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
out of scope for this document.  In particular, this document defines: <del> the use of the Elliptic Curve Diffie-Hellman key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA certificates for authentication of TLS peers. </del> <ins> the use of the ECDHE key agreement scheme with ephemeral keys to establish the TLS premaster secret, and the use of ECDSA and EdDSA signatures for authentication of TLS peers. </ins> The remainder of this document is organized as follows. ecdh provides an overview of ECC-based key exchange algorithms for TLS. clientauth

Discussion:
Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme
lgtm
Change:
To download the issued certificate, the client simply sends a GET request to the certificate URL. <del> The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/x-pem-file to request the certificate in PEM format. The server provides metadata about the certificate in HTTP headers. In particular, the server MUST send one or more link relation header fields RFC5988 with relation "up", each indicating a single certificate resource for the issuer of this certificate.  The server MAY also include the "up" links from these resources to enable the client to build a full certificate chain. </del> <ins> The default format of the certificate is PEM (application/x-pem-file) as specified by RFC7468.  This format should contain the end-entity certificate first, followed by any intermediate certificates that are needed to build a path to a trusted root.  Servers SHOULD NOT include self-signed trust anchors.  The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/pkix-cert to request the end- entity certificate in DER format. The server MAY provide one or more link relation header fields RFC5988 with relation "alternate".  Each such field should express an alternative certificate chain starting with the same end-entity certificate.  This can be used to express paths to various trust anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. </ins> The server MUST also provide a link relation header field with relation "author" to indicate the application under which this

Discussion:
One of the most common ACME deployment failures observed in practice is for servers to be configured to serve only the end-entity certificate, without the intermediate certificates. This is a particularly pernicious problem because some browsers will still trust the resulting one-certificate chain, due to caching or fetching of URLs from Authority Information Access. But other browsers will not, resulting in a "works on my computer" problem. Arguably this configuration is the result of incorrect clients, but we should expect that most clients will do the easiest thing. This change aligns the easiest thing with the most correct thing.
You should include advice here on omitting trust anchors. TLS 1.3 has you could crib from (see the definition of ).
Hi, the PEM text is not correct: application/x-pem-file is not a registered media type, among other things. Will post to mailing list with details.
Change:
the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del> <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that

Discussion:
lgtm
need to be to "an" like in line 854?? URL
Fixed by
The word Blob is missing? URL
Change:
the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released.  A description used as an "answer" may be applied as a <del> response to a "offer", or an update to a previously sent "pranswer". </del> <ins> response to an "offer", or an update to a previously sent "pranswer". </ins> The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
4.3.1. <del> In the manual allocation method, the configuration agent assigns at </del> <ins> In the static allocation method, the configuration agent assigns at </ins> least one server ID to each server. When forwarding a packet with a long header and non-compliant DCID,

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.