jiebi/CodeConvo huggingface dataset:
Change:
Note that when the load balancer's table for a configuration is empty, all incoming DCIDs corresponding to that configuration are <del> non-compliant by definition. </del> <ins> unroutable by definition. </ins> <del> The handling of a non-compliant long-header packet depends on the reason for non-compliance.  The load balancer MUST applyt this logic: </del> <ins> The handling of an unroutable long-header packet depends on the reason for unroutability.  The load balancer MUST applyt this logic: </ins> If the config rotation bits do not match a known configuration, <del> the load balancer routes the packet using an arbitrary algorithm (see arbitrary-algorithm). </del> <ins> the load balancer routes the packet using a fallback algorithm (see fallback-algorithm). </ins> If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer skips the first

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.
Change:
RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. <ins> Port: The Source Port of the UDP datagram that triggered the Retry packet.  This field MUST be present if and only if the ODCIL is greater than zero.  This field is therefore always absent in tokens in NEW_TOKEN frames. </ins> Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet.

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
3.4.2.2. The "dot-selector" selects the node of the member value corresponding <del> to the member name from any JSON object in its input nodelist.  The behaviour is unpredictable if the JSON object has duplicate names. </del> <ins> to the member name from any JSON object in its input nodelist. </ins> It selects no nodes from any other JSON value.

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity
Change:
As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous <del> unacknowledged packet numbers, including the new packet. For example, if an endpoint has received an acknowledgment for packet 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. </del> <ins> unacknowledged packet numbers, including the new packet.  Pseudo-code and examples for packet number encoding can be found in sample- packet-number-encoding. </ins> At a receiver, protection of the packet number is removed prior to recovering the full packet number.  The full packet number is then

Discussion:
I took some liberties with data types here, but... pseudocode. I do wonder if the slice notation is sufficiently clear; I was hesitant to just do bit-shifts and masks because the number of bytes returned is key. An alternative would be simply to return the number of bytes, I suppose.
bit more than the base-2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. That is really hard to parse. 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. and so is that. Indeed I found the remaining paras of the section difficult to follow.
I agree that first sentence is hard to parse.
I also agree regarding the first. As this is an alternative description, and I don't have anything better to offer, I plan not to change anything unless someone offers something good. The second seems fine.
I wonder if the real takeaway here is that these "examples in passing" assume the reader is deeply following along with the algorithm in their head; I know I don't, but I'm also not implementing packetization. We already have an appendix that illustrates packet number decoding; perhaps we should move one or both paragraphs to an appendix that illustrates selecting an encoding, with these as the examples. Reading the rest of the section, is "protection of the packet number" the term we've used elsewhere? Shouldn't that be "header protection," perhaps with a cross-ref to -tls?
Change:
4. When a DNS client is configured with an Unencrypted Resolver IP <del> address, it SHOULD query the resolver for SVCB records for "dns://resolver.arpa" before making other queries.  Specifically, the </del> <ins> address, it SHOULD query the resolver for SVCB records for the name "resolver.arpa" before making other queries.  Specifically, the </ins> client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https.

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:
The serialized and encrypted ClientHelloInner structure, AEAD- encrypted using HPKE with the selected KEM, KDF, and AEAD <del> algorithm and key generated as described below. </del> <ins> algorithm and key generated as described below.  {:br} </ins> If the server accepts ECH, it does not send this extension.  If it rejects ECH, then it sends the following structure in

Discussion:
This ensures that each paragraph line breaks at 80 characters. No other change is intended (editorial or otherwise).
Do you want to borrow the linter that we use in QUIC? Just copy to your Makefile along with .
Brilliant!
Change:
(error-handling). Once a receiver advertises a stream limit using the MAX_STREAMS <del> frame, advertising a smaller limit has no effect.  A receiver MUST ignore any MAX_STREAMS frame that does not increase the stream limit. </del> <ins> frame, advertising a smaller limit has no effect.  MAX_STREAMS frames that do not increase the stream limit MUST be ignored. </ins> As with stream and connection flow control, this document leaves implementations to decide when and how many streams should be

Discussion:
Rather than saying who ignores MAX_STREAMS, we can just that it is ignored.
has the following requirement: frame, advertising a smaller limit has no effect. A receiver MUST ignore any MAXSTREAMS frame that does not increase the stream limit. I believe this should be: frame, advertising a smaller limit has no effect. A sender MUST ignore any MAXSTREAMS frame that does not increase the stream limit. This would be in line with the similar requirements for MAXSTREAMDATA and MAXDATA in : is not an error to advertise a smaller limit, but the smaller limit has no effect. [...] A sender MUST ignore any MAXSTREAMDATA or MAXDATA frames that do not increase flow control limits.
I believe the sentence was intended to read: "A receiver(of the frame) MUST ignore any MAX_STREAMS frame that does not increase the stream limit."
Using "receiver" in this context is confusing, maybe it could just be replaced by "endpoint": frame, advertising a smaller limit has no effect. An endpoint MUST ignore any MAX_STREAMS frame that does not increase the stream limit. Or just take the language from : ignored.
Yeah, this is the right fix.
Change:
server through the proxy. The following example shows an IP flow forwarding setup, where a <del> client requests to establish a forwarding path to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </del> <ins> client requests to establish a forwarding tunnel to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </ins> The following example shows a proxied UDP listen flow, where a client receives can receive UDP packets via the proxy, and can send to any

Discussion:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.
Change:
other packet number spaces with in-flight data, coalescing packets if possible. <ins> If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay. </ins> When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent.

Discussion:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?
Change:
be a result of applying the child segment "[<selectors>]" to the node "Di". <del> The result of the descendant selector is the concatenation of "R1", ..., "Rn" (in that order). </del> <ins> For each node in the input nodelist, the result of the descendant segment is the concatenation of "R1", ..., "Rn" (in that order). These results are then concatenated in input nodelist order to form the result of the segment. </ins> So a descendant segment drills down one or more levels into the <del> structure of the input value. </del> <ins> structure of each input value. </ins> 2.7.2.3.

Discussion:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.
Change:
10.3. <ins> The account recovery processes described in account-recovery allow authorization to be transferred from one account key to another, in case the former account key pair's private key is lost.  ACME needs to prevent these processes from being exploited by an attacker to hijack the authorizations attached to one key and assign them to a key of the attacker's choosing. Recovery takes place in two steps: 1.  Provisioning recovery information (contact or recovery key) 2.  Using recovery information to recover an account The provisioning process needs to ensure that only the account key holder ends up with information that is useful for recovery.  The recovery process needs to assure that only the (now former) account key holder can successfully execute recovery, i.e., that this entity is the only one that can choose the new account key that receives the capabilities held by the account being recovered. Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure that the message is only available to the legitimate owner of the contact address.  Otherwise, a passive attacker could see the link and click it first, or an active attacker could redirect the message. If the server requires a user to respond to a message sent to a contact address containing a secret value, then the contact channel will need to ensure that an attacker cannot observe the secret value and spoof a message from the contact address. In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. 10.4. </ins> As a protocol run over HTTPS, standard considerations for TCP-based and HTTP-based DoS mitigation also apply to ACME.

Discussion:
This reverts commit 5ea8bb3afe51fa14b34593341b895e0262b454ca, reversing changes made to 278c6e8ab49e3013708cbf544c76df868973635f.
Change:
defines the concepts that are used by both the API and implementation documents.  The Preconnection allows applications to configure Connection Properties, and the Connection represents <del> an object that can be used to send and receive Messages.  A connection is a local operation that serves to simplify the local send/receive functions and to filter the traffic for the endpoint. This might (as in TCP) or might not (as in UDP) represent an end- to-end protocol connection across the network path. </del> <ins> an object that can be used to send and receive Messages. A Connection is an abstraction that represents the communication. If the transport services interface selects a protocol such as TCP for the communication, a Connection will correspond to an underlying protocol connection.  If however a protocol such as UDP is selected, the Connection remains an abstraction at the end points. </ins> 1.3.

Discussion:
Added a couple of sentences to Arch that are hoped to early introduce that connections are things in the API, not aretfacts of the transport protocol instances. Different to, but related to an issue for the description in API.
"A is an abstraction that represents the communication. If the transport services interface selects a protocol such as TCP for the communication, a will correspond to an underlying protocol connection. In the other hand, if a protocol such as UDP is selected, the remains an abstraction in the end points and doesn't correspond to explicit protocol state" ?
NAME : Could you live with the update in this PR?
yes, I think so (assuming I'm reading the diff right)
Change:
document signing. Term of "Document Sign" in this document is digitally sign contents <del> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by </del> <ins> that are consumed by people.  To be more precise, contents are intended to be shown to person with printable or displayable form by </ins> means of services or software, rather than processed by machines. 3.1.

Discussion:
there was two more remaining human.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.
Change:
However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and hash function. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS <del> 1.2, and thereby avoid cross-protocol collisions. </del> <ins> 1.2, and thereby avoid cross-protocol collisions.  Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. </ins> <del> 7. </del> <ins> 8. </ins> This is a WIP draft and has not yet seen significant security analysis. <del> 8. </del> <ins> 9. </ins> DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as

Discussion:
Importantly, add details regarding incremental deployment, and clarify label values for non TCP-based variants of TLS.
Fixed in .
Fixed in .
Both endpoints must adopt importers for interoperability's sake.
Fixed in .
"TLS 1.3 supports pre-shared key s/resumption/authentication"
Fixed in .
Change:
entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight. <ins> Note also that the client can disable compatible version negotiation by only including the Chosen Version in the Other Versions field of the Version Information Transport Parameter. </ins> 5. During the handshake, endpoints will exchange Version Information,

Discussion:
After pushback from NAME I think this covers the main point with a whole lot less text.
As discussed in URL, there are various levels of partial support for this standard, different for client and server, and there ought to be normative language around these capabilities. There are certain modes that MUST be supported along with multiple versions, and others that are just performance improvements. AFAICT, for any server that supports >1 versions, there are two possible levels of support: Send the TP and support incompatible negotiation Support compatible negotiation For a client, it's more complicated: NAME proposes: No support: do not the send nor parse the TP. If you get a VN packet, fail the QUIC connection Downgrade prevention only: send the TP with only one other version, also parse and validate the TP. If you get a VN packet, fail the QUIC connection. This protects against intermediaries that are rewriting the version field on Initial packets. In v1/v2, these attacks will be detected by the authenticated version field in subsequent handshake packets, but that is not generalizable to all versions of QUIC. Compatible only: downgrade prevention and be prepared to accept an upgrade Incompatible only: advertise only one version, so there's downgrade prevention when trying again with new version after a VN packet. Full: downgrade prevention, compatible VN and incompatible VN
LGTM