jiebi/CodeConvo huggingface dataset:
Change:
processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame. <del> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used. </del> 13.2.6. ACK frames MUST only be carried in a packet that has the same packet

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.
Change:
general-purpose APIs use a URI for this field to avoid collisions between multiple API types protected by a single AS. <del> While it is expected that many APIs will have its own properties, a </del> <ins> While it is expected that many APIs will have their own properties, a </ins> set of common properties are defined here.  Specific API implementations SHOULD NOT re-use these fields with different semantics or syntax.  The available values for these properties are

Discussion:
Minor typos
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit b2ce64bfa924bc30b24ea9301223156ec0eb8520 https://deploy-preview-204--gnap-core-protocol-editors-URL
within (and likely other sections), the property names are plural, but the text sometimes refers to the singular property names. This should be cleaned up to be consistent one way or another.
Change:
This document does not take a position on whether those goals are "valid" (whatever that might mean). <del> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications. </del> Both "End-to-End" and "Hop-by-Hop" media encryption have specific implications for streaming operators.  These are described in hop-by- hop-encrypt and e2em-encrypt.

Discussion:
From NAME Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).
This paragraph appears later in the document - I can move this up under the bullet points and make that clearer.
Fixed as in my previous comment.
BTW, unsure how the authors want me to mark "I have read the change and I like it" ? Currently, simply using a "thum up" emoticon on the solution comment. Let me know if you prefer another marking.
NAME If I can't hear you either giggling or screaming all the way to Texas, and I see a "thumbs up" emoticon, that's clear enough to me!
LGTM
Change:
Add the following to the TLS Compression Method Identifiers registry RFC3749: <del> Note: Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </del> <ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </ins> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: <del> Note: The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </del> <ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </ins> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to

Discussion:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.
Change:
2.8. <del> Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </del> <ins> Version Negotiation packets are used by the server to indicate that a requested version from the client is not supported (see section 6 of QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically protected, but QUIC versions can use later encrypted messages to verify that they were authentic.  Therefore any modification of this list will be detected and may cause the endpoints to terminate the connection attempt. </ins> Also note that the list of versions in the Version Negotiation packet may contain reserved versions.  This mechanism is used to avoid

Discussion:
addresses
I don’t have comments on the validity of the discussion text in section 12 and the described procedures, but I do wonder why this is information for an application designer, rather than for managing operations. Is this the correct ID for this information? and if its is, could it be explained a little more to what the app designer needs too know. This section seems rather devoid of useful references. please add some.
The split here was see as applicability is addressed at people who want to use QUIC (application designer but also people deploying QUIC at servers) and manageability for people who have to handle QUIC traffic (mainly network operator incl probably data centre operators). I know the split between the two last categories (deploying servers and managing a dc networks) is not always that clear. It's probably this section and the one about load balancing in manageability. I'm open to discuss where which section belongs. Do we need to bring this to the meeting? NAME what kind of reference are you thinking of?
On what to do in Manageability: I'd suggest we write some text that says: "QUIC provides a version negotiation process, that allows new versions to be introduced. The deployment of new versions is discussed in section 12 of [ID. ietf-quic-applicability]." Maybe even just as the first para of Manageability: Sect: 2.8. I meant add reference to section 6 in QUIC Transport - to both these documents
There is already section 2.8 on "Version Negotiation and Greasing" and section 3.1.1. on "Identifying Negotiated Version" in the manageability draft. Ideally the idea is to not have cross reference between manageability and applicability. I added a reference to section 6 of the quic-transport draft in manageability (see PR ). Not sure we need that reference also in the applicability draft because that section actually doesn't require any knowledge of the internals on how version negotiation works...
Change:
10.4.4. <del> As more clients enable ECHO support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECHO extensions becomes less suspicious and part of common or predictable client behavior.  In other words, if all Web browsers start using ECHO, the presence of this value does not signal suspicious behavior to passive eavesdroppers. Additionally, this specification allows for clients to send GREASE ECHO extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. </del> <ins> The only explicit signal indicating possible use of ECHO is the ClientHello "encrypted_client_hello" extension.  Server handshake messages do not contain any signal indicating use or negotiation of ECHO.  Clients MAY GREASE the "encrypted_client_hello" extension, as described in grease-extensions, which helps ensure the ecosystem handles ECHO correctly.  Moreover, as more clients enable ECHO support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECHO extensions becomes less unusual and part of typical client behavior.  In other words, if all Web browsers start using ECHO, the presence of this value will not signal unusual behavior to passive eavesdroppers. </ins> 10.4.5.

Discussion:
Addresses . cc NAME
There's no explicit signal indicating that ECHO was negotiated for a connection. Thus, clients must perform trial decryption with both possible handshake keys. If we intend to keep this, then we should crisply state that "don't stick out" is limited to explicit signals, i.e., implicit signals such as size-related information is probably out of scope. (It's certainly an open question what is the "best" padding scheme for handshake messages.) cc NAME
Change:
To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: <ins> Where SignContent is specified as: And its fields set to: </ins> Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm.

Discussion:
This PR fixes some minor issues with the presentation language. Moving and to their own block is required so that the can now detect them.
Change:
That approach would have been difficult to roll out reliably on DTLS where many implementations do not expose sequence numbers, and would <del> still not prevent attacks like in I-D.mattsson-core-coap-actuators </del> <ins> still not prevent attacks like in I-D.mattsson-core-coap-attacks </ins> Section 2.5.2. 3.8.

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with <del> the '1' 1-bit pattern, followed by the "S" bit indicating whether the </del> <ins> the '1' 1-bit pattern, followed by the 'T' bit indicating whether the </ins> reference is into the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the <del> table entry for the header field.  When S=1, the number represents the static table index; when S=0, the number is the relative index of </del> <ins> table entry for the header field.  When T=1, the number represents the static table index; when T=0, the number is the relative index of </ins> the entry in the dynamic table. 4.5.3.

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
band mechanism. "max-age", an optional attribute that consists of the number of <del> seconds for which the challenge will be accepted by the Origin. </del> <ins> seconds for which the challenge will be accepted by the origin. </ins> Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> Origins MAY also include the standard "realm" attribute, if desired. Issuance protocols MAY require other attributes. </del> <ins> The header MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </ins> As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the TokenChallenge has a token_type the client does not recognize or <del> support, it MUST NOT parse or respond to the challenge. </del> <ins> support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid.  For example, clients can choose to reject challenges that list origin names for which current connection is not authoritative (according to the TLS certificate). </ins> Note that it is possible for the WWW-Authenticate header to include <del> multiple challenges, in order to allow the Client to fetch a batch of </del> <ins> multiple challenges, in order to allow the client to fetch a batch of </ins> multiple tokens for future use. For example, the WWW-Authenticate header could look like this: <del> If a Client fetches a batch of multiple tokens for future use that </del> <ins> If a client fetches a batch of multiple tokens for future use that </ins> are bound to a specific redemption context (the redemption_context in <del> the TokenChallenge was not empty), Clients SHOULD discard these </del> <ins> the TokenChallenge was not empty), clients SHOULD discard these </ins> tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not <del> be linkable to the original context could allow the Origin to recognize a Client. </del> <ins> be linkable to the original context could allow the origin to recognize a client. </ins> 2.1.1.

Discussion:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!
Change:
8.2. <del> This document will request IANA to register "masque/udp" in the "Well-Known URIs" registry maintained at </del> <ins> This document will request IANA to register "masque" in the "Well- Known URIs" registry maintained at </ins> <<https://www.iana.org/assignments/well-known-uris>>.

Discussion:
As per registrations cannot contain a character so we register instead of
L602 still includes /udp, Is that intended?
Yeah my thinking was that we register and for now only define semantics for . A future document can tweak the related info line to also assign semantics to
I'm not a .well-known expert. My interpretation from mnot's suggestion was the prefix ends up as ".well-known/masque" and that the remainder is defined here as "/udp/{targethost}/{targetport}". Yes something else might come along and define other things to follow the prefix .well-known/masque but that can be deferred for later, and that spec needs to state all of its own rules. An alternative is that we expect everything after the prefix to behave in a similar way, I.e. .well-known/masque/{masquetype}/{targethost}/{target_port}. I don't know if that holds true.
From reading it appears that there is a lot of flexibility on how to organize additional path components so this appears OK to me, but I'll let NAME provide insights here
Yep, how you deal with what's "under" your registration is up to you. One option is to create a separate registry; another is to require additional values to update the registering RFC.
Change:
semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the <del> peer.  The secret key used to sign a credential corresponds to the </del> <ins> peer.  The private key used to sign a credential corresponds to the </ins> public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a

Discussion:
In section 3, the document says: The secret key used to sign ... Please change "secret" to "private". Later in the sentence, [RFC5280] is referenced, and it talks about "private key" in this context.
Addressed in
Change:
When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the transceiver direction is intersected with the offered direction, as <del> explained in the sec.generating-an-answer section below. </del> <ins> explained in sec.generating-an-answer below. </ins> Note that while setDirection sets the direction property of the transceiver immediately (sec.transceiver-direction), this property

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:
exceeds that limit, it MAY not be served. The field is an Item and its value is a non-negative Integer referred <del> to as the "expiring-limit".  Parameters are not allowed. </del> <ins> to as the "expiring-limit".  This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> The expiring-limit MUST be set to the service limit that is closest to reaching its limit, and the associated time window MUST either be:

Discussion:
Parameters are not allowed, and if they appear they MUST be ignored.
Why not just 'If Parameters appear they MUST be ignored'?
NAME we wanted to stress the fact that servers are not expected to provide parameters, otherwise some clients could just consider the whole field value malformed and ignore it.
The normal way to do that is something like:
Ok, I'll rebase this PR tomorrow :) Late night now in Italy. Thanks for all this support :)
In a few places, the specification says "Parameters are not allowed" but does not spell out what should happen if they appear.
Change:
This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- <del> D.schwartz-svcb-dns.  However, if any protocol does not involve some </del> <ins> D.ietf-add-svcb-dns.  However, if any protocol does not involve some </ins> form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in authenticated.

Discussion:
Addressing
Once it's published, we should reference the official draft for draft-schwartz-svcb-dns
Change:
6.3.1. <ins> As described above, a client can indicate its agreement with the CA's terms of service by setting the "terms-of-service-agreed" field in its registration object to "true". If the server has changed its terms of service since a client initially agreed, and the server is unwilling to process a request without explicit agreement to the new terms, then it MUST return an error response with status code 403 (Forbidden) and type "urn:ietf:params:acme:error:agreementRequired".  This response MUST include a Link header with link relation "terms-of-service" and the latest terms-of-service URL. The problem document returned with the error MUST also include an "instance" field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms. 6.3.2. </ins> A client may wish to change the public key that is associated with a registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.

Discussion:
Right now, it's not clear when the client needs to agree to the server's terms, and what the server should do if it needs the client to re-agree. This PR addresses both with a dedicated error code and some related behaviors.
Change:
MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS <del> with applicaiton protocols. </del> <ins> with application protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a

Discussion:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker
Change:
RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. <del> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers </del> <ins> Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers </ins> blindly implement cipher suites.  Therefore, IANA [SHALL add/has added] the following warning to the registry:

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .