jiebi/CodeConvo huggingface dataset:
Change:
If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the <del> original.  The connection library creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </del> <ins> original.  This creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </ins> DNS hostname-to-address resolution is the most common method of endpoint derivation.  When trying to connect to a hostname endpoint

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...
Change:
The Adaptive DNS Discovery (ADD) Working Group is chartered to define mechanisms that allow clients to automatically discover and select encrypted DNS resolvers in a wide variety of network environments. <del> This document currently focusses on one common use case, that of discovering the encrypted DNS resolver that corresponds to the Do53 resolver offered by a network.  Additional use cases can be added in future versions.  As well as describing the use case, it lists requirements that any proposed discovery mechanisms should address. They can do this either by providing a solution, or by explicitly stating why it is not in scope. </del> <ins> This document describes one common use case, namely that of clients that connect to a network but where they cannot securely authenticate that network.  Whether the network required credentials before the client was permitted to join is irrelevant; the client still cannot be sure that it has connected to the network it was expecting. In such cases the client would like to learn which encrypted DNS resolvers are designated by that network, or by the Do53 resolver offered by that network.  It lists requirements that any proposed discovery mechanisms should seek to address.  They can do this either by providing a solution, or by explicitly stating why it is not in scope. </ins> 1.1.

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
This handling is similar to the Transit Information Option as supported in Section 6.7.8. of RFC6550. <del> 5. The MOP-extension could cause 3-byte increase in memory in the RPL- Instance.  The MOP field in the RPL-Instance needs to be upgraded to a 32 bit integer. RFC6550, it was possible to discard an unsupported DIO-MOP just by inspecting the base message.  With this document, the MOPex is a different control message option and thus the discarding of the DIO message could happen after inspecting the message options. A node in storing MOP could independently construct a DAO message with target options containing its child/sub-childs.  Thus with capabilities it needs to reconstruct the capabilities field as well. This may result in increase in the memory requirement on per routing- entry basis. 6. 6.1. IANA is requested to assign a new Mode of Operation, named "MOPex" for MOP extension under the RPL registry.  The value of 7 is to be assigned from the "Mode of Operation" space RFC6550 6.2. Two new entries are required for new supporting new options "MOPex", "Capabilities" from the "RPL Control Message Options" space RFC6550. 6.3. IANA is requested to create a registry for the extended-MOP-value (MOPex).  This registry should be located in TODO.  New MOPex values may be allocated only by an IETF review.  Currently no values are defined by this document.  Each value is tracked with the following qualities: MOPex value </del> <ins> 4. </ins> <del> Description </del> <ins> 4.1. </ins> <del> Defining RFC </del> <ins> New entry is required for supporting new Capabilities option in the "RPL Control Message Options" space RFC6550. </ins> <del> 6.4. </del> <ins> 4.2. </ins> IANA is requested to create a registry for the Capabilities flags as described in cap-why of this document.  This registry should be

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
This is a request for the entire body. This is used to confirm that the current set of MAX_PAYLOADS <del> payloads have been successfully received and that, upon receipt, the peer can continue to sent the next set of payloads.  This is the 'Continue' Q-Block-2. </del> <ins> payloads (the latest one having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next set of payloads (the first one having block number NUM).  This is the 'Continue' Q-Block-2. </ins> <del> This is a request for the remaining payloads in the current MAX_PAYLOADS set. </del> <ins> This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set. </ins> If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and later blocks) and

Discussion:
The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.)
Change:
HTTP/1.1 (HTTP11) uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and <del> excessive tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </del> <ins> excessive tolerance of variant behavior. Because HTTP/1.1 does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </ins> HTTP/2 (HTTP2) introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,

Discussion:
Address multiple editorial comments.
NAME said
NAME said
The text currently says: Transport makes the following addition, in : That might be worth reiterating in HTTP/3.
NAME said
Two separate questions. I'm fine generalizing it to HTTP/1.x. The link between the first two sentences is the fact that HTTP/1.x uses human-readable whitespace-delimited fields, but those attributes make parsing inconsistent; subsequent versions of HTTP/2 went a different direction. If you're talking about the second and third, that could easily be a paragraph split; it's a change of idea under the umbrella of major changes of direction from H1 to H2+.
Change:
Required Insert Count to determine when it is safe to process the rest of the block. <del> If no references are made to the dynamic table, a value of 0 is encoded.  Alternatively, where the Required Insert Count is greater than zero, the encoder transforms it as follows before encoding: </del> <ins> The encoder transforms the Required Insert Count as follows before encoding: </ins> Here "MaxEntries" is the maximum number of entries that the dynamic table can have.  The smallest entry has empty name and value strings

Discussion:
This makes the encoding and decoding pseudo-code more symmetric. "Alternatively" might not be the best word here, because it might imply that the implementation has a choice. In a section about encoding Required Insert Count, it is more pure to talk about Required Insert Count being zero than to talk about whether references are made to the dynamic table.
Also, CI failed because the line is too long
Change:
Change the registry policy to: Values in the range 0-223 are assigned via Specification Required <del> RFC5226.  Values 224-255 are are reserved for Private Use. </del> <ins> RFC5226.  Values 224-255 are reserved for Private Use. </ins> Add the following:

Discussion:
This PR and
ship it
From the draft: Remove one "are" from "are are reserved".
Remove the "it" from "cannot it" in the text below:
From the Introduction section: As far as I can see the above ought to be:
Change:
configuration.  The client therefore MUST reset the state of all streams, including application state bound to those streams. <del> A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet.  These packets do not signify rejection of 0-RTT. </del> <ins> A client MAY reattempt 0-RTT if it receives a Retry or Version Negotiation packet.  These packets do not signify rejection of 0-RTT. </ins> <del> 4.8. </del> <ins> 4.6.3. </ins> When a server receives a ClientHello with the "early_data" extension, it has to decide whether to accept or reject early data from the

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
1-RTT handshake keys until it finds one that decrypts properly, and then pick up the handshake from that point. <del> If the server choosed to accept the "early_data" extension, then it </del> <ins> If the server chooses to accept the "early_data" extension, then it </ins> MUST comply with the same error handling requirements specified for all records when processing early data records.  Specifically, decryption failure of any 0-RTT record following an accepted

Discussion:
This should be "chose" not "choosed", which isn't really an accepted word.
Added another commit here for a minor wording fix that snuck in with changing all extensions to be referred to by type ID name.
Ok, I switched it to "chooses" instead & squashed my little fixes together here. There's also a fix for the "will MAY" bit that I think we discussed at some point but its fix didn't get in.
Change:
consistent pattern while avoiding collisions with any existing applicable registries in TLS. <del> The following values are reserved as GREASE values for cipher suites: </del> <ins> The following values are reserved as GREASE values for cipher suites and ALPN identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}

Discussion:
Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL
Change:
For example, a single text/plain object (content-format 0) of value "Hello World" (11 characters) would be serialized as <del> 0x82 0x00 0x4b H e l l o 0x20 w o r l d </del> <ins> 0x82 0x00 0x4b H e l l o 0x20 W o r l d </ins> In effect, the serialization for a single object is done by prefixing the object with information that there is one object (here: 0x82),

Discussion:
Address Benjamin Kaduk's outstanding DISCUSS.
No: with that, the sender sends along all formats and the recipient chooses based on its capabilities or preferences. Appropriate for single-shot mail, not at all appropriate for a request/response situation (at least not for the response part). URL Grüße, Carsten
Ah sorry, hadn't read properly (it's sender, not receiver).
LGTM
Change:
If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header <del> extension, as described in I-D.ietf-mmusic-msid, Section 3.2. </del> <ins> extension, as described in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 14. </ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in

Discussion:
The text in -14 says: If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in [I-D.ietf-mmusic-msid], Section 3.2. This should reference the BUNDLE specification, not the MSID specification, I believe.
Change:
5.3.2. <del> An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </del> <ins> An endpoint that wants to make itself discoverable sends (and regularly refreshes with) a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </ins> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per registration. <ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration location is returned. </ins> The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory.

Discussion:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke
Change:
request describes the process for constructing and processing an Encapsulated Request. <del> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </del> <ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt.

Discussion:
In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though
Change:
10.10.3. <del> This attack uses resumption PSKs as an oracle for dictionary attacks against a given ClientHello's true SNI.  To begin, the attacker first interacts with a server to obtain a resumption ticket for a given test domain, such as "test.com".  Later, upon receipt of a legitimate ClientHello without a PSK binder, it computes a PSK binder using its own ticket and forwards the resulting ClientHello.  Assume the server then validates the PSK binder on the outer ClientHello and chooses connection parameters based on the inner ClientHello.  A server which then validates information in ClientHelloOuter ticket against information in ClientHelloInner, such as the SNI, introduces an oracle that can be used to test the encrypted SNI value of specific ClientHello messages. ECH mitigates against this attack by (1) prohibiting the "pre_shared_key" extension in ClientHelloOuter and (2) requiring servers ignore this extension when processing ClientHelloOuter. Thus, if the server accepts the inner ClientHello, it only validates binders in the inner ClientHello.  This means that PSKs are used within the HPKE encryption envelope. </del> <ins> This attack aims to leak information about secret parts of the encrypted ClientHello by adding attacker-controlled parameters and observing the server's response.  In particular, the compression mechanism described in outer-extensions references parts of a potentially attacker-controlled ClientHelloOuter to construct ClientHelloInner, or a buggy server may incorrectly apply parameters from ClientHelloOuter to the handshake. To begin, the attacker first interacts with a server to obtain a resumption ticket for a given test domain, such as "example.com". Later, upon receipt of a ClientHelloOuter, it modifies it such that the server will process the resumption ticket with ClientHelloInner. If the server only accepts resumption PSKs that match the server name, it will fail the PSK binder check with an alert when ClientHelloInner is for "example.com" but silently ignore the PSK and continue when ClientHelloInner is for any other name.  This introduces an oracle for testing encrypted SNI values. This attack may be generalized to any parameter which the server varies by server name, such as ALPN preferences. ECH mitigates this attack by only using ClientHelloOuter to compute ClientHelloInner and authenticating all of ClientHelloInner with the HPKE AEAD.  If any extensions are compressed as in outer-extensions, the OuterExtensions.inner_digest field authenticates the decompressed result.  If none are compressed, the entire ClientHello is encrypted and authenticated directly.  An earlier iteration of this specification only encrypted and authenticated the "server_name" extension, which left the overall ClientHello vulnerable to an analogue of this attack. </ins> 11.

Discussion:
I think this is a more general attack and deserves a more general description of the mitigation. See URL and . NAME
Change:
that the server is unwilling to use with "skR", the server returns an error. <del> Compute an HPKE context using "skR" and the encapsulated key "enc", yielding "context". </del> <ins> Compute an HPKE context using "skR", a label of "ohttp request", and the encapsulated key "enc", yielding "context". </ins> Construct additional associated data, "aad", from "keyID", "kemID", "kdfID", and "aeadID" or as the first seven bytes of

Discussion:
This is a breaking change, but I think that it's worthwhile. "request" is an extraordinary generic string and the risk of it being used in another context is too high.
We can address test vectors in a followup PR.