jiebi/CodeConvo huggingface dataset:
Change:
6.1. Each ACME function is accomplished by the client sending a sequence <del> of HTTPS requests to the server, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate-management below describes the message formats used by the function and the order in which messages are sent. </del> <ins> of HTTPS requests to the server RFC2818, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate- management below describes the message formats used by the function and the order in which messages are sent. </ins> In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.  The ACME server acts

Discussion:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.
Change:
this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) <ins> Subsequently, the Inernet Architecture Board (IAB) held a COVID-19 Network Impacts Workshop IABcovid in November 2020.  Given a larger number of reports and more time to reflect, the following observations from the draft workshop report are worth considering. Participants describing different types of networks reported different kinds of impacts, but all types of networks saw impacts. Mobile networks saw traffic reductions and residential networks saw significant increases. Reported traffic increases from ISPs and IXPs over just a few weeks were as big as the traffic growth over the course of a typical year, representing a 15-20% surge in growth to land at a new normal that was much higher than anticipated. At DE-CIX Frankfurt, the world's largest Internet Exchange Point in terms of data throughput, the year 2020 has seen the largest increase in peak traffic within a single year since the IXP was founded in 1995. The usage pattern changed significantly as work-from-home and videoconferencing usage peaked during normal work hours, which would have typically been off-peak hours with adults at work and children at school.  One might expect that the peak would have had more impact on networks if it had happened during typical evening peak hours for video streaming applications. The increase in daytime bandwidth consumption reflected both significant increases in "essential" applications such as videoconferencing and VPNs, and entertainment applications as people watched videos or played games. At the IXP-level, it was observed that port utilization increased. This phenomenon is mostly explained by a higher traffic demand from residential users. </ins> 3. 3.1.

Discussion:
…nd update public discussion venues
I left the previous description of Sanjay Mishra's presentation, but removed the sub-references in that description (which included the problematic ATT reference).
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?
Change:
Update the ratchet tree by replacing nodes in the direct path from the removed leaf using the information in the Remove message <ins> Reduce the size of the roster and the tree until the rightmost element roster element and leaf node are non-null </ins> Update the ratchet tree by setting to blank all nodes in the direct path of the removed leaf

Discussion:
Right now, we blank out leaf nodes when we remove their holders, but we never reduce the size of hte tree or repopulate interior blanks with new members. This PR adds those functions: Reduce the size of the tree and the roster when you remove from the right edge Add an field to the message, to enable new members to be added to blank slots in the tree, not just at the right edge. In addition to performing "garbage collection", this change should make it easier to do a state resync -- just remove the desync'ed endpoint and add them back in the same spot.
NAME Do you think this is ready to merge? say it's OK as long as we can convince ourselves that truncation preserves the tree invariant. Proof sketch: The tree invariant is a universal statement over nodes in the tree and members in the group: ! Since subtrees are just subsets of the set of nodes in the tree, if the tree invariant holds for a given tree, then it also holds for any subtree of that tree. So since truncation just moves from a tree to a subtree, the invariant continues to hold.
Currently, the tree only ever grows: When you add someone, you have to add them at the right edge, even if there are blank leaves When you remove someone, the tree never shrinks We should enable reclaiming of blank leaves and automatically reduce the size of the tree to the minimum necessary size.
After discussion at 2019-01 interim: Agreement that this seems OK as long as we can verify that the tree invariant holds when you truncate the tree.
Change:
The ESNIKeys structure contains the following fields: The version of the structure.  For this specification, that value <del> SHALL be 0xff02.  Clients MUST ignore any ESNIKeys structure with </del> <ins> SHALL be 0xff03.  Clients MUST ignore any ESNIKeys structure with </ins> a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]]

Discussion:
Since the client's ESNI key share doesn't change across CHs in response to a HRR, the same AEAD IV would be used to encrypt/decrypt two different messages. This is an attempt to fix that, while also specifying the server-side HRR behavior. (Basically, check that the ESNI contents have not changed.)
Nice catch, Would it make more sense to instead use the KeyShare as a salt in the HKDF?
Or you could include the handshake transcript up to, but not including, the ClientHello. That is the empty string before HRR< but something else after.
That is a little iffy with cookie-only HelloRetryRequests. Those don't change the ClientHello key shares list, so the client would derive the same key + nonce pair. The client would also use the same plaintext so it's fine, but it seems an unnecessarily fragility.
Agreed. I think I prefer the "new DH" version.
Thank you for the changes! LGTM.
Change:
"extensions": The new GroupContext extensions (possibly updated by a GroupContextExtensions proposal) <del> Apply the UpdatePath to the tree, as described in </del> <ins> Decrypt the path secrets for UpdatePath as described in </ins> synchronizing-views-of-the-tree, using the provisional <del> GroupContext when decrypting the path secret and storing "leaf_node" at the committer's leaf. </del> <ins> GroupContext as the context for HPKE decryption. </ins> Define "commit_secret" as the value "path_secret[n+1]" derived from the last path secret value ("path_secret[n]") derived for

Discussion:
Conflicts with (in derivation of ) This is intended just to move around the required steps and give them clearer labels. Please keep an eye out for things that might have accidentally been added or dropped.
Interim 2022-06-02: NAME to review, then clear to merge
Currently, we only have explicit algorithm steps for validating an UpdatePath. We should have a similar level of concreteness for the process of creating an UpdatePath.
Change:
An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  For audio, the codecs specified in I-D.ietf-rtcweb-audio, Section 3, MUST be be supported. </del> <ins> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5). </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

Discussion:
lgtm with justin's comments.
Ping on this
overall this LG for consistency with the surrounding text, I would change the usage of "[XXXX] (see Section 3)" to "[XXXX], Section 3"
Change:
ESNI TXT query).  The client MUST NOT send encrypted SNI using groups or cipher suites not advertised by the server. <ins> When offering an encrypted SNI, the client MUST NOT offer to resume any non-ESNI PSKs.  It additionally MUST NOT offer to resume any sessions for TLS 1.2 or below. </ins> Let Z be the DH shared secret derived from a key share in ESNIKeys and the corresponding client share in ClientEncryptedSNI.key_share. The SNI encryption key is computed from Z as follows:

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:
value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 5.6.1. </del> <ins> 5.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:
Move description of registration and authorization objects to Certificate Management section Re-frame Protocol Elements section to be more clearly about the transport layer Fix some references
Change:
message per epoch. Much like the Authentication Service, the Delivery Service can be <del> split between server and client components.  Acheiving required </del> <ins> split between server and client components.  Achieving the required </ins> uniqueness property will typically require a combination of client and server behaviors.  For example, all of the following examples provide a unique Commit per epoch:

Discussion:
This edit got a little invasive, largely around the "ordering" requirements. As was already pointed out the epoch numbering provides ordering to first order. What is really needed is for the DS to select a single Commit per epoch.
Thanks for the PR! Left a few comments, but otherwise looks good!
Change:
5. <del> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  There are multiple other possible models.  This section includes some reference models.  This is not intended to be a restrictive list, and other variations may exist. </del> <ins> dataflow shows a data-flow diagram for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  This section refines it by describing two reference models, as well as one example composition thereof.  The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns. </ins> 5.1.

Discussion:
The three sentences "There are multiple [...]", "This section includes [...]" and "This is not intended [...]" are slightly vague. It doesn't seem to me that their information content is enough to justify them being independent sentences. They should probably be combined.
OLD: NEW:
(slight refinement) "Figure 1 shows an abstract model for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier. This section refines it by describing two reference interaction schemes (topological models), as well as one possible compositions thereof. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."
Reads good to me. Any other comments? (starting a virtual going once...)
Change:
This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or <del> transport layer segmentation at the sender. </del> <ins> transport layer segmentation at the sender.  This property exposes the Maximum Packet Size (MPS) as described in Datagram PLPMTUD I- D.ietf-tsvwg-datagram-plpmtud. </ins> 11.1.8.

Discussion:
Add a reference to MPS in DPLPMTUD for the Message Size Before Fragmentation property.
LGMT, just replace "models" with something more suitable.
Change:
6.4. <del> The use of prefixes, wildcards, bimasks, and port ranges allows a </del> <ins> The use of prefixes, wildcards, bitmasks, and port ranges allows a </ins> DetNet node to aggregate DetNet flows.  This aggregation can take place within a single node, when that node maintains state about both the aggregated and component flows.  It can also take place between

Discussion:
New section 5, and capitalized headings.
Lou, Yes, I'll make that change. Cheers, Andy
And done.
Thanks.... Lou PS you might want to turn off line wrap in your editor...
Lou, I just checked the settings and I don't believe it's doing any hard wrapping. What are you seeing? Cheers, Andy
right - it's best to use hard wrapping for maximum editor independence as well as github reviews. Lou
Balázs, This is similar to the text in the MPLS document, but that document references SR-MPLS. In the IP case, I figured that SR-MPLS was off the table, so I changed the reference to SRv6. The earlier part of the sentence already references control plane signaling, centralized management, and hybrid solutions. In addition to those, I wanted to include the fact that SRv6 is also a valid solution here. If there's anything else that you would like to include, we can certainly add that. Cheers, Andy
Change:
handshake, which has a basic packet loss retransmission timer. This can allow loss recovery to occur more quickly for QUIC data. <del> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was successfully received. </del> <ins> QUIC datagrams are subject to QUIC congestion control.  Providing a single congestion control for both reliable and unreliable data can be more effective and efficient. </ins> <del> QUIC datagrams are subject to QUIC congestion control, allowing applications to avoid implementing their own. These reductions in connection latency, and application insight into the delivery of datagrams, can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </del> <ins> These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </ins> Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN).

Discussion:
Drop the text on acknowledgments. Then modify the congestion control thing to make the benefit clearer. A unified congestion controller can be more efficient.
-- URL This is not an application-layer signal. While the peer might have received the packet and processed it at the QUIC layer, this does not guarantee that the DATAGRAM frame contents were processed by the application. The draft already acknowledges this in . However, the treatment in the motivation could be misleading. Consider dropping this item.
-- URL Isn't it the case that they are acknowledged? (This one is just a nit, the next issue will be more serious.)
Change:
Version Negotiation packet.  This packet SHALL include each entry from the server's set of Offered Versions (see server-fleet) in a Supported Version field.  The server MAY add reserved versions (as <del> defined in the Versions section of QUIC) in Supported Version fields. </del> <ins> defined in Section 6.3 of QUIC) in Supported Version fields. Clients will ignore a Version Negotiation packet if it contains the original version attempted by the client.  The client also ignores a Version Negotiation that contains incorrect connection ID fields; see Section 6 of RFC8999. </ins> Upon receiving the VN packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one,

Discussion:
In light of discussion in slack, the problem here is that the validation is based on the negotiated version. Validation needs to be based on the client's selected version. I've also moved text about validating lack of support for the original version to the incompatible VN section, alongside a reminder to validate connection IDs. Security does depend on this, but the client ignores these bad VN packets. That provides more effective defense against attack than what was here originally.
Thanks! Approved modulo two nits
Change:
for the specified KEM from a symmetric secret, using the specified hash function. <del> Each node in a ratchet tree contains up to three values: </del> <ins> Each node in a ratchet tree contains up to four values: </ins> A private key (only within direct path, see below)

Discussion:
Blanking on add (I think) was obsoleted by unmerged leaves Add leaf to unmerged list for non-blank nodes on add There are now four elements in each node
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :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 .
Nice catch, Thank you !
Change:
Security considerations: See seccons of RFC-AAAA. <del> Interoperability considerations: Applications MUST ignore any key value pairs that they do not understand unless the key ends with the '_' character in which case an error MUST be generated.  This allows backwards compatible extensions to this specification. </del> <ins> Interoperability considerations: N/A </ins> Published specification: RFC-AAAA

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
potential for brute-force attack.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in <del> such as way that MD5 and SHA1 MUST NOT be used for digital </del> <ins> such as way that MD5 and SHA-1 MUST NOT be used for digital </ins> signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.

Discussion:
SHA-1 is spelled everywhere as "SHA-1", it's the only instance of "SHA1" change it so that it is consistent
Change:
D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both MUST use the same security protocols and options. </del> <ins> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

Discussion:
Following , Section 4.2.3 of the Architecture document now says that fallback between different security protocol versions might be allowed. The Security Considerations section was out of sync. This PR fixes that.
Change:
The "HpkeKeyConfig" structure contains the following fields: <del> An opaque identifier for the given HPKE key configuration.  This </del> <ins> A one-byte identifier for the given HPKE key configuration.  This </ins> is used by clients to indicate the key used for ClientHello encryption.

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.
Change:
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC <del> for record protection.  This document updates RFC 5246 and RFC 7525. </del> <ins> for record protection.  This document updates RFC 5246. </ins> 1.

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:
rejects a report for this reason, it SHOULD abort the upload protocol and alert the client with error "reportTooEarly". <del> If the Report contains an unrecognized extension, then the Leader MAY abort the upload request with error "unrecognizedMessage".  Note that this behavior is not mandatory because it requires the Leader to decrypt its input share. </del> <ins> If the Report contains an unrecognized extension, or of two extensions have the same ExtensionType, then the Leader MAY abort the upload request with error "unrecognizedMessage".  Note that this behavior is not mandatory because it requires the Leader to decrypt its input share. </ins> 4.3.3.

Discussion:
Based on (merge that first).
As noted by NAME in URL, we need to decide how to handle duplicate extensions. One simple idea is to treat duplicate extensions as decoding failures, i.e., abort with "unrecognizedMessage".