jiebi/CodeConvo huggingface dataset:
Change:
Specifies the authentication and key establishment algorithms, the hash for use with HKDF to generate keying material, and the record <del> protection algorithm (See the-security-parameters for formal definition.) </del> <ins> protection algorithm </ins> a secret shared between the client and server that can be used as a pre-shared symmetric key (PSK) in future connections.

Discussion:
The section on connection states was almost all cruft. I made a new section for nonce construction and moved the piece on sequence numbers there. The only text I modified was the first three paragraphs of the nonce section, which needed to be scrubbed for references to "connection state", and the lead-in section on the AEAD, which I moved to where the other AEAD stuff was and expanded a little to include some forward references.
LGTM NAME Did you still want to replace any of this? The stuff being cut here is very obsolete and must confuse anyone who attempts to read through the whole spec.
Yes, I'm working on it this week. , Dave Garrett EMAIL wrote:
Change:
6.3.2. <ins> For this functionality, note that we supply multiple tokens in "msg" to "Evaluate".  This allows batching a single proof object for multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf only permits a single input, we follow the advice for providing vectors of inputs. </ins> 6.3.3. <ins> Similarly to "Issue", we follow the advice for providing vectors of inputs to the "Unblind" function for verifying the batched proof object. </ins> 6.3.4. 6.3.5.

Discussion:
Rewrite parts of intro Clean up protocol overview Rewrite API functions Rewrite protocol instantiation Update ciphersuites (This is a big change, apologies!) cc NAME NAME for reviews (will also notify mailing list).
API has been updated at URL quite substantially.
SecretKey, to me, implies a symmetric key. Can we make this PrivateKey? That's the terminology used (mostly) in RFC7748, at least.
Done in
Change:
spans of bytes, those spans of bytes are considered independent Messages.  Boundaries of a Message might or might not be understood or transmitted by transport protocols.  Specifically, <del> what one application considers to be two Messages sent on a </del> <ins> what one application considers to be multiple Messages sent on a </ins> stream-based transport can be treated as a single Message by the <del> application on the other side. </del> <ins> application on the other side, and vice versa. </ins> Message Properties: Message Properties can be used to annotate specific Messages.  These properties might only apply to how

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
media metadata will be moved out of the encoded frame buffer, to be used later in the RTP generic frame header extension.  The encoded frame, the metadata buffer and the frame counter are passed to SFrame <del> encryptor.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame, the media metadata and the header are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> encryptor. SFrame encryption uses the AEAD encryption algorithm for the ciphersuite in use.  The key for the encryption is the "sframe_key" and the nonce is formed by XORing the "sframe_salt" with the current counter, encoded as a big-endian integer of length "AEAD.Nn". The encryptor forms an SFrame header using the S, CTR, and KID values provided.  The encoded header is provided as AAD to the AEAD encryption operation, with any frame metadata appended. </ins> The encrypted payload is then passed to a generic RTP packetized to <del> construct the RTP packets and encrypts it using SRTP keys for the HBH </del> <ins> construct the RTP packets and encrypt it using SRTP keys for the HBH </ins> encryption to the media server. 4.3.3.

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del> <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.10.

Discussion:
Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn't let an application control anything.
LGTM
Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and ³RtpReceivers². 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful.
Section 3.4.1 is its own section, and explains what the RtpTransceiver is. Agree that Sections 3.4.2/3.4.3 (on senders/receivers) could be expanded somewhat. NAME FYI
Resolved by
Change:
RFC6690 only describes how to discover resources from the web server that hosts them by querying "/.well-known/core".  In many constrained scenarios, direct discovery of resources is not practical due to <del> sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </del> <ins> sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </ins> This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and

Discussion:
We were asked about the term in Erik's comments, and nobody could explain its relevance to the RD; removing it. See-Also: URL
Change:
value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 6.5.1. </del> <ins> 6.4.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 6.5.1. </del> <ins> 6.4.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
The semantics of the other CoAP header fields are left unchanged. <del> 2.5. </del> <ins> 2.4. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Discussion:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).
Change:
application <del> private-token-request </del> <ins> token-issuer-directory </ins> N/A

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
Imported PSKs are not used as IKM for two different KDFs. <del> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below. </del> Imported PSKs do not collide with future protocol versions and KDFs. <ins> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions when possible, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

Discussion:
The gist of the feedback, as I understood it, was that we made claims that were quite strong. This relaxes the language a bit and draws on RFC8446 for some example text. cc NAME NAME NAME
Hard to pick up the differences here, but I think that I got them.
Change:
than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. <del> This 7 day limit allows for changes in server configuration.  If </del> <ins> This 7-day limit allows for changes in server configuration.  If </ins> server configuration changes and a client does not set the QUIC Bit, then it is possible that a server will drop packets, resulting in connection failures. <del> A server MUST set the QUIC bit to 0 only after processing transport </del> <ins> A server MUST set the QUIC Bit to 0 only after processing transport </ins> parameters from a client.  A server MUST NOT remember that a client negotiated the extension in a previous connection and set the QUIC Bit to 0 based on that information.

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or <del> not present in the offer. </del> <ins> not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP endpoints MUST be prepared to receive such answers. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf-

Discussion:
Fixes issue .
Note that I made this a MAY and not a MUST, because the only precedent for a MUST in codec selection is with regards to the mandatory codecs.
This seems like it still needs some more work, as we discussed earlier.
I added some more informative text about non-JSEP endpoints. Does this address your concerns Ekr? There are still some questions about when (if ever) a JSEP endpoint is allowed to include previously discarded codecs in an offer (issue ), but this PR should at least address issue .
Browser offer MCU, VP9, and VP10. MCU answers with VP10. Offer / answer completes. Later the MCU offers VP9 to browser on m-line that was currently use VP10. What does the browser do? A strict reading of spec might suggest that since MCU only offered VP9, and current is VP10, the m-line should be rejected. Do we need to change this ? Is it OK for browser to respond with VP9.
Previously I've heard people say "the non-JSEP endpoint can do whatever it wants with codecs." For example, in the thread for issue .
It is definitely OK for the browser to accept the VP9 in the updated offer and I would go further and say that it must accept VP9 in such an updated offer if it is capable of doing so. The spec should make it clear that browsers MUST accept such codec changes in updated offers.
If we solve this, should resolve.
Originally raised by Magnus. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section.
there is another bug on this too - I agree we could change this
Obsoleted by events - moved to BUNDLE
With changes above
Change:
As an answer, the generated SDP will contain a specific configuration that specifies how the media plane should be established; for each SDP line, the generation of the SDP MUST follow the process defined <del> for generating an answer from the document that specifies the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </del> <ins> for generating an answer from the specification that defines the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </ins> Session descriptions generated by createAnswer MUST be immediately usable by setLocalDescription; like createOffer, the returned

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
should not terminate an earlier child connection attempt upon starting a secondary child. <del> If a child node fails to connect before the delay time has expired for the next child, the next child should be started immediately. </del> <ins> If a child node fails to establish connectivity (as in determining- successful-establishment) before the delay time has expired for the next child, the next child should be started immediately. </ins> Staggered racing between IP addresses for a generic Connection should follow the Happy Eyeballs algorithm described in RFC8305.  RFC8421

Discussion:
Section 4.2.2 says "If a child node fails to connect before..." without really defining if this means completing the handshake, or making some progress. 4.3.1 does a better job, but for readability there ought to be a reference or rewording in 4.2.2.
/to connect/ is problematic for me also, but /establish connectivity/ is less problematic, although always good to explain!
Change:
However, some legacy endpoints are not fully spec-compliant and can behave unpredictably in the presence of ICE candidates that contain a <del> hostname, potentially leading to ICE failure.  Such endpoints have been identified during testing of this technique, but appear to be rare. </del> <ins> hostname, potentially leading to ICE failure.  Some endpoints may also fail to handle a connectivity check from an address that they have not received in signaling.  During the aforementioned experimental testing, the connection rate when interacting with endpoints that provided raw IP addresses (and therefore should be unaffected) decreased by 3% (relative), presumably for these reasons. </ins> 5.

Discussion:
ping
Will we get sources for these numbers that elaborate distribution and regional differences?
LGTM modulo the thought on mentioning the potential impact of c= line before the update.
No answer to my question?
NAME I struggled to respond to the question since it's so open-ended, and really outside the scope of this PR. Suggest filing an issue and we can discuss more there.
Change:
the ESNIKeys structure.  For the purpose of computing the checksum, the value of the "checksum" field MUST be set to zero. <ins> 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. </ins> The list of keys which can be used by the client to encrypt the SNI.  Every key being listed MUST belong to a different group.

Discussion:
(WG email coming shortly.) ESNI has different compatibility characteristics than most TLS extensions. It involves client state, and encrypting the SNI makes the ClientHello unusable for servers that do not have the key or do not implement ESNI. This breaks common rollout and rollback strategies and places strong requirements on DNS/server consistency. This makes deploying ESNI risky for servers. This change aims to reduce these deployment risks. ESNI is much more useful if widely deployed. Moreover, if ESNI is unreliable due to complex requirements on the server, clients will be disincentivized to implement it. The DNS/server consistency requirements also disincentivize rotating keys (section 7.2.5). This change introduces the notion of a "public name" which allows the client to receive authenticated signals from the server that the ESNIKeys are out of sync, so clients can safely repair key mismatches. It also aligns with existing server behavior before ESNI, so partial rollouts and rollbacks can also be handled. The fix for the latter also handles MITM scenarios, replacing the existing client recommendation: The public name notion fixes a bug in that text: an attacker could disable ESNI on all servers, given the existence of any such server.
And, as I write this, I realize I forgot to deal with Stephen's comment on the thread about the middlebox stuff! It's quite late here, so I will reword that tomorrow morning.
Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.
How to understand the reliability of the public key from server?
I see that I missed something about disabling. I think that this could be a lot more explicit about the three primary cases that I talk about in the comments below.Looks mostly good, but added some nits and clarification questions.
Change:
Defining RFC <del> 7. </del> <ins> 5. </ins> The options defined in this document are carried in the base message objects as defined in RFC6550.  The RPL control message options are

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication. <del> 6. </del> <ins> 5. </ins> Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3

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:
2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages after processing at the message layer.  For Confirmable (CON), Non-Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. </del> <ins> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. </ins> 2.3.

Discussion:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.
Change:
Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value <del> in every packet is more of liability than an asset.  If systems come to depend on a fixed value, then it might become infeasible to define a version of QUIC that attributes semantics to this bit. </del> <ins> in every packet is more of a liability than an asset.  If systems come to depend on a fixed value, then it might become infeasible to define a version of QUIC that attributes semantics to this bit. </ins> In order to safeguard future use of this bit, this document defines a QUIC transport parameter that indicates that an endpoint is willing

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
16.10. <ins> The DS and AS may also apply additional policies to MLS operations to obtain additional security properties.  For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations.  MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted.  MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. 16.11. </ins> It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath encrypts a sequence of path secrets to different subtrees of the

Discussion:
This removes the following graf: The DS and AS may also apply additional policies to MLS operations to obtain additional security properties. For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations. MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted. MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. My sense is this belongs in Security Considerations, not here.
This looks good to me. Please do move the removed paragraph to the security considerations, either here or in .