jiebi/CodeConvo huggingface dataset:
Change:
server as described in finding_an_rd. The registrant-ep sends (and regularly refreshes with) a POST <del> request to the "/.well-known/core" URI of the directory server of </del> <ins> request to the "/.well-known/rd" URI of the directory server of </ins> choice.  The body of the POST request is empty, and triggers the resource directory server to perform GET requests at the requesting registrant-ep's /.well-known/core to obtain the link-

Discussion:
No deployed implementations of simple registration are known that can't switch over easily. As per URL
Change:
HTTPS server. Verify that the Content-Type header of the response is either <del> absent, or has the value "application/json". Verify that the body of the response is well-formed authorized key object. </del> <ins> absent, or has the value "text/plain". </ins> <del> Verify that the "key" and "token" fields in the authorized key object match the values from the authorized key object in the challenge. </del> <ins> Verify that the body of the response is well-formed key authorization. </ins> <del> Comparisons of the "token" field MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </del> <ins> Verify that key authorization provided by the server matches the token for this challenge and the client's account key. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
consume congestion window, which could delay subsequent transmission by an application. <del> 14.3.1. </del> <ins> 14.4.1. </ins> Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
7. <del> A resolver at "simple.example" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </del> <ins> A resolver at ""simple.example"" that supports DNS over TLS on port 853 (implicitly, as this is its default port): </ins> <del> A resolver at "doh.example" that supports only DNS over HTTPS (DNS over TLS is not supported): </del> <ins> A resolver at ""doh.example"" that supports only DNS over HTTPS (DNS over TLS is not supported): </ins> <del> A resolver at "resolver.example" that supports </del> <ins> A resolver at ""resolver.example"" that supports: </ins> <del> DNS over TLS on "resolver.example" ports 853 (implicit in </del> <ins> DNS over TLS on ""resolver.example"" ports 853 (implicit in </ins> record 1) and 8530 (explicit in record 2), with <del> "resolver.example" as the Authentication Domain Name, </del> <ins> ""resolver.example"" as the Authentication Domain Name, </ins> DNS over HTTPS at "https://resolver.example/dns-query{?dns}" (record 1), and

Discussion:
These are really minor, was making all your dns names use the same syntax you started with ("") But I think the examples should look similar in nature. (i'm also thinking of some horrible bad examples to include)
agreed - totally missed that. I pushed up the edit if that is easier.
Change:
The public key of a signature key pair matching the SignatureScheme specified by the CipherSuite of the group <del> The identity of the holder of the private keys </del> <ins> The identity of the holder of the private key </ins> Credentials MAY also include information that allows a relying party to verify the identity / signing key binding.

Discussion:
Thanks NAME pointing out the imprecision. Is this what you were looking for? Thanks NAME for the pointer to the correct registry.
This doesn't make sense because we don't actually use this registry. The signature scheme is defined by the ciphersuite, and the ciphersuite registry doesn't map to this unrelated registry
The is not authoritative in the group context and will always correspond with the one in the group (as is required by the generic description of the functionalities that Credentials have to provide). The SignatureScheme is there for when the Credential is handled in a context where there is no surrounding group. For example, when it's handled by the AS. There is a mapping from ciphersuit to SignatureScheme in Table 5, the entries of which correspond to the entries in the referenced registry. Is that what you meant?
Change:
applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example the strings could be defined as 'YES' and 'NO '.) <del> Timing Issues - TBD </del>

Discussion:
Response to note from Göran Selander 1) we need to say where the secret is derived from 2) how it is formatted, and 3) why we are not using KA and KB in the KDF step.
Change:
server from repeated client probes, the PTO backoff is not reset at a client that is not yet certain that the server has finished validating the client's address.  That is, a client does not reset <del> the PTO backoff factor on receiving acknowledgements until it receives a HANDSHAKE_DONE frame or an acknowledgement for one of its Handshake or 1-RTT packets. </del> <ins> the PTO backoff factor on receiving acknowledgements until the handshake is confirmed; see Section 4.1.2 of QUIC-TLS. </ins> This exponential reduction in the sender's rate is important because consecutive PTOs might be caused by loss of packets or

Discussion:
This avoids redefinition of the conditions for handshake confirmation. It's fewer words, even with the extra references.
The draft should use "handshake confirmed" and point to the TLS draft instead of describing the conditions individually in various places.
Change:
Preference: can take one of five values (Prohibit, Avoid, Ignore, Prefer, Require) for the level of preference of a given property <del> during protocol selection; see selection-props. </del> <ins> during protocol selection; see selection-props.  When querying, a Preference is of type Boolean, with "true" indicating that the Selection Property has been applied. </ins> For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are

