jiebi/CodeConvo huggingface dataset:
Change:
1. <del> HTTP extensions sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </del> <ins> HTTP extensions (as defined in HTTP) sometimes need to access underlying transport protocol features such as unreliable delivery (as offered by DGRAM) to enable desirable features.  For example, this could allow introducing an unreliable version of the CONNECT method, or adding unreliable delivery to WebSockets RFC6455. </ins> In datagrams, this document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange

Discussion:
Issue created in reponse to considerations section seems straightforward. extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC? The term HTTP extensions is defined in . Since we already have a normative reference to that document, I propose to resolve this issue by adding a reference to that section in our introduction.
Lgtm Reviewer: David Mandelberg Review result: Ready I did not notice any security issues with this document, and the security considerations section seems straightforward. (nit / question / feel free to ignore) I was a bit confused by the term "HTTP extensions" at first, but from context, I'm guessing it's used loosely to mean any addition to HTTP? I found RFC 2774 when I was looking to see if it meant something specific, but I'm guessing it's not a reference to a 20+ year old experimental RFC?
Change:
they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. <del> 5.3. </del> <ins> 6.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, <del> such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del> <ins> such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

Discussion:
I'll add references for QUIC, TLS, IPsec, WireGuard, and TOR. Update: Created
Comment by NAME It is a bit odd to mention a non-IETF VPN protool, but not the IETF VPN protocol. Especially since IPsec also has constant byte stream support via IPTFS that WireGuard does not have :P
This is just a list of examples, it doesn't need to cover everything in the universe. And IETF docs are allowed to mention non-IETF things.
Change:
1-RTT handshake keys until it finds one that decrypts properly, and then pick up the handshake from that point. <ins> Servers MUST comply with the same error handling requirements specified for all records when processing early data records and MUST NOT fall back to 1-RTT on any such errors.  Specifically, decryption failure of any 0-RTT record following an accepted "early_data" extension MUST produce a fatal "bad_record_mac" alert as per record- payload-protection. </ins> [[TODO: How does the client behave if the indication is rejected.]] [[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the

Discussion:
Proposed clarification based on mailing list discussion. Explicitly state that 0-RTT records MUST NOT get special treatment and 1-RTT fallback on decryption errors is prohibited. This may technically already be the intended situation, however any ambiguity here will undoubtedly lead to some implementations falling back to avoid breakage in this scenario, which risks 0-RTT data stripping attacks. As I agree with the expected behavior stated by NAME on-list, this is just a matter of adding some clarification here (even if it might be redundant; someone interpreting the text the way I initially did could do something dangerous if they don't also notice the risk).
Change:
provided in the handshake.  That is the CertificateVerify message in TLS 1.3 or ServerKeyExchange in 1.2. <del> Verify that the certificate has the correct extensions that allow the use of Delegated credentials. </del> <ins> Verify that the certificate has the DelegationUsage extension, which permits the use of Delegated credentials. </ins> <del> Clients that receive Delegated credentials that are valid for more than 7 days MUST terminate the connection with an "illegal_parameter" alert. </del> <ins> If one or more of these criteria are not met, then the Delegated credential is invalid.  Clients that receive Delegated credentials that are invalid MUST terminate the connection with an "illegal_parameter" alert. </ins> 4.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; <del> the removal of names could happen when the execution context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </del> <ins> the removal of names could happen when the browsing context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </ins> A malicious Web application could flood the local network with mDNS messages by: <del> creating execution contexts that create ICE agents and start </del> <ins> creating browsing contexts that create ICE agents and start </ins> gathering of local ICE host candidates; destroying these local candidates soon after the name registration

Discussion:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.
Change:
8.1. <del> This specification registers a Well-Known URI RFC5785: URI Suffix: dns-query Change Controller: IETF Specification Document(s): [this specification] 8.2. </del> 9. Running DNS over HTTPS relies on the security of the underlying HTTP

Discussion:
and
The draft says: But it probably needs to describe at least one way to perform that automated discovery. It's probably not a good idea to have people attempt to guess.
fwiw the .wk is used here so that that when a request/response pair is pushed the client understands this to be DoH. Its probably also helpful to have a well-known path here for the normal so that defaults of https://, 443, and the default path can be used in configuration systems that might only be capable of a hostname. (e.g. my DoH server is at URL).. I'll work on text.
I think I can future proof for the context I want using a response header instead of a well known.. imo that's kind of ignoring the point of the path - but whatever. Maybe I'll propose x-well-known :)
Change:
The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function <del> to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in".  The hash function for HKDF when deriving initial secrets and keys is SHA-256 SHA. </del> <ins> from TLS TLS13 to produce a 32-byte secret.  Packets constructed by the server use the same process with the label "server in".  The hash function for HKDF when deriving initial secrets and keys is SHA-256 SHA. </ins> This process in pseudocode is:

Discussion:
This was, I think clear, but the use of HKDF-Expand-Label and the encoding of labels into octets could be even more explicit.
Section 5.2: The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA]. Looking at RFC 5689 the HKDF-Expand function defines what is referenced as label as "info" input. It is a string. It is unclear that this is an ASCII string, but based on what is written it looks like something where each character is an octet is assumed, thus no UTF-16 or UTF-32 strings would work as intended. If I am correct I think the draft can be improved by being explicit like in TLS that the label used as input into the functions as ASCII. So adding something like this sentence from RFC8446 is likely appropriate: The labels specified in this document are all ASCII strings and do not include a trailing NUL byte.
Actually I think I understand what the issue is: Lets look at these three paragraphs in Section 5.2: This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a IKM of the Destination Connection ID field. This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving. The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA]. The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3.

I got the impression that the HKDF-Expand function was the one from RFC5689 and not the one from TLS1.3. So I think what is needed to clarify this is that the second paragraph needs to explicitly provide the HKDF-Expand-label function with section and document reference. I still think it should be made clear that the labels are ASCII, but that is clear in TLS 1.3 compared to RFC5689.
Based on , labeling this as "editorial"
Changes looks good, resolve the issue.
nits
Change:
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets <ins> transports.  It also formally updates RFC7641 for use with these </ins> transports. 1.

Discussion:
The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.
URL Appendix A. Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) This needs to be referenced from the main body in some form.
Change:
other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties <del> except "Connection Priority", see conn-priority.  Like all other </del> <ins> except "Connection Priority" (see conn-priority) .  Like all other </ins> Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. <ins> The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific Connection returns a set of all Connections in the same group.

Discussion:
How do framers behave in connection groups? I.e. do all connections share one framer object or does the framer object get duplicated when a connection gets cloned? If it does get duplicated, does it keep its current state? This might mostly be an implementation detail but I think it should be mentioned in section 6.4 of API.
Interim: same type of framer is plausible default (but new instances), but in general a framer should be per connection. State is not shared across connections. Bigger problem: framers are added to preconnections, not connections, so how is this done with cloning? (perhaps: add list of framers as parameter added to the clone call)
I've thought about it, and Idon't think we actually have a bigger problem here: On an initiated Connection/ConnectionGroup, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Initiate(). On a Listener, the provenance of the Framers is Preconnection.AddFramer() -> Preconnection.Listen() -> Listener.Clone(). In a Rendezvous situation, there is (unless I'm missing something) always a Preconnection from which a Framer can ultimately be inherited.
In §8.1.2 ¶3, the doc says: but this doesn't seem to be conceptually compatible with the text at the top of §8.1.2.1, which says: I think the way most developers would think about this is as a pipeline: you feed data into the top-level framer with Send, which then percolates downward through the pipeline to the bottom-level framer, which then sends it to the transport.
I think this should be easy to address, by rephrasing: as: ... BUT "call each other" is surely a terrible way to put this, and there must be a way to say this cleanly and neatly, in line with how the code really goes. THIS, I suspect, is a very simple thing for NAME to do, and hence I assigned it to him.
Change:
model can be used to transmit collections of resources, such as batches of sensor data or configuration parameters. <del> Example of a SenML collection is shown below: </del> <ins> An example of a SenML collection is shown below: </ins> Here three resources "3306/0/5850", "3306/0/5851", and "3306/0/5750", of an IPSO dimmable light smart object IPSO are represented using a

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
Section 5, and the set of fingerprint and algorithm values is stored. <del> If the "m=" proto value indicates use of RTP, as described in the sec.profile-names section above, the following attribute lines MUST be processed: </del> <ins> If the "m=" proto value indicates use of RTP, as described in sec.profile-names above, the following attribute lines MUST be processed: </ins> The "m=" fmt value MUST be parsed as specified in RFC4566, Section 5.14, and the individual values stored.

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
6.2. <del> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application protocols, such as DNS, which is often used to send a single-packet request to look up the IP address for a domain name, and return a single-packet response containing the IP address.  Although it is possible to saturate a path between a DNS client and DNS server with DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application protocols that share the same pathways). In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since UDP does not provide any feedback mechanism to senders to help limit impacts on other users, application-level protocols such as RTP RFC3550 have been responsible for the decisions that TCP-based </del> <ins> Because UDP does not provide any feedback mechanism to senders to help limit impacts on other users, UDP-based application-level protocols have been responsible for the decisions that TCP-based </ins> applications have delegated to TCP - what to send, how much to send, and when to send it.  Because UDP itself has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own <del> feedback mechanisms and respond to the feedback the application </del> <ins> feedback mechanisms, and to respond to the feedback the application </ins> receives.  This expectation is most recently codified in Best Current Practice RFC8085.

Discussion:
Also adding Tommy's name in Acks section.
LGTM, too and ready to merge.
From NAME In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is often used to send a single-packet request to look up the IP address for a DNS name, and return a single-packet response containing the IP address." I'm not sure how valuable this example is for explaining UDP, but if it is kept, please say that multiple packets are sent to get multiple addresses. With IPv6 and IPv4, clients query for both A and AAAA records, and handle multiple addresses, especially for IPv6.
FWIW, I understand why you're saying this. My point (and I wrote this) was to explain why it we've used DNS over UDP for decades without worrying about congestive collapse, but we've used other protocols over TCP because we were worried. I can certainly explain that more correctly, as you propose. And thanks for pushing back.
Hi, NAME especially after NAME suggesting in his TSVART review that I don't need to talk about history, removing this text completely was a perfectly reasonable resolution for your issue!
Sounds good
LGTM
Change:
strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider the following guidelines: </del> <ins> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider the following guidelines: </ins> There needs to be a real and compelling use for any new unit to be added.

Discussion:
Is there a reason we keep it for label registrations?
NAME Good point; same considerations apply to both. Will fix.
From Peter's review: or IESG Approval as defined in [RFC5226]. confusion.
It means that if something needs to happen and AD can make it happen without firing the expert which creates so much bad will that an AD would much rather wit 6 months for the expert to respond. All it says if the AD can do this or the expert can. I don't care much.
NAME Our AD had preference to have just Expert review in order for people to not think there are two paths but show clear preference. If things are slow, the IESG is next on the appeal path, so ADs can do it anyway.
Addressed by PR
Note that even with we still have the dual policy on the labels. Bug or feature?
On the "Our AD had preference to have just Expert review " ... I'm fine with this.
NAME The dual policy was fixed with the latest commit. Although perhaps we want to have more guidelines for the expert to follow?
Change:
because the ACME protocol itself includes anti-replay protections (see replay-protection). <del> ACME clients SHOULD send a User-Agent header in accordance with RFC7231, including the name and version of the ACME software in addition to the name and version of the underlying HTTP client software. </del> <ins> ACME clients MUST send a User-Agent header, in accordance with RFC7231.  This header SHOULD include the name and version of the ACME software in addition to the name and version of the underlying HTTP client software. </ins> ACME clients SHOULD send an Accept-Language header in accordance with RFC7231 to enable localization of error messages.

Discussion:
Thanks for the comments NAME I've updated the PR to address.
There has been list discussion on this PR and consensus is positive. I'm going to merge this now that NAME has addressed the feedback provided.
LGTM :rocket:
Change:
transmitted as specified by the current active session state. %%% Handshake Protocol enum { hello_request_RESERVED(0), <del> client_hello(1), server_hello(2), session_ticket(4), </del> <ins> client_hello(1), server_hello(2), new_session_ticket(4), </ins> hello_retry_request(6), encrypted_extensions(8), certificate(11), server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15),

Discussion:
This is purely aesthetic, but apparently no one realizes the name is different, not even IANA, so we may as well go fix it. (I don't know how to write IANA considerations, so I've left it a TODO. But if you give me text, I'll update this PR to include it.) For consistency. At a glance, it seems most TLS implementations did not realize the HandshakeType value was actually named sessionticket and assumed it was named newsession_ticket anyway. Moreover, the IANA entry was named neither and actually named NewSessionTicket since RFC 4507's IANA considerations used the wrong name.
Change:
transmitted separately, thus avoiding IP fragmentation. When transmitting the handshake message, the sender divides the <del> message into a series of N contiguous data ranges.  These ranges MUST NOT be larger than the maximum handshake fragment size and MUST jointly contain the entire handshake message.  The ranges MUST NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes </del> <ins> message into a series of N contiguous data ranges.  The ranges MUST NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes </ins> contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. <ins> Each range MUST be delivered in a single packet. </ins> When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.