jiebi/CodeConvo huggingface dataset:
Change:
5. <del> This section describes several components that are used by ACME, and general rules that apply to ACME transactions. </del> <ins> ACME uses a combination of HTTPS and JWS to create a messaging layer with a few important security properties. Communications between an ACME client and an ACME server are done over HTTPS, using JWS to provide som additional security properties for messages sent from the client to the server.  HTTPS provides server authentication and confidentiality.  With some ACME-specific extensions, JWS provides authentication of the client's request payloads, anti-replay protection, and a degree of integrity for the HTTPS request URI. </ins> 5.1. Each ACME function is accomplished by the client sending a sequence <del> of HTTPS requests to the server, carrying JSON messages.  Use of HTTPS is REQUIRED.  Clients SHOULD support HTTP public key pinning </del> <ins> of HTTPS requests to the server, carrying JSON messages RFC7159.  Use of HTTPS is REQUIRED.  Clients SHOULD support HTTP public key pinning </ins> RFC7469, and servers SHOULD emit pinning headers.  Each subsection of certificate-management below describes the message formats used by the function, and the order in which messages are sent.

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:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> 3. </del> <ins> 4. </ins> This document specifies two means of performing version negotiation: one "incompatible" which requires a round trip and is applicable to

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the delivery of messages and avoids Personally Identifiable Information <del> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </del> <ins> (PII) or other sensitive metadata wherever possible.  A Service Provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS. </ins> [[OPEN ISSUE: These privacy statements seem very strong.  BB.  I would be willing to keep them as requirements since we have example

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
provide backpressure to the transport stack when it is temporarily not ready to receive messages. <ins> The interface should allow the application to correlate which call to Receive resulted in a particular Receive Event.  The manner in which this correlation is indicated is implementation-specific. </ins> 8.2.1. A Received event indicates the delivery of a complete Message.  It

Discussion:
Apple does this: URL URL it may be more convenient than what we currently have (or do we have it unspecified? My interpretation of our text would have been to use only one receive handler associated to the Connection). E.g., if an application expects 3 different types of messages to be received in sequence, it can hand over three different receive handlers in Apple's case, and that seems useful. Apple also has a "completion" handler per sent event, handed over as a parameter to "send". Is this necessary? Who needs 3 different "Sent" handlers for 3 different messages - shouldn't the "sent" handler rather be a singular per-Connection thing?
I think this gets into an implementation-specific area. If the language has an easy way to provide a unique completion/closure for a given invocation of Receive(), then I think it is preferable to do this to having a single function. If anything, it may be nice to make a not for Received() and Sent() that they should, if supported by the language, provide this kind of linking between calls and events.
I agree, and I assign this to Tommy since he offered (in an email) to write text. Thanks a lot!
Change:
might propose to remove a member of a group has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team.  Proposals originating outside the <del> group are identified by an "preconfigured" or "new_member" SenderType </del> <ins> group are identified by a "preconfigured" or "new_member" SenderType </ins> in MLSPlaintext. The "new_member" SenderType is used for clients proposing that they

Discussion:
by special-casing external senders. Removing the GroupContext would allow me to take messages that user A sent in one instance of a group, and make it look like they're speaking in another group by re-encrypting the ciphertext.
Right now, the signature on an MLSPlaintext includes the GroupContext for the group. If we are going to allow Add proposals signed by the new member, then this will need to change, because the new member doesn't know the GroupContext. My preference would be to simply remove the GroupContext from the plaintext. The Group ID is already included, so copy/paste protection can be added that way. The other elements of the GroupContext effectively overlap with the Epoch that is already signed.
Haven't thought about this too deeply, but having the full GroupContext in MLSPlaintextTBS means that we know all the members agree on the state of the ratchet tree, the transcript, the extensions. Removing it means we would no longer have agreement on those, right?
We won't have confirmation of agreement as a result of signature verification. The question is whether that is necessary. If the MLSPlaintext was decrypted from an MLSCiphertext, for example, then the successful decryption of the MLSCiphertext implies agreement on all those things. I suppose you could also switch the signature input based on SenderType, but that seems messier.
I'm not so sure that decrypting an MLSCiphertext implies agreement, because the crypto is symmetric. A man-in-the-middle can re-encrypt but not re-sign.
Change:
14 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document makes use of the terms defined in RFC8499.  The term "Global DNS" is defined in RFC8499. 'Encrypted DNS' refers to a DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DoT, DoH, or DoQ). The term 'Validated Split-Horizon' is also defined. 2.1. A split horizon configuration for some name is considered "validated" if the network client has confirmed that a parent of that name has authorized the local network to serve its own responses for that name.  Such authorization generally extends to the entire subtree of names below the authorization point. </del> <ins> This document makes use of the terms defined in RFC8499, e.g. "Global DNS".  The following additional terms are used throughout the document: </ins> 3.

Discussion:
From Paul Wouters: From Michael Richardson:
Do you think this is a client configuration that we should reasonably expect? It seems to me that that behavior would be quite strange, although it is permissible. I think it's probably clearer for our examples to represent common configurations.
NAME Can we discuss it separately? This PR is for changes in response to feedback in the ADD adoption thread. Do you approve of this PR for that purpose? Perhaps you can open a new PR if you would like to add more example text.
Yes, changes look good to me. Works for me. I proposed this text to address the comment from the WG on whether client implementations will enable DNSSEC to support the proposed mechanism.
Change:
MAY use the Capsule-Protocol header field to simplify intermediary processing. <del> "Capsule-Protocol" is an Item Structured Header (see Section 3.3 of STRUCTURED-FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </del> <ins> "Capsule-Protocol" is an Item Structured Header (see STRUCTURED- FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </ins> Endpoints indicate that the Capsule Protocol is in use on the data stream by sending the Capsule-Protocol header field with a value of

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. <del> The decrypted plaintext contains the server id and opaque server data in that order.  The load balancer uses the server ID octets for routing. </del> <ins> The first octets of the plaintext contains the server id. </ins> 5.3.3. <del> The server encrypts both its server ID and a nonce in 16-octet block with the configured AES-ECB key. </del> <ins> The server encrypts both its server ID and enough octets in a nonce to form a 16-octet block using the configured AES-ECB key.  Note that any remaining octets in the nonce are transmitted as plaintext, and should consider the constraints in cid-entropy. </ins> 6.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible. <del> The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </del> <ins> The client initiates a QUIC connection by choosing an original version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </ins> version downgrade attacks (see downgrade). Upon receiving this first flight, the server verifies whether it

Discussion:
Instead of creating separate issues for each minor editorial comments I will put them all in this issue - I am not a fan of having normative language in the definitions. I feel those normative languages are out of context and hard to reason. It is the case for MSL definition. I would suggest that besides definition, we have some description where MSL is used and put the recommended value there. What is the difference between the initial version and original version ? if there is none why do we need to use two different call sign for the same thing? What is Tubes? we need to explain it. otherwise use other example.
I personally disagree. Mentioning the recommended value when defining the term makes it easier to understand and implement. Agreed, there was only one mention of "initial version" so I replaced that with original in It's a hypothetical example. That doesn't make it unhelpful.
:-) hmm, the example makes little sense if one does not understand the terms used in the example. If "Tube" is a hypothetical term here, then let's just mention that.
There was no reasoning, this was pulled out of a hat just like the original MSL from RFC 793. Can you send us a PR describing the reasoning you'd like to see added? Fair enough, I've added the word "hypothetical" to PR
Change:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label in </del> <ins> inclusive.  In a fully-qualified domain name, the last label in </ins> the ordered list is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total

Discussion:
There are still inconsistencies remaining. : it can be fully qualified (in which case, it begins at the common root of the graph) : partially qualified domain names, which are names where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "URL") Suggestions: Explicitly specify ordering in "Domain name": _ → Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s). A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node. Note that the generality of "domain name" requires careful language here to accommodate arbitrary edge direction (parent→child vs. child→parent) and graph topology (e.g., non-tree DAGs can have multiple roots and/or multiply-referenced nodes). Update "Fully qualified domain name" accordingly: partially qualified domain names, which are names where one or more of the last labels in the ordered list are omitted (for example, a name of "www" relative to "URL" identifies "URL")_.
Change:
7.8. MLS hashes the contents of the tree in two ways to authenticate <del> different properties of the tree.  This section defines _tree hashes_, and _parent hashes_ are defined in parent-hashes. </del> <ins> different properties of the tree.  _Tree hashes_ are defined in this section, and _parent hashes_ are defined in parent-hashes. </ins> Each node in a ratchet tree has a tree hash that summarizes the subtree below that node.  The tree hash of the root is used in the

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.
Change:
4.1.2. A resource directory can advertise its presence in DNS-SD using the <del> service name "_core-rd._udp" defined in this document. </del> <ins> service name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for CoAP over UDP), "_core-rd._tcp" (for CoAP over TCP) or "_core-rd- tls._tcp" (for CoAP over TLS)` defined in this document.  (For the WebSocket transports of CoAP, no service is defined as DNS-SD is typically unavailable in environments where CoAP over WebSockets). </ins> <del> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </del> <ins> The selection of the service indicates the protocol used, and the SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd.

Discussion:
Those were in the original proposals during IETF / on the list, but not in the text yet. Depends on for practical merging purposes.
Change:
applicable registries in TLS. The following values are reserved as GREASE values for cipher suites <del> and ALPN identifiers: </del> <ins> and ALPN RFC7301 identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}

Discussion:
The date is wrong and ALPN is missing a citation: Error: Cannot handle a with year different than this year, and no month. Using today's date. Warning: no in targets
(Editorial, I hope. Going ahead and merging this for -02.)
Change:
is intended for immediate termination of a connection, without cleaning up state. <ins> 4.1.7. A Connection Group is a set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </ins> 4.2. This section defines the set of objects used internally to a system

Discussion:
This is fully editorial: I'm not sure if the term "Connection Group" is introduced in the right section. There might be no perfect fit but maybe section 2.2 is a bit better? Also I note that the terms "Connection Group" and "Path" do not not show up in any of the figures...
Make this a new subsection, i.e. 4.1.7.
Works - Thank you!
Change:
Services and features provided by transport protocols have been cataloged in RFC8095.  This document supplements that work by surveying commonly used and notable network security protocols, and <del> identifying the services and features a Transport Services system (a system that provides a transport API) needs to provide in order to add transport security.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each protocol, this document provides a brief description, the dependencies it has on the underlying transports, and the interfaces provided to applications. </del> <ins> identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </ins> Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and externally (via an API) for applications I-D.ietf-taps-arch. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard <del> protocols such as Google QUIC, are both included despite overlapping </del> <ins> protocols such as gQUIC, are both included despite overlapping </ins> features.  As such, this survey is not limited to protocols developed within the scope or context of the IETF.  Outside of this candidate set, protocols that do not offer new features are omitted.  For

Discussion:
This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!