Discussion:
I chose boolean, because, when querying, it only matters whether a Selection Property was chosen or not (I believe).
From Kyle Rose: NAME says: I think this isn't very controversial, I believe we should just do this as he suggested. This issue is just a reminder for myself to do this.
Thanks
Change:
3. A device may learn about Captive Portal API URIs through more than <del> one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical. However, if the URIs learned are not in fact all identical the captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence over any URI learned via some other mechanism, such as a redirect. </del> <ins> one of (or indeed all of) the above options.  Implementations can select their own precedence order (e.g., prefer one of the IPv6 options before the DHCPv4 option, or vice versa, et cetera). </ins> If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device <del> owner or administrator.  Implementations can select their own precedence order. </del> <ins> owner or administrator; it is a network configuration error if the learned URIs are not all identical. </ins> 4.

Discussion:
""" — Section 3 — Specifically, URIs learned via any of the options in Section 2 should take precedence over any URI learned via some other mechanism Given the MUST that comes before this, I think the word “should” ought to be removed, to avoid any confusion. """ Actually, this text is left over from the brief period of time when there was an HTTP redirect Link-Relation header. That option was removed, and I think the 2nd paragraph can be deleted. The 1st and 3rd paragraphs can probably be reworked into two much tighter paragraphs.
Change:
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1. The digest used in the mask generation function MUST be the same as the digest which is being signed (i.e., what appears in <del> algorithm.signature).  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del> <ins> algorithm.signature).  The length of the salt MUST be equal to the octet length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the

Discussion:
The RSA-PSS salt length seems to be missing from the specification. The original post on the mailing list and a few other sources propose that where is the length of the digest output in bytes. Should this be raised on the mailing list again or was this agreed on already?
Let's just do it the way you propose. PR welcome
Change:
there is a missing packet, an immediate ACK is sent. If the reordering theshold is 3 and ACKs are only sent due to <del> reordering: "Receive 1 Receive 3 -> 2 Missing Receive 4 -> 2 Missing Receive 5 -> Send ACK because of 2 Receive 8 -> 6,7 Missing Receive 9 -> Send ACK because of 6, 7 Missing Receive 10 -> Send ACK because of 7 " </del> <ins> reordering: </ins> If the reordering threshold is 5 and ACKs are only sent due to <del> reordering: "Receive 1 Receive 3 -> 2 Missing Receive 5 -> 2 Missing, 4 Missing Receive 6 -> 2 Missing, 4 Missing Receive 7 -> Send ACK because of 2, 4 Missing Receive 8 -> 4 Missing Receive 9 -> Send ACK because of 4 " </del> <ins> reordering: </ins> 6.2.

Discussion:
apparently not...
Yeah unfortunately this ain't regular markdown, tilde is needed to instruct the RFC tooling of the correct artwork type (which, FYI, you can theoretically tweak with additional labels but that you shouldn't need here).
Aren't backticks and tildes equivalent? Either way, this looks fine.
Change:
Each of these hostnames may also resolve to one or more addresses, thus creating multiple layers of branching. <del> 4.1.2.2. </del> <ins> 4.1.3.2. </ins> If a client has multiple network interfaces available to it, such as mobile client with both Wi-Fi and Cellular connectivity, it can

Discussion:
Restructure to address Rearrange to include Rendezvous and Environment Discovery text in connection establishment. Remove that previous section. was intended to check the ordering of sections against the other drafts and to merge . I have merged the Rendezvous text into Connection Establishment, but I haven't changed any of the text yet. I am a little concerned about creating an interdependancy in the text between derriving endpoints (name lookup) and the ICE/TURN stuff. More generally, I am not sure what to say about name resolution and proxies (ala ). TOR opens a can of privacy worms for name lookup and racing paths that I am not sure how to address.
Looks good apart from typo!
Having proxies to go through on a system (SOCKS, HTTP Connect, etc) or a set of TOR endpoints requires the implementation to do some nested/recursive work, and pass down endpoints correctly to protocol instances. The implementation document should describe this.
+1
There is already text in 4.1.3.3. Protocol Options. Is that sufficient or do we need more?
Review structure. What fits in pre-establishment. Relation system policy - cached state. Generalizes
Discussed in Singapore, we'll have more structure comments later, but we've done a lot of changes since then.
I like the change, as it makes the process much clearer and reduces the awkwardness of ICE/STUN. To model TOR, SOCKS, or other tunnelling protocols, I would refrain from seeing them as protocol stacks, but treat them as derived paths that only support these stacks. This removes the need for cupeling name resolution to the protocol stack, and looks quite natural to me as these derived paths may be available in the connection cache or need to be established for name resolution anyway before starting the real candidate racing. If we want to do so, it might be easier to talk about paths (that have one or more corresponding local endpoints), derived paths, derived remote endpoints (as result of name resolution on each path) and protocol stacks.
Change:
This and the following sections define the required set of REST interfaces between an RD, endpoints and lookup clients.  Although the examples throughout these sections assume the use of CoAP RFC7252, <del> these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple Registration cannot be executed as the base attribute (which is mandatory for HTTP) cannot be used there.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces. </del> <ins> these REST interfaces can also be realized using HTTP RFC7230.  The multicast discovery and simple registration operations are exceptions to that, as they rely on mechanisms unavailable in HTTP.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown. An RD implementing this specification MUST support the discovery, registration, update, lookup, and removal interfaces. </ins> All operations on the contents of the RD MUST be atomic and idempotent.

