jiebi/CodeConvo huggingface dataset:
Change:
Once header protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet.  The next expected packet is the highest received packet <del> number plus one.  For example, if the highest successfully authenticated packet had a packet number of 0xa82f30ea, then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. Example pseudo-code for packet number decoding can be found in sample-packet-number-decoding. </del> <ins> number plus one.  Pseudo-code and an example for packet number decoding can be found in sample-packet-number-decoding. </ins> 17.2.

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:
containing these properties can be passed to the Send Action.  For other uses of the message context, see msg-ctx. <del> Note that message properties are per-Message, not per-Send if partial </del> <ins> Note that Message Properties are per-Message, not per-Send if partial </ins> Messages are sent (send-partial).  All data blocks associated with a single Message share properties specified in the Message Contexts. For example, it would not make sense to have the beginning of a

Discussion:
This also addresses two inline [EDITOR's NOTE] items. One was about the per-message override capacity profile being inconsistent with the other one; this was solved by removing details, such that the other one defines the possible choices. Another was about selection vs. connection properties, with broken text. There was no need to add the references as the editor's note says, I thought.
this LGTM, thanks!
Change:
simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <ins> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </ins> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
of the resulting subscription to application servers that are able to provide proof of possession for the corresponding private key. <del> This public key is then added to the request to create a push subscription as described in key.  The Crypto-Key header field includes exactly one ECDSA public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url RFC7515.  The example in ex-restrict shows a restriction to the key used in ex-push: </del> <ins> The public key is then added to the request to create a push subscription.  The push subscription request is extended to include a body.  The body of the request is a JSON object as described in RFC7159.  A "vapid" member is added to this JSON object, containing the public key on the P-256 curve, encoded in the uncompressed form X9.62 and base64url encoded RFC7515.  The MIME media type of the body is set to "application/json". The example in ex-restrict shows a restriction to the key used in ex- push.  Extra whitespace is added to to meet formatting constraints. </ins> An application might use the Web Push API API to provide the user agent with a public key.

Discussion:
I know that it's the devil, but JSON is the obvious choice here.
Why would it be obvious ? application/x-www-form-urlencoded or a request parameter ?
It's an obvious choice given the proprietary precedence in the industry. I can't really judge the appropriateness of using JSON as opposed to an alternative -- this change LGTM assuming it is. Since the UA chooses the PS, there is no need for encryption. JSON provides good extensibility for additional (proprietary) data that may have to be transmitted over this channel.
At least it's not xml... I don't mind json - just didn't think it is so obvious. It does open an important question: will the user be allowed to pass more information to the push service (voluntarily) ? But +1 on this change.
Probably, but I don't want to think about that just yet :)
Change:
One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens <del> without interacting with the Issuer directly. </del> <ins> offline or otherwise without interacting with the Issuer directly. </ins> Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients.

Discussion:
We current state this as the requirement: This could be misread in that we do allow forgeries when interacting with the Issuer directly. Clearly that's not the intent, so let's fix this.
Change:
An HTTP message (request or response) consists of: <del> the message header (see RFC7230, Section 3.2), sent as a single </del> <ins> the message header (see Section 3.2 of RFC7230), sent as a single </ins> HEADERS frame (see frame-headers), <del> optionally, the payload body, if present (see RFC7230, Section 3.3), sent as a series of DATA frames (see frame-data), </del> <ins> optionally, the payload body, if present (see Section 3.3 of RFC7230), sent as a series of DATA frames (see frame-data), </ins> <del> optionally, trailing headers, if present (see RFC7230, Section 4.1.2), sent as a single HEADERS frame. </del> <ins> optionally, trailing headers, if present (see Section 4.1.2 of RFC7230), sent as a single HEADERS frame. </ins> A server MAY send one or more PUSH_PROMISE (see frame-push-promise) or DUPLICATE_PUSH (see frame-duplicate-push) frames before, after, or

Discussion:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1
Change:
2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019 <del> Chai-2019 Grover-2019 Singh-2019. </del> <ins> Chai-2019 Grover-2019 Singh-2019.  SNI blocking against QUIC traffic has been first observed in Russia in March 2022 Elmenhorst-2022. </ins> 4.2.3.2.

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
1. <del> The TLS protocol RFC8466 includes several points of extensibility, </del> <ins> The TLS protocol RFC8446 includes several points of extensibility, </ins> including the list of cipher suites and the list of extensions.  The values in these lists identify implementation capabilities.  TLS follows a model where one side, usually the client, advertises

Discussion:
Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL
Change:
some mitigations require coordination between the client and server. These mitigations are out-of-scope for this specification. <del> 10.8.5. </del> <ins> 10.9.5. </ins> This design is not forward secret because the server's ECH key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 10.8.6. </del> <ins> 10.9.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers.  The client

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
An implementation that receives an invalid tls_flags extension MUST terminate the TLS handshake with a fatal illegal_parameter alert. <ins> 3.1. The 0-RTT handshake, defined in section 2.3 of RFC8446, has a ClientHello message, a ServerHello message, and an EncryptedExtensions message.  Those can include the tls_flags extension just as they can in a regular handshake. Future flag extensions MUST define their interaction with 0-RTT, just as other extensions are required to. </ins> 4. IANA is requested to assign a new value from the TLS ExtensionType

Discussion:
To solve issue
RFC8446 4.2.10 requires that: This extension does not (as far as I can see) do that. I think the text in tls-flags should prevaricate on this topic, because really it's an encoding framework for trivial extensions (that themselves need to define their interaction with 0-RTT.)
Created a PR. Let me know if this is satisfactory. URL
NAME NAME assume this one can be closed based on being merged?
Change:
13.1.1. <del> To avoid creating an indefinite feedback loop, an endpoint MUST NOT send an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet.  The endpoint MUST however acknowledge packets containing only ACK or PADDING frames when sending ACK frames in response to other packets. </del> <ins> An endpoint MUST NOT send more than one packet containing only an ACK frame per received packet that contains frames other than ACK and PADDING frames.  An endpoint MUST NOT send a packet containing only an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet.  This prevents an indefinite feedback loop of ACKs.  The endpoint MUST however acknowledge packets containing only ACK or PADDING frames when sending ACK frames in response to other packets. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING

Discussion:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.
Change:
(see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the order <del> resource. </del> <ins> resource.  Clients SHOULD NOT make any assumptions about the sort order of "identifiers" or "authorizations" elements in the returned order object. </ins> Once the client believes it has fulfilled the server's requirements, it should send a POST request to the order resource's finalize URL.

Discussion:
This PR clarifies that a client SHOULD NOT assume that the "identifiers", "authorizations" or "challenges" arrays returned in various server response objects are sorted. This PR also clarifies that while some have a 1:1 relationship between order identifiers and order authorizations this isn't a universal truth. This resolves URL
NAME Is 6 days without any feedback on-list sufficient to merge?
On the reuqest, there are two arrays returned, one for the and one for the . However, there is no order specified in ACMEv2. As two arrays are returned (and no hash), this might imply that the order of matches the order of . This is not specified right now. Having this specified would allow clients to know in advance for which identity they are requesting the authorization challenge before requesting the URL, e.g. for better error reporting. Also ok would be to just explicitly specify that the order is not guaranteed or the number of entries is not guaranteed to match in order to make it more clear to developers. cf. URL
From the outcome of the linked conversation, we should just specify that no specific order is guaranteed.
:+1: - URL I will start a mailing list thread since this is a new SHOULD NOT.
Looks good to me; let's wait a little bit for feedback on-list.
Change:
clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. <ins> TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for

Discussion:
The text is good however I don't understand its placement in the draft fully. Shouldn't this paragraph go into the previous section or even in an own section? I know the issue, that this PR is addressing, was about DDoS but if we want to have it in the DDoS section we need probably some more words explaining how Retry should be used in this case. Currently it comes a bit out of nothing and interrupts the reading flow of the rest of the text...
I am not really sure at all that the existing DDoS guidance is good advice; we have a somewhat more robust plan in quic-lb, which perhaps we should reference?
for that matter, the Retry packet does not make an appearance in this section at all, which seems like an oversight.
Yes to both. Can you provide an PR?
Yes, please assign this issue to me.
Change:
completion; i.e. when the Message was not sent before its Lifetime (see msg-lifetime) expired.  This is separate from SendError, as it is an expected behavior for partially reliable transports.  The <del> Expired Event contains an implementation-specific reference to the Message to which it applies. </del> <ins> Expired Event contains a reference to the Message to which it applies. </ins> 7.3.3.

Discussion:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.
Change:
Name: Name of the issuance protocol <ins> Token Structure: The contents of the Token structure TokenChallenge Structure: The contents of the TokenChallenge structure </ins> Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable

Discussion:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.
Change:
This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various <del> error conditions. </del> <ins> error conditions.  This implies HTTP status code 400 Bad Request unless explicitly specified otherwise. </ins> 4.

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged