jiebi/CodeConvo huggingface dataset:
Change:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. <del> The length of the "node_secrets" vector MUST be zero for the first </del> <ins> The length of the "node_secrets" vector MUST be zero for the first </ins> node in the path.  For the remaining elements in the vector, the <del> number of ciphertexts in the "node_secrets" vector MUST be equal to </del> <ins> number of ciphertexts in the "node_secrets" vector MUST be equal to </ins> the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution.

Discussion:
The underscore character does not have to be escaped in code environments. This applies to the inline (backticks) as well as block (tildes) variants.
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits.

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
One goal of this design is that independent requests are only linkable by their content.  However, the choice of configuration might be used to correlate requests.  A configuration includes the <del> URI, the Oblivious Gateway (KeyConfig), and URI.  A configuration is active if can successfully use it for interacting with with a target. </del> <ins> URI, the Oblivious Gateway , and URI.  A configuration is active if can successfully use it for interacting with with a target. </ins> Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching the key ID from the or the URI.

Discussion:
From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"
Change:
the new RTT to be included in smoothed_rtt. Endpoints SHOULD set the min_rtt to the newest RTT sample after <del> persistent congestion is established.  This is to allow a connection to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt) after a disruptive network event, and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. </del> <ins> persistent congestion is established.  This avoids repeatedly declaring persistent congestion when the RTT increases.  This also allows a connection to reset its estimate of min_rtt and smoothed_rtt after a disruptive network event; see smoothed-rtt. </ins> Endpoints MAY re-establish the min_rtt at other times in the connection, such as when traffic volume is low and an acknowledgment

Discussion:
3) [rfced] Does the following improve the readability of the paragraph? Current: Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established. This is to allow a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event (Section 5.3), and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. Perhaps: Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. This also allows a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event (Section 5.3).
I find this easier to read, but I think it may be subtly different, so I put it into a separate PR.
It doesn't change the meaning, but it does feel like the first sentence is trying to span too many topics. I like the reordering, but I'd split it out.This is good, thank you !
Change:
Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", </del> <ins> Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id", </ins> "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private <del> key, "skR", corresponding to "keyID". </del> <ins> key, "skR", corresponding to "key_id". </ins> <del> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </del> <ins> a.  If "key_id" does not identify a key matching the type of "kem_id", the server returns an error. </ins> <del> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </del> <ins> b.  If "kdf_id" and "aead_id" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </ins> Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, "keyID" as an 8-bit integer, plus "kemID", "kdfID", and "aeadID" as three 16-bit integers. </del> <ins> bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. </ins> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".

Discussion:
RFC 9180 does use skR/pkR/skS/skR, so I didn't change everything to use snake_case, but this is more consistent with how we identify things in other places. Also, it reads better and we don't have to grapple with whether it should be keyId or keyID.
Change:
6.4. DetNet flow identification at a DetNet service layer is realized by <del> an S-label.  It maps a Detnet flow to a specific d-CW in a DetNet node.  For a data flow the S-label used for flow identification MUST be bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. An S-label for a single DetNet flow does not need to be unique DetNet domain wide.  As long as two or more different DetNet flows do not errorneously map to a same d-CW in a DetNet node the labels may vary. </del> <ins> an S-label.  The S-lable is allocated from the platform label label space RFC3031 Thich means that the DetNet flow is correctly identified and matched to the flow parameters, including the flow history, regardless of which input interface the packet arrives on. The S-label MUST be at the bottom label of the label stack for a DetNet-s- or DetNet-st-flow and MUST precede the d-CW. The S-label for a specific DetNet flow is unique to that DetNet flow on a specific node, but is not required to be identical with the S-lable for that DetNet flow in any other node within the DetNet domain.  Thus the S-label can only be used to identify the DetNet flow at the intended receiving node. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
In order to send an encrypted SNI, the client MUST first select one of the server ESNIKeyShareEntry values and generate an (EC)DHE share <del> in the matching group.  This share is then used for the client's "key_share" extension and will be used to derive both the SNI encryption key and the (EC)DHE shared secret which is used in the TLS key schedule.  This has two important implications: The client MUST only provide one KeyShareEntry </del> <ins> in the matching group.  This share will then be sent to the server in the EncryptedSNI extension and used to derive the SNI encryption key. It does not affect the (EC)DHE shared secret used in the TLS key schedule. </ins> <del> The server is committing to support every group in the ESNIKeys list (see below for server behavior). </del> <ins> Let Z be the DH shared secret derived from a key share in ESNIKeys and the corresponding client share in EncryptedSNI.key_share.  The SNI encryption key is computed from Z as follows: </ins> <del> The SNI encryption key is computed from the DH shared secret Z as follows: </del> <ins> where ESNIContents is as specified below and Hash is the hash function associated with the HKDF instantiation. </ins> The client then creates a PaddedServerNameList:

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate <del> the registration under which this certicate was issued.  The server MAY also include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del> <ins> the registration under which this certicate was issued. The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) If the CA particpates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was submitted to a CT log.  An SCT can be included as a extension in the certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation "ct-sct". </ins> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA

Discussion:
The idea here is that if the CA opts not to log the precertificates it has a mechanism for publishing the proofs that are associated with a cert.
There are two good mechanisms to do this without adding a new endpoint: The CA implementing ACME can include SCTs in its OCSP responses Subscribers that wish to use SCTs, for instance in the TLS Extension mode of operation, may fetch those SCTs directly from the CT logs.
Neither of these seem like great substitutes. The first seems to violate straightforward reference semantics. The second puts a lot more work on the server.
I think this can be easily solved with a .
Change:
9. <ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. To do so, some mechanism of ensuring that the Evidence and Attestation Result are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, may change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. </ins> 10. The conveyance of Evidence and the resulting Attestation Results

Discussion:
Based on discussion at IETF about including a very high level summary, and text in the arch docs, draft-birkholz-rats-reference-interaction-model, and draft-birkholz-rats-tuda. Signed-off-by: Dave Thaler
A quick review of the strawman, using the strawman to highlight a few points for discussion.
Change:
12.3. <del> Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. </del> <ins> Handles, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. </ins> An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever,

Discussion:
by removing the sentence which didn't add any critical point. Also mention replaying in the list of potential nefarious activities. Signed-off-by: Dave Thaler
In context, I am not sure what that sentence is trying to tell me.
I think it means that an Attacker might or might not have actually received the epoch ids from the epoch id distributor.
Change:
HTTPS server. Verify that the Content-Type header of the response is either <del> absent, or has the value "application/jose+json" </del> <ins> absent, or has the value "application/jose+json". </ins> <del> Verify that the body of the response is a valid JWS of the type indicated by the Content-Type header (if present), signed with the client's account key </del> <ins> Verify that the body of the response is a valid JWS, signed with the client's account key. </ins> Verify that the payload of the JWS meets the following criteria: * <del> It is a valid JSON dictionary * It has exactly four fields * Its "type" field is set to "simpleHttp" * Its "token" field is equal to the "token" field in the challenge * Its "path" field is equal to the "path" field in the response * Its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent </del> <ins> it is a valid JSON dictionary; * it has exactly three fields; * its "type" field is set to "simpleHttp"; * its "token" field is equal to the "token" field in the challenge; * its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent. </ins> <del> Comparisons of the "path" and "token" fields MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </del> <ins> Comparisons of the "token" field MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from <del> unencrypted DNS to encrypted DNS when only the IP address of an encrypted resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </del> <ins> unencrypted DNS to encrypted DNS when only the IP address of a resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is </ins> known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities.

Discussion:
I've made a few changes to terms used to correct some accidental lies: the starting IP address could be of an Encrypted Resolver, but does not have to be, discovery by SVCB may discover one or more resolver which may or may not be the original resolver, etc.
Change:
provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving <del> mode of I-D.ietf-avtcore-6222bis).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </del> <ins> mode of RFC7022).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </ins> 4.4.2.

Discussion:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.
Change:
thread. The Transport Services API can allow applications to explicitly <del> define Connection Groups that force separation of Cached State and </del> <ins> define Connection Contexts that force separation of Cached State and </ins> Protocol Stacks.  For example, a web browser application might use <del> Connection Groups with separate caches for different tabs in the </del> <ins> Connection Contexts with separate caches for different tabs in the </ins> browser to decrease linkability. <del> The interface to specify a Connection Group can expose fine-grained tuning for which properties and cached state is allowed to be shared with other Connections.  For example, an application might want to allow sharing TCP Fast Open cookies across groups, but not TLS session state. </del> 5. RFC-EDITOR: Please remove this section before publication.

Discussion:
Fix terminology in -arch Add minimal connection contexts in -interface
We had not decided that yet: We agreed that the property was sufficient as portable interface for the purpose We did not yet because did nit fix the inconsistencies between Connection Groups in -architecture and -interface So what we could do (als an alternative to this PR) to - Drop the stuff this PR renamed to "Connection Context" from -arch all-together Merge the changes in -arch, but do not include the minimal Connection Context into -interface an try to squish question about the context missing in -interface in later reviews
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Did we decide to explicitly introduce this new connection context?
Change:
[RFC5246][RFC8447][RFC-to-be] <del> 9. </del> <ins> 8. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 10. </del> <ins> 9. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin

Discussion:
I didn't add a -08 version of the doc (datatracker keeps that history), and this keeps the diff smaller. cc NAME NAME
Should we remove the 7525 text now that 7525bis is underway.
Could you also: remove the reference to 7525 on line 14 drop 7525 from line 45, i.e., change the header. This I-D will no longer update the 7525. drop "and RFC 7525" line 137. drop "and " from line 158 Like
Change:
An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf- rtcweb-rtp-usage. If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line

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.