Discussion:
The previous sentence was barely readable. Details were removed as they are obvious (multicast) or already mentioned in the respective section (simple registration).
Change:
multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> Efficient use of Connection Groups: This boolean property specifies whether an application considers it useful to create Connection Groups, e.g. to explicitly prioritize between Connections within a Connection Group.  This property will tend to select multistreaming transport protocols, which can multiplex Connections into a Connection Group over a single flow.  This is not a strict requirement.  The default is to not have this option. </del> <ins> Multiplex connections: This boolean property specifies that the application would prefer multiple Connections between the same endpoints within a Connection Group to be multiplexed onto a single underlying transport connection where possible, for reasons of efficiency.  This is not a strict requirement.  The default is to not have this option. </ins> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an

Discussion:
The API document says: I'm not sure I follow this. The text doesn't seem to match the option name: it isn't saying use connection groups efficiently or not, it's specifying whether connection groups can be used at all. It's also not clear why prioritisation is given as an example. Would it be clearer written something more like the following?
yep. Although you still have to explicitly entangle connections by cloning them if you want them to be guaranteed to be within a connection group.
URL makes me question why we need this parameter?
To explicitly prefer multistreaming protocols during selection, because you wrote your app to clone connections instead of cloning preconnections.
(see )
Change:
Separate specifications may define matching rules for other certificate extensions. <del> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication. </del> <ins> Note: It is a fatal "unexpected_message" alert for an anonymous server to request client authentication. </ins> 4.3.

Discussion:
Noticed these while reviewing the negotiation PR: handshakefailure means "the sender was unable to negotiate an acceptable set of security parameters given the options available", but these are all protocol errors that should only occur with a buggy server. Switch them to more appropriate ones: If the HelloRetryRequest makes no sense, it is an illegalparameter. If we get a second HelloRetryRequest, it's an unexpectedmessage (the client is in a state where it expects a ServerHello and will likely just fall through to the generic message-mismatch codepath). If HelloRetryRequest and ServerHello are inconsistent, it is an illegalparameter. If an anonymous server sends a CertificateRequest, it's an unexpected_message (this too will likely use the generic message-mismatch codepath).
Change:
master key, so that traffic can be decrypted only by those who know the current EKTKey. <del> 2.5. </del> <ins> 2.6. </ins> EKT SHOULD be used over SRTP, and other specification MAY define how to use it over SRTCP.  SRTP is preferred because it shares fate with

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request. <ins> For example, the IP proxy could respond with: </ins> 4.5. Unlike UDP proxying requests, which require specifying a target host,

Discussion:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!
Change:
case of re-boots.  This document RECOMMENDS the exchange of 64 bit random nonces.  Considering the birthday paradox, the average collision for each nonce will happen after 2^32 messages, which is <del> considerably more token provisioned than would be expected for </del> <ins> considerably more token provisionings than would be expected for </ins> intended applications.  If applications use something else, such as a counter, they need to guarantee that reboot and loss of state on either node does not provoke reuse.  If that is not guaranteed, nodes

Discussion:
This part got reworded a bit in response to IESG comments and this (admittedly unusual) grammatical construction got changed to something that doesn't make sense.
Thanks. "which is considerably more token provisioned" is clearly not right. I think the intent was "tokens provisioned" but "token provisionings" is more accurate. Unless there are any objections I will merge on Monday.
Change:
2. <del> This section describes the components in satellite system that lays on SATCOM systems dedicated to broadband Internet access that follows </del> <ins> This section describes the components in a satellite system based on SATCOM systems dedicated to broadband Internet access that follows </ins> the DVB standards.  A high-level description of a multi-gateway <del> satellites network is provided.  There are multiple SATCOM systems, </del> <ins> satellite network is provided.  There are multiple SATCOM systems, </ins> such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity

Discussion:
A few document nits… Section 2, 1st and 2nd Sentences “in satellite system” should be “in a satellite system”. Not clear what “lays” means here. “multi-gateway satellites network” should be “multi-gateway satellite network”. (Most of the uses cases have nothing to do with multi-gateway, though.) Section 3, 2nd Sentence Delete the duplicate “where”. Section 6, 2nd Sentence “that the some scenarios” should be “that some scenarios”.
Thanks for having identified the NITS. Closed by PR
Change:
6.2.1.2. <del> As described in Section 17.5.1 of QUIC-TRANSPORT, endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets.  At this point, all loss recovery state for the Initial packet number space is also discarded.  Packets that are in flight for the packet number space are not declared as either acknowledged or lost.  After discarding state, new Initial packets will not be sent. </del> <ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender considers them no longer in flight.  That is, the sender SHOULD discard all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging Handshake packets (see Section 17.2.2.1 of QUIC- TRANSPORT).  At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is discarded. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). </ins> 6.2.2.

Discussion:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.