jiebi/CodeConvo huggingface dataset:
Change:
3. <del> Issuers MUST provide one parameter for configuration: </del> <ins> Issuers MUST provide two parameters for configuration: </ins> Issuer Request URI: a token request URL for generating access tokens.  For example, an Issuer URL might be https://issuer.example.net/example-token-request.  This parameter uses resource media type "text/plain". <ins> Issuer Public Key values: an Issuer Public Key for an issuance protocol. </ins> The Issuer parameters can be obtained from an Issuer via a directory <del> object, which is a JSON object whose field names and values are raw values and URLs for the parameters. </del> <ins> object, which is a JSON object whose values are other JSON objects and URLs for the parameters. Each "token-keys" JSON object contains the following fields and corresponding raw values. Issuers MAY advertise multiple token-keys for the same token-type to support key rotation.  In this case, Issuers indicate preference for which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. </ins> <del> As an example, the Issuer's JSON directory could look like: </del> <ins> Altogether, the Issuer's JSON directory could look like: </ins> Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-

Discussion:
This is both a convenience for origins, as well as a way to support key rotation.
Thanks for this. IIUC the key rotation interval for non-rate-limited token issuance may be ambiguous. Since there is not necessarily a policy window defined in that case. Is that right? This would be manageable be convention; and trivial when a single entity controls both the issuer and origin.
Correct. The rotation window is currently not specified. Omitting that seems reasonable for this case. Origins can simply check in with issuers at some regular cadence as they deem fit.
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.
Change:
perform path validation (migrate-validate) if it detects a change in the IP address of its peer. <ins> When an endpoint has no validated path on which to send packets, it MAY discard connection state.  An endpoint capable of connection migration MAY wait for a new path to become available before discarding connection state. </ins> This document limits migration of connections to new client addresses, except as described in preferred-address.  Clients are responsible for initiating all migrations.  Servers do not send non-

Discussion:
NAME this is annoyingly close to done. Would you mind?
NAME : Take a look.
LGTM
Change:
9.7.5. <del> This registry lists the types of identifiers in certificates that ACME clients may request authorization to issue. </del> <ins> This registry lists the types of identifiers that can be present in ACME authorization objects. </ins> Template:

Discussion:
Currently says This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates. But ACME clients no longer directly request authorization; instead this section lists identifiers that the servers may create authorizations for based on new-order.
Change:
"max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. <ins> When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude the peer's 'max_ack_delay' from its PTO calculation.  Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. </ins> 8. There are tradeoffs inherent in a sender sending an ACK_FREQUENCY

Discussion:
by allowing implementations to not add maxackdelay to the PTO calculation if enough ack-eliciting packets are in flight.
NAME Does Jana's longer explanation help or would you like more clarification?
With this extension, an immediate ACK is expected if more than the "Packet Tolerance" ack-eliciting packets are outstanding. Given that, it may be a worthwhile optimization to allow the maxackdelay to not be included in the PTO computation in some cases. If we're not going to allow that, I think we should explain why. URL This split off , but I think the question of whether maxackdelay always needs to be included in PTO should be separate from whether QUIC would benefit from an ACK-pull mechanism of some sort. That being said, if a mechanism did exist, we add details about when ACK-pull allowed maxackdelay to not be included.
This is a clever optimization, I agree it's worth some text.
I'm not sure I understand the motivation for this (I'm also having trouble following the issue). Can we add some more explanation here?one suggestion, but lgtm otherwise.
Change:
Message lengths can be defined, and Messages can be partially reliable. <del> Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3, which refers back to the specifications for each protocol.  This back-tracking method applies to all elements of I-D.ietf-taps-minset (see appendix D of I- D.ietf-taps-interface): they are listed in appendix A of I-D.ietf- taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </del> <ins> Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3 of RFC8303 and section 3 of RFC8304, which refers back to the relevant specifications for each protocol. This back-tracking method applies to all elements of I-D.ietf-taps- minset (see appendix D of I-D.ietf-taps-interface): they are listed in appendix A of I-D.ietf-taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </ins> 10.1.

Discussion:
Section 10 of impl draft: "Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of [RFC8303]." I know it's specified like this in RFC8303 but PRIMITIVENAME does not seem to be explained or used. Maybe I didn't look careful enough but to be honest I also didn't find the use of this nomenclature from RFC8303 very helpful...
Just to answer the comment of usefulness of this nomenclature: this allows back-tracking to the relevant spec., which (I believe) is valuable for people implementing a TAPS system. In the example of CONNECT.SCTP, RFC 8303 describes this as consisting of: Interleaving' (optional), followed by 'Associate' Initialize and Associate are obvious; naturally, they come from RFC 4960. Considering to use 'Enable/Disable Interleaving' (which is very important for a TAPS system - to implement priorities between streams) is perhaps less obvious, and the text points back at RFC 8260.
Change:
7.2. The cipher suites defined in this draft use short authentication tags <del> for both inner and outer encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </del> <ins> for encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </ins> 8.

Discussion:
I don't think we should not reference the inner/outer encryption, as we only define the e2ee encryption in the draft
Change:
data.  Compression MUST NOT be used if the source of data cannot be reliably determined. <del> Further considerations regarding the compression of fields sections </del> <ins> Further considerations regarding the compression of field sections </ins> are described in QPACK. 10.7.

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?
Change:
For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: <ins> %%% Key Exchange Messages </ins> X and Y respectively are the binary representations of the X and Y values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by

Discussion:
Fix the spacing in and add it to Appendix B.3.1. Add missing space in .
Change:
array after they are created.  If a client observes a change in the contents of either array, then it SHOULD consider the order invalid. <del> The "authorizations" array in the challenge SHOULD reflect all </del> <ins> The "authorizations" array of the order SHOULD reflect all </ins> authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions.  For example, if a CA allows multiple

Discussion:
Rewrite "in challenge", which seems to be incorrect to "of the order"
Good catch! Thank you NAME :eagle: :mag:
Change:
Trustworthiness Claims being relied upon from the Verifier considered the chain of trust for the Attesting Environment. <del> There are two categorizations Verifier identities defined in this document. </del> <ins> There are two categorizations of Verifier identities defined in this document: </ins> verifier build: a unique instance of a software build running as a Verifier.

Discussion:
"There are two categorizations Verifier identities defined in this document" does not read awesomely. I am putting forward a (maybe even worse) alternative. Feel free to English-ise it.
Looks like an improvement
Change:
table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document <del> RFC8126 is required to register an extension with the value "Yes". </del> <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note:

Discussion:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .
Change:
User Agent would send an INVITE message containing SDP for the media session along with the endpoint's certificate fingerprint, which can be signed using the procedures described in RFC4474 for the benefit <del> of forwarding the message to other entities.  Other entities can now verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and check that is the authorized entity. </del> <ins> of forwarding the message to other entities by the Focus RFC4353. Other entities can now verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and check that is the authorized entity. </ins> Ultimately, if using session signaling, an endpoint's certificate fingerprint would need to be securely mapped to a user and conveyed

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. <del> When responding to these special queries for "dns://resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section. This will allow the DNS client to make queries over an encrypted </del> <ins> When responding to these special queries for "resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section.  This will allow the DNS client to make queries over an encrypted </ins> connection without waiting to resolve the Encrypted Resolver name per I-D.ietf-dnsop-svcb-https.  If no A/AAAA records or SVCB IP address hints are included, clients will be forced to delay use of the

Discussion:
There is no need to use a DNS URI for this. You are only using the name. And you don't cite RFC 4501. It is also incorrect, because you are treating "URL" as the authority, rather than the qname. What you really want is "URL;type=64" or something like that. But the words you have are adequately clear.
Change:
3.2. <del> The iPATCH method can be used to change the values of SenML Records, to add new Records, and to remove existing Records.  The names and times of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record can match at most one Target Record.  Patch Packs can also include new values and other SenML Fields for the Records. </del> <ins> The (i)PATCH method can be used to change the values of SenML Records, to add new Records, and to remove existing Records.  The names and times of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record can match at most one Target Record.  Patch Packs can also include new values and other SenML Fields for the Records.  Application of Patch Packs is idempotent. </ins> When the name in a Patch Record matches with the name in an existing <del> Record, the time values are compared.  If the time values do not exist or are equal in both Records, the Target Record is replaced with the contents of the Patch Record. </del> <ins> Record, the resolved time values are compared.  If the time values either do not exist in both Records or are equal, the Target Record is replaced with the contents of the Patch Record. </ins> If a Patch Record contains a name, or combination of a time value and a name, that do not exist in any existing Record in the Pack, the

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:
The type of each measurement. <del> The aggregation function to compute (e.g., sum, mean, etc.) and an optional aggregation parameter. </del> <ins> The aggregation function to compute (e.g., sum, mean, etc.). </ins> The set of aggregators and necessary cryptographic keying material to use.

Discussion:
Similar to , it should not be possible for a share to be included in more than one batch. The timestamp currently gives us some way of ensuring that reports map to at most batch, but not a way of ensuring that reports aren't included two overlapping batch windows. It's not immediately clear if include a single report in two overlapping batch windows is a problem, or if a problem only arises when these windows are disjoint. We should probably clarify what are the inter-batch requirements here and what sort of replay prevention is required.
The aggregators (either the leader or helper) can prevent the collector from getting outputs from overlapping batches by remembering batch intervals. For example, suppose the leader responded successfully to a collect request for time interval . Then suppose that, some time later, the collector requests output shares for , where . The potential privacy violation occurs because the sets of reports in each batch are non-disjoint. To prevent this, the leader might respond to the second request with an error, or it might just include the reports in .
If aggregators are meant to use the report timestamp to protect against replay, then I think it needs to appear in the AEAD-ed message constructed by the client (i.e. ). Otherwise a leader could insert arbitrary timestamps into and trick helpers into exceeding privacy budgets or double counting inputs. Additionally, a batching client could insert arbitrary values into .
I created a PR that addresses this issue partially. What's left to do is allow multiple collect requests over the same batch, as required by the PDA protocol (e.g., Hits). I have an idea for how to do this, I'll follow up with a PR.
Closed by URL
LGTM -- thanks!
Change:
A Key Derivation Function (KDF) These values are based on the values that TLS negotiates and are used <del> by QUIC to generate packet and header protection keys (see packet- protection and header-protect). </del> <ins> by QUIC to generate packet and header protection keys; see packet- protection and header-protect. </ins> If 0-RTT is possible, it is ready after the client sends a TLS ClientHello message or the server receives that message.  After

Discussion:
This clarifies the TLS interface by explaining that TLS only generates outputs (handshake bytes or keying material) in response to inputs. Previously, the only inputs we acknowledged were the handshake bytes, but this recognizes two more: the signal from the client to start handshaking, and - for async validation - a signal that a certificate is OK or not.
Weren't we going to say that the traffic keys might get generated asynchronously in ? I wonder how this PR interacts with . I see this PR calling out three types of events (i.e. generation of CH, input of handshake bytes, completion of certificate validation) as the "inputs," then claim that TLS provides the keys "synchronously" in relation to such events. That works as a definition, but I am not sure if it is easy to comprehend. I think my preference would be to talk about (a)synchronicity from the viewpoint of a transport. It would be easier to say that TLS might provide keys "asynchronously" from what the transport provides as input, then point out that key generation (possibly in relation to certificate verification) might take some time.
To answer both questions, I am planning on integrating the text from as well. That would cover the case where the TLS stack has to disappear for some time before it produces new outputs, however that manifests.
NAME NAME I've rebased this based on the changes in . Would you mind checking my work?
The label should be instead of .
Thanks NAME fixed.
The process for interacting with TLS does not acknowledge the possibility that progress in the handshake might depend on inputs other than CRYPTO frames. In particular, endpoints might need to perform additional checking to decide that the TLS handshake is complete. The most important example being the processing that occurs for certificate validation. This is often an asynchronous process, with OCSP and other muck, so recognizing that explicitly in the draft is worthwhile. This might help tease out one of the causes of the problem discussed in , but it doesn't lead to a solution.
Q: Does this indicate that the TLS changes involved in may be editorial? I'd like to focus on the transport and recovery changes to deal with the issue, and it'd be nice if the tls changes were separate from my perspective.
Why isn't adequate for this? Specifically, isn't it enough to change the stance from synchronous to asynchronous?

I would prefer to explain how certificate validation can take time and block availability of keys.
Should this become proposal-ready?
NAME : This is an editorial issue, so no.
Thanks looks great!
Change:
change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del> <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.

Discussion:
LGTM.
Actually, looking at a bit closer, perhaps consider: "... endpoint and cooperating intermediaries to efficiently ..." and perhaps make the Manageability reference explicitly to section 3.1 that covers identifying QUIC traffic.
Note that this is the second paragraph of the document. I'd prefer not to pile too many unrelated concepts in at this point. I think that it is OK to consider "cooperating intermediaries" to be implicit when we say "endpoint" when operating at this level of abstraction. Toward the end, where manageability is cited, is a better place for that sort of detail. I narrowed the citation to point to Section 3.1 as you suggested.
I think this update addresses NAME 's point in the telechat review.
Change:
change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del> <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.

Discussion:
This one says something like what Lucas said, with the caveat that the whole thing about per-connection ID is specific to spin bits, so I dropped that.
LGTM
Change:
3.2. The Captive Portal API data structures are specified in JavaScript <del> Object Notation (JSON) RFC7159. </del> <ins> Object Notation (JSON) RFC7159.  Requests and responses for the Captive Portal API use the "application/captive+json" media type. Clients SHOULD include this media type as an Accept header in their GET requests, and servers MUST mark this media type as their Content- Type header in responses. </ins> The following keys are defined at the top-level of the JSON structure returned by the API server:

Discussion:
Satisfied
application/json is fine in the general sense, but if you want to ever do things like versioning, then a media type is important. Crib from if you want a recent example.
Discussed in London, consensus to use a new media type.
I am ok with the added text.
Change:
"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <del> The reader is assumed to be familiar with the DTLS specifications since this document defines an extension to DTLS 1.2 and DTLS 1.3. </del> <ins> The reader is assumed to be familiar with DTLS RFC6347. </ins> 3.

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.