jiebi/CodeConvo huggingface dataset:
Change:
The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the <del> current state using the Add message: </del> <ins> current state using the Add message.  This information is encrypted for the new member using ECIES.  The recipient key pair for the ECIES encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite. </ins> Note that the "init_secret" in the Welcome message is the "init_secret" at the output of the key schedule diagram in key-

Discussion:
This PR addresses two outstanding issues with Welcome messages: Welcome messages were not encrypted for the new member, so that the information in them (in particular, init secrets) were not appropriately protected. The protocol overview had not been updated to include the Welcome-based add flow.
This was resolved in , but recording it in this issue for posterity. A Welcome message carries the value for the group, and so it needs to be encrypted for the new joiner. The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext, and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message.
Change:
for performing connection racing.  The Transport Services Architecture implementation from TAPS also describes how connections can race across interfaces and address families.  In <del> cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket invalidation by racing. </del> <ins> such cases, clients may use more than one ticket while racing connection attempts in order to establish one successful connection.  Having multiple tickets equips clients with enough tickets to initiate connection racing while avoiding ticket re-use and ensuring that their cache of tickets does not empty during such races.  Moreover, as some servers may implement single-use tickets, distinct tickets prevent premature ticket invalidation by racing. </ins> Connection priming: In some systems, connections can be primed or bootstrapped by a centralized service or daemon for faster

Discussion:
This is without ticket re-use text. This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths. Did I get this right? Does this make sense? Should we put this in the document directly?
NAME NAME do you think we should include the table in the PR's description in the text? I think its contents are implied from the text, so adding more text is just being verbose. But I could be persuaded otherwise.
I think that it might be confusing. For instance, I see no reason that a client wouldn't have a fixed configuration. A client that never races resumptions could send N and 1 always.
Can you please provide text?
NAME I can't really provide text as I'm unclear on what the field is trying to even describe.
Change:
<del> Transport Layer Security (TLS) Certificate Compression </del> <ins> TLS Certificate Compression </ins> draft-ietf-tls-certificate-compression-latest Abstract <del> In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. </del> <ins> In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. </ins> This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.

Discussion:
Now that TLS and DTLS are in the RFC editor's list of abbreviations as "common" there's no need to spell out Transport Layer Security anymore.
Change:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on <del> an octet boundary </del> <ins> an byte boundary </ins> Indicates that x has a fixed value of C

Discussion:
Maybe leftovers from , or newly added text.
I'm sure the document was touched by his noodly appendage of the Octocat :octocat:
How did those slip through!?Yes, I think these are mostly new / imported from other docs.Thanks, NAME !
Change:
If a max_idle_timeout is specified by either peer in its transport parameters (transport-parameter-definitions), the connection is silently closed and its state is discarded when it remains idle for <del> longer than the minimum of both peers max_idle_timeout values and three times the current Probe Timeout (PTO). </del> <ins> longer than the minimum of both peers max_idle_timeout values. </ins> Each endpoint advertises a max_idle_timeout, but the effective value at an endpoint is computed as the minimum of the two advertised

Discussion:
The text as written implied that the actual timeout period was calculated using: This is silly, as 3PTO is usually smaller than the other two values, and connections would time out too fast. Splitting the text regarding the 3PTO backstop makes this clearer.
Wasn't the intended meaning
I can only speak about my intent, but I did not intend to always add 3PTO to the timeout. The text was clearly more confused than I thought.
I actually wasn't sure what you meant before, but this is what I assumed.
Change:
becoming idle.  Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in response to other events. <ins> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgments are included in packets with ack-eliciting frames.  An endpoint SHOULD send an ACK frame with other frames when there are new ack-eliciting packets to acknowledge.  When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY choose not to send an ACK frame with outgoing frames until an ack-eliciting packet has been received. An endpoint that is only sending non-ack-eliciting packets might choose to occasionally add an ack-eliciting frame to those packets to ensure that it receives an acknowledgment; see ack-tracking.  In that case, an endpoint MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments. </ins> In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack- eliciting packet either:

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
networking practices and observations of media delivery issues encountered when streaming media over those existing networks. <del> This document defines "high-bitrate streaming media" as follows: </del> <ins> 1.1. This document defines "high-bitrate streaming media over the Internet" as follows: </ins> "High-bitrate" is a context-sensitive term broadly intended to capture rates that can be sustained over some but not all of the

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
WebRTC browsers MUST implement I-D.ietf-rtcweb-jsep. WebRTC endpoints MUST implement the functions described in that <del> document that relate to the network layer (for example Bundle I- D.ietf-mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I-D.ietf-ice-trickle), but do not need to support the API functionality described there. </del> <ins> document that relate to the network layer (e.g.  Bundle I-D.ietf- mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I- D.ietf-ice-trickle), but do not need to support the API functionality described there. </ins> 8.

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
5.2. <del> As is the ordinary case for HTTP caching (HTTP-CACHING), a response with RateLimit fields might be cached and re-used for subsequent requests.  A cached response containing RateLimit fields does not modify quota counters but could contain stale information.  Clients interested in determining the freshness of the RateLimit fields could rely on fields such as the Date header field and on the time window of a quota policy. </del> <ins> HTTP-CACHING defines how responses can be stored and reused for subsequent requests, including those with RateLimit fields.  Because the information in RateLimit fields on a cached response may not be current, they SHOULD be ignored on responses that come from cache (i.e., those with a positive current_age; see Section 4.2.3 of HTTP- CACHING). </ins> 6.

Discussion:
It would be better to say that rate limiting information in what we used to call non-firsthand responses (basically, anything with an Age header) should be ignored.
Is the following text ok?
Looks good, just a few suggested tweaks:
Change:
introduced in version -03 and a breaking change made in version -05, then there would be a challenge labeled "http-03" and one labeled "http-05" - but not one labeled "http-04", since challenge in version <del> -04 was compatible with one in version -04. ]] </del> <ins> -04 was compatible with one in version -03. ]] </ins> 7.1.

Discussion:
Note is still required.
In this case it seems better to address the removal of the editor's note than to optimize its contents - do we know if this note is still required?
Change:
6.1. <ins> Because do not authenticate the when using Oblivious HTTP, MUST maintain an explicit allowlist of target resources that the trusts an Oblivious Gateway to respond for, and check requests against this allowlist before sending them.  This ensures that are not abused to forward traffic to arbitrary Target Resources.  See server- responsibilities for similar responsibilities that apply to . </ins> MUST ensure that the they select for generating Encapsulated Requests is integrity protected and authenticated so that it can be attributed to the ; see key-configuration.

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
generates a random PSK identity with the same length.  It also generates a random, 32-bit, unsigned integer to use as the "obfuscated_ticket_age".  Likewise, for each inner PSK binder, the <del> client generates random string of the same length. </del> <ins> client generates a random string of the same length. </ins> <del> If the server replies with a "pre_shared_key" extension in its </del> <ins> Per the rules of real-ech, the server is not permitted to resume a connection in the outer handshake.  If ECH is rejected and the client-facing server replies with a "pre_shared_key" extension in its </ins> ServerHello, then the client MUST abort the handshake with an "illegal_parameter" alert.

Discussion:
Just some minor nits I picked up during a slow pass of the spec.
LGTM pending one nit.
Change:
provision and resource management discussed in I-D.ietf-opsawg-l2nm. Through this data model, the service orchestration layer can learn the available endpoints (i.e., SAPs) of interconnection resource of <del> the underlying network. The service orchestration layer can determine which endpoint of interconnection to add to L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements could determine the feasibility of an end-to-end IP connectivity or L2VPN connectivity and therefore derive the sequence of domains and the points of interconnection to use. </del> <ins> the underlying network.  The service orchestration layer can determine which interconnection endpoints to add to an L2VPN or L3VPN service.  With the help of other data models (e.g., L3SM RFC8299 or L2SM RFC8466), hierarchical control elements can also assess the feasibility of an end-to-end IP connectivity or L2VPN connectivity and, therefore, derive the sequence of domains and the points of interconnection to use. </ins> This document explains the scope and purpose of a SAP network model <del> and its relation with the service models and describes how it can be used by a network operator.  The document also shows how the topology and service models fit together. </del> <ins> and its relation with the service models. </ins> The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) RFC8342.

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
observers cannot reliably use it as an identifier for QUIC. latency spin bit: The third-most-significant bit of the first <del> octet in the short packet header for version 1.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further </del> <ins> octet in the short header for version 1.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further </ins> details. header type: The long header has a 2 bit packet type field

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
8.6.1. <ins> This registry lists field names that are defined for use in ACME account objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. 8.6.2. This registry lists field names that are defined for use in ACME order objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in order- objects. 8.6.3. </ins> This registry lists values that are used within URN values that are provided in the "type" field of problem documents in ACME.

Discussion:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..
Change:
Add the following: <del> Note: The designated expert RFC5226 only ensures that the specification is publicly available. </del> <ins> The designated expert RFC5226 only ensures that the specification is publicly available. </ins> 10.

Discussion:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.
Change:
the allowance for expansion to 256 octets.  Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations. <ins> An Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Similarly, other ciphers cannot produce authenticated data until the entire record is present.  Thus, incremental processing of records minimally exposes endpoints to the risk of forged data. </ins> The "max_fragment_length" extension RFC6066 was designed to enable constrained clients to negotiate a lower record size.  However, "max_fragment_length" suffers from several design problems (see mfl-

Discussion:
This is a good part of what motivates the existence of the mechanism.
The text changes look good to me. I only had a minor remark regarding another sentence.
Change:
13.1.8.1. The "external_senders" extension is a group context extension that <del> contains credentials of senders that are permitted to send external proposals to the group. </del> <ins> contains the credentials and signature keys of senders that are permitted to send external proposals to the group. </ins> 13.2.

Discussion:
The External Senders Extension allows clients to agree on the entities that are allowed to send external proposals, as well as the signature public keys required to verify them. It contains a list of credentials that is meant to achieve this goal. However, due to a recent change, Credentials don't necessarily contain signature public keys anymore. NAME suggested to have it contain a signature public key, as well as a corresponding Credential, which allows members to verify the binding between signature public key and the owning entity's identity, which I think would be a good solution.
Thanks NAME I like that this captures both the signature and authentication aspects. NAME wdyt?Looks good to me! NAME idea might be a good additional improvement.
Change:
7.1. <del> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). </del> <ins> Create an entry, compress_certificate(TBD), in the existing registry for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR". </ins> 7.2.

Discussion:
This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.
Change:
A client MUST validate the values received in the "RateLimit" fields before using them and check if there are significant discrepancies with the expected ones.  This includes a "RateLimit-Reset" moment too <del> far in the future or a "request-quota" too high. </del> <ins> far in the future or a "service-limit" too high. </ins> Malformed "RateLimit" fields MAY be ignored.

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <ins> Further, the possibility of an on-path attacker in an attacking network introduces some risks.  The attacker could redirect traffic to arbitrary destinations.  The attacker could analyze the user's traffic leading to loss of confidentiality.  Or, the attacker could modify the traffic inline. </ins> 7.2. The solution described here requires that when the User Equipment

Discussion:
When we trust a network, we introduce the risk of on path attacks. Mention a few of them as possibilities. A few questions for the reviewers: Should we mention that the list is not exhaustive, or is that implied? Should we mention mitigating factors? (i.e. some of the attacks I've mentioned should be prevented w/ proper use of TLS).
Roman writes, text as just one example.
Change:
In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP introduces a length field with variable size. fig-frame shows the <del> adjusted CoAP header format with a modified structure for the fixed header (first 4 bytes of the UDP CoAP header), which </del> <ins> adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which </ins> includes the length information of variable size, shown here as an 8-bit length.

Discussion:
These labels are confusing and should be rewritten more in the style of RFC6455 with "Length" and "Extended Length" for clarity.
And remember to replace the last reference to: The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers.