jiebi/CodeConvo huggingface dataset:
Change:
The client verifies the validity of a KeyPackage using the following steps: <del> Verify the LeafNode in the KeyPackage according to the process defined in leaf-node-validation. Verify that the signature on the KeyPackage is valid using the public key in the LeafNode's credential Verify that the ciphersuite and protocol version of the LeafNode </del> <ins> Verify that the ciphersuite and protocol version of the KeyPackage </ins> match those in use in the group. <del> 11.2. </del> <ins> Verify the "leaf_node" field of the KeyPackage according to the process defined in leaf-node-validation. </ins> <del> The "capabilities" extension indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are supported by a client.  Proposal types defined in this document are considered "default" and thus need not be listed. This extension MUST be always present in a KeyPackage.  Extensions that appear in the "extensions" field of a KeyPackage MUST be included in the "extensions" field of the "capabilities" extension. 11.3. The "lifetime" extension represents the times between which clients will consider a KeyPackage valid.  This time is represented as an absolute time, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  A client MUST NOT use the data in a KeyPackage for any processing before the "not_before" date, or after the "not_after" date. Applications MUST define a maximum total lifetime that is acceptable for a KeyPackage, and reject any KeyPackage where the total lifetime is longer than this duration. This extension MUST always be present in a KeyPackage. </del> <ins> Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential". </ins> <del> 11.4. </del> <ins> 11.2. </ins> Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
example, draft-ietf-quic-http-01 is identified using the string "h3-01". <ins> Draft versions MUST use the corresponding draft transport version as their transport.  For example, the application protocol defined in draft-ietf-quic-http-25 uses the transport defined in draft-ietf- quic-transport-25. </ins> Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier. For example, an experimental implementation based on draft-ietf-quic-

Discussion:
As discussed in Singapore, this ties HTTP/3 to QUIC version 1 until someone writes down how another QUIC version is used.
We've removed the text saying that application protocols can constrain which QUIC versions they can run over. We need to discuss where the correlation between ALPN tokens and version numbers gets considered. Some proposals discussed in Cupertino: ALPN tokens imply one specific QUIC version. This leads to a possible error case, where an ALPN token is offered/accepted over another QUIC version. Application protocols can restrict which QUIC versions they run over. This implies that the QUIC version being spoken must be considered when selecting an ALPN token.
Discussed with NAME this is fine in the TLS draft, but the HTTP/3 draft needs to have a firmer opinion. Right now it says "anything with TLS 1.3".
The discussion in Singapore seemed to end with the conclusion that HTTP/3 would be defined to refer to QUIC version 1 exclusively. But we decided not to answer the broader question of what ALPN actually refers to. That was considered too broad a topic for the QUIC WG to address without involving TLS, HTTP, and others.
Change:
known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to <del> specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del> <ins> specify alternate port numbers.  Other applications (e.g., Microsoft's SMB over QUIC) also use UDP port 443 by default. Therefore, simple assumptions about whether a given flow is using QUIC, or indeed which application it might be using QUIC, based solely upon a UDP port number may not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

Discussion:
AFAIK Microsoft's SMB-over-QUIC also uses 443.
Not sure we explicitly need to add that...?
It does underscore the point that HTTP/3 != 443, and 443 != HTTP/3. I think it's useful to add.
The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR
Change:
7. <del> 8. </del> There are no IANA considerations for this document. <del> 9. [TBD] 10. </del> <ins> 8. </ins> The authors would like to thank Mo Zanaty and Christian Oien for invaluable input on this document.  Also, we would like to

Discussion:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG
Change:
VNF: Virtual Network Function. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </ins> 2. This section describes the components in a satellite system based on

Discussion:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.
Change:
While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit <del> having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </del> <ins> having more than one in flight.  When using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will

Discussion:
"Generally, when using maxackdelay for PTO computations, endpoints MUST use the maximum of the current value and all those in flight." I think the words generally and MUST do not sit well together, and it would be better to say what is the requirement.
Change:
consistent with the existing DTLS association, if the association is being continued by the offerer. <ins> RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted if and only if the m= section previously used RTCP multiplexing. </ins> If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate.

Discussion:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits
Change:
value). The query is a root identifier followed by a sequence of zero or more <del> , each of which is applied to the result of the previous root </del> <ins> segments, each of which is applied to the result of the previous root </ins> identifier or segment and provides input to the next segment.  These results and inputs take the form of a nodelist.

Discussion:
This is currently done inconsistently and doesn't add much value. Instead, define terms in the Terminology section. Reviewers please note: is not modified. This avoids a clash with URL which deletes the term.
Let's wait until lands before sorting this PR out. Meanwhile, rebased on main and kept one of the italicisations which was previously removed.
I've reinstated the other italics which NAME favoured.
Change:
Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however, NSEC3 records mitigate against zone <del> enumeration and support Opt-Out.  NSEC resource records require </del> <ins> enumeration and support Opt-Out.  NSEC3 resource records require </ins> associated NSEC3PARAM resource records.  NSEC3 and NSEC3PARAM resource records are defined in RFC5155.

Discussion:
There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".
Change:
can fail to generate an assertion and instead indicate a URL where login should proceed. <del> A calling site is then able to load the provided URL in an IFRAME in order to trigger the required user interactions.  Once any user interactions are complete, the IFRAME MUST send a WebMessaging to the calling site indicating that login has completed.  Any message is sufficient for this purpose, the "source" parameter identifies the originating IFRAME. </del> <ins> The application can then load the provided URL to enable the user to enter credentials.  The communication between the application and the IdP is described in webrtc-api. </ins> 5.7.

Discussion:
This is the companion to w3c/webrtc-pc A move to JS realms and so forth removes the need for a "protocol" in this document. Instead, I've tried to focus here on what information needs to pass between the browser and the IdP, rather than be prescriptive. I didn't reindent anything, so it's a mess. I also didn't move Section 5.6 up a level, as I am sorely tempted to do. Hopefully these changes are easy enough to review as they are.
Change:
The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is <del> signed using the client's identity key.  A KeyPackage object with an </del> <ins> signed using the client's signature key.  A KeyPackage object with an </ins> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field.

Discussion:
The public key in a credential is introduced without a special name and the field in the BasicCredential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key. I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".
Change:
may appear in ClientHello messages from clients which are offering prior versions of TLS). <ins> 4.2.4.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert. PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension.  The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </ins> 4.2.5. The "post_handshake_auth" extension is used to indicate that a client

Discussion:
This was the one extension that wasn't in the extensions section, which made it hard to find. Note I've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text.
Does the part that says need to be updated to point to this new location instead of {{certificate-request}}?
Good catch. Fixed.
lgtm
merge this when ready
Change:
the same. Check that the "account" field of the key-change object contains <del> the URL for the account matching the old key. </del> <ins> the URL for the account matching the old key </ins> <del> Check that the "newKey" field of the key-change object contains the key used to sign the inner JWS. </del> <ins> Check that the "newKey" field of the key-change object also verifies the inner JWS. </ins> If all of these checks pass, then the server updates the corresponding account by replacing the old account key with the new

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
option is critical, safe to forward, part of the cache key, and not repeatable. <del> The Object-Security option contains the OSCORE flag byte and for requests, the Sender ID (see compression).  If the flag byte is all zero (0x00) the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </del> <ins> The Object-Security option contains the OSCORE flag byte, the Sender Sequence Number and the Sender ID when present, (see compression). If the flag byte is all zero (0x00) and no other fields are present, the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </ins> A successful response to a request with the Object-Security option SHALL contain the Object-Security option.  Whether error responses

Discussion:
This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value. The text about kid being the last field is a draft, please modify if you have any better formulation.
Change:
This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the value of the Recommended column.  A Standards Track document <del> RFC8126 is required to register an extension with the value "Yes". </del> <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> 9.

Discussion:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .
Change:
provides confidentiality and integrity protection for subscriptions and push messages from external parties. <del> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </del> 8.1. The protection afforded by TLS does not protect content from the push service.  Without additional safeguards, a push service can inspect and modify the message content. <del> For its requirements, the API has adopted I-D.ietf-webpush-encryption </del> <ins> Applications using this protocol MUST use mechanisms that provide end-to-end confidentiality, integrity and data origin authentication. The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. For this requirement, the API has adopted I-D.ietf-webpush-encryption </ins> to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies.

Discussion:
Ben commented in his review that the requirement for confidentiality seemed to be covered by TLS, unless the text was actually referring to e2e protections (which I believe that it was). Moving the paragraph from the introduction of S8 to the immediate subsection resolves this confusion.