jiebi/CodeConvo huggingface dataset:
Change:
data (as defined in asd) and provided as trigger parameter. The enhancements of the YANG module for the ietf-voucher-request with <del> these new leaves are defined in voucher-request-prm-yang. </del> <ins> these new leaves are defined in RFC8366bis. </ins> The PVR is signed using the pledge's IDevID credential contained as x5c parameter of the JOSE header.

Discussion:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.
Change:
WT_MAX_STREAM_DATA frames contain the following fields: <del> Stream ID: The stream ID of the affected WebTransport stream, encoded as a variable-length integer. </del> <ins> The stream ID of the affected WebTransport stream, encoded as a variable-length integer. </ins> <del> Maximum Stream Data: A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes. </del> <ins> A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes. </ins> All data sent in WT_STREAM frames for the identified stream counts toward this limit.  The sum of the lengths of Stream Data fields in

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
window of 10 times the maximum datagram size (max_datagram_size), limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, <del> increasing the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. </del> <ins> increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.

Discussion:
and the 20-byte overhead too. (If this is superseded, that's cool. Low hanging fruit...)
Éric Vyncke said:
Change:
its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has <del> not received a HANDSHAKE_DONE frame. </del> <ins> not received a HANDSHAKE_DONE frame.  If Handshake keys are available to the client, it MUST send a Handshake packet, and otherwise it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. A client could have received and acknowledged a Handshake packet, causing it to discard state for the Initial packet number space, but not sent any ack-eliciting Handshake packets.  In this case, the PTO is set from the current time. </ins> 5.2.3.

Discussion:
This is what the pseudocode says, but I couldn't find anywhere in the text that clarified that if there were no ack-eliciting packets to arm PTO from, use Now().
Change:
Servers' behavior may be subject to other conditions like the one shown in the example from service-limit. <del> A client MUST validate the RateLimit fields before using them and check if there are significant discrepancies with the expected ones. This includes a RateLimit-Reset field moment too far in the future (e.g. similarly to receiving "Retry-after: 1000000") or a service- limit too high. </del> <ins> A client is responsible for ensuring that RateLimit field values returned cause reasonable client behavior with respect to throughput and latency (see sec-resource-exhaustion and sec-dos). </ins> A client receiving RateLimit fields MUST NOT assume that future responses will contain the same RateLimit fields, or any RateLimit

Discussion:
no normative language in sec- -
This doesn't seem practical; how would validation help? What are they looking for?
For example, implementations are expected to validate received values like Or The same goes for other fields, e.g. A similar practice, in a different context though, is mentioned in URL Hints are welcome!
Considering the objective of the RateLimit headers is to allow a client to avoid being throttled, the consequence of a client ignoring the RateLimit-* headers is just a client getting throttled. If we believe that a client may need to protect itself against malicious values injected into these headers, then I it should be sufficient to give clients the permission to ignore the headers if they believe the values are not reasonable. Suggest wording like: However, considering that processing these headers is optional for a client anyway, I'm not sure this comment is absolutely necessary.
Part of the problem here is that "valid" is being used in different senses: to indicate that it's a valid Structured Field to indicate that it's semantically valid (e.g., "too big") For the latter, since it's so fuzzy (at least to date), I'd suggest using something like "reasonable" instead.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
Change:
The response to the TLS SNI challenge simply acknowledges that the client is ready to fulfill this challenge. <del> The string "tls-sni-01" The "token" value from the authorized key object in the challenge. </del> <ins> The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. </ins> <del> On receiving a response, the server MUST verify that the "token" value in the response matches the "token" field in the authorized key object in the challenge.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge </del> <ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </ins> Given a Challenge/Response pair, the ACME server verifies the client's control of the domain by verifying that the TLS server was

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
to determine a suitable Local Endpoint), as well as all properties necessary for candidate selection. <del> The Initiate() Action consumes the Preconnection.  Once Initiate() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> The Initiate() Action returns a Connection object.  Once Initiate() has been called, any changes to the Preconnection MUST NOT have any effect on the Connection.  However, the Preconnection can be reused, e.g., to Initiate another Connection. </ins> Once Initiate is called, the candidate Protocol Stack(s) may cause one or more candidate transport-layer connections to be created to

Discussion:
Fixed text in the API draft to allow reusing Preconnections as discussed in . However, changes to the Preconnection MUST NOT have any effect on the Connections or Listeners created beforehand - I think normative language is useful here to really highlight this possible pitfall. I omitted any note on deep copy as that's just a way to implement this.
Great catch, it makes me wonder why we had closed issue ? Thanks for doing this!Thank you - fix achieved with minimal changes ;-)
Change:
operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. <ins> Validating the ESNIKeys structure additionally validates the public name.  This validates any retry signals from the server because the client validates the server certificate against the public name before retrying. </ins> 7.2.8. This design has no impact on application layer protocol negotiation.

Discussion:
(WG email coming shortly.) ESNI has different compatibility characteristics than most TLS extensions. It involves client state, and encrypting the SNI makes the ClientHello unusable for servers that do not have the key or do not implement ESNI. This breaks common rollout and rollback strategies and places strong requirements on DNS/server consistency. This makes deploying ESNI risky for servers. This change aims to reduce these deployment risks. ESNI is much more useful if widely deployed. Moreover, if ESNI is unreliable due to complex requirements on the server, clients will be disincentivized to implement it. The DNS/server consistency requirements also disincentivize rotating keys (section 7.2.5). This change introduces the notion of a "public name" which allows the client to receive authenticated signals from the server that the ESNIKeys are out of sync, so clients can safely repair key mismatches. It also aligns with existing server behavior before ESNI, so partial rollouts and rollbacks can also be handled. The fix for the latter also handles MITM scenarios, replacing the existing client recommendation: The public name notion fixes a bug in that text: an attacker could disable ESNI on all servers, given the existence of any such server.
And, as I write this, I realize I forgot to deal with Stephen's comment on the thread about the middlebox stuff! It's quite late here, so I will reword that tomorrow morning.
Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.
How to understand the reliability of the public key from server?
I see that I missed something about disabling. I think that this could be a lot more explicit about the three primary cases that I talk about in the comments below.Looks mostly good, but added some nits and clarification questions.
Change:
issuance public key based on the blind RSA signature scheme BLINDRSA. This document does not cover the Privacy Pass architecture, including <del> choices that are necessary for ensuring that client privacy leaks. This information is covered in ARCHITECTURE. </del> <ins> choices that are necessary for deployment and application specific choices for protecting client privacy.  This information is covered in ARCHITECTURE. </ins> 2.

Discussion:
This should presumably say "for ensuring that client privacy does not leak" or "to prevent client privacy leaks."
Change:
assumptions that might be made based on knowledge of QUIC version 1; these do not apply to every version of QUIC. <del> 2. </del> <ins> 3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
Gorry thought that it might be worth saying what QUIC is first. I agree. Tiny tweaks to the intro to allow for the change. Including a new title.
Issue raised by NAME via :
I like it. I'll see what that looks like. I have read Version-Independent Properties of QUIC (-30) in the WGLC and think this is ready, I found 3 editorial comments that might need consideration after the WGLC: (i) I suggest the introduction for this spec starts abruptly. Is it worth considering one sentence top explain what QUIC is, in case someone read this document first? - One possible solution could be to move the text in section 3 to section 1? (To me, the section 3 text does not need to come after the Section 2 definitions.) (ii) Does this read better with /for/ moved within the sentence? OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./ NEW:/At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended./ (iii) I see the desire to emphasise the “NOT”, but I query if this is correct usage of a RFC2119 keyword in Appendix A?: /The following statements are NOT guaranteed to be true for every QUIC version:/ Best wishes, Gorry
Change:
TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently.  The TLS standard, however, does <del> not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. </del> <ins> not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. </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:
Some suggested nits for s1: adding a semi-colon and swapping two whichs for thats.
Change:
A push resource is used by the application server to request the delivery of a push message (see send).  A link relation of type <del> "urn:ietf:params:push" is used to identify a push resource. </del> <ins> "urn:ietf:params:push" identifies a push resource. </ins> A push message resource is created to identify push messages that have been accepted by the push service.  The push message resource

Discussion:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.
Change:
for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. <ins> DTLS 1.3 uses network byte order (big-endian) format for encoding messages based on the encoding format defined in TLS13 and earlier (D)TLS specifications. </ins> The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS 1.3.

Discussion:
Francesca says I am uncertain whether this document is the right place to place restrictions on IANA for this purpose beyond what has already been done elsewhere. Maybe there is a chance to do something in the TLS 1.3 update.
I added some text to the PR.
Since got merged, should this issue be closed now?
Thank you for this document. Please find some minor comments below. Francesca section 2. Conventions and Terminology FP: Please spell out that network byte order (most significant byte first) is used throughout the document. Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. FP: It would be good to mention retransmission max times here. /+----------------+ /+-------+--------+ The value for the "DTLS-OK" column is "Y". IANA is requested to reserve the content type range 32-63 so that content types in this range are not allocated. FP: IANA is asked to reserve 32-63, but I could not see any explanation for that. I would like to see it justified in section 4.1 or in the respective IANA section. fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. FP: First time PMTU appears, please expand and add reference. performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular: FP: I think this is missing areference to RFC 8201 since IPv6 is mentioned below. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions.

FP: This seems important enough that it should be highlighted for the experts reviewing the registration. I see that URL has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447? zero length vector (i.e., a single zero byte length field). FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a zero-valued single byte length field)" flow shown in Figure 11 if the client does not send the ACK message FP: s/11/12
Addressed in
LGTM with some suggested nits
Change:
Privacy Pass is an architecture for authorization based on privacy- preserving authentication mechanisms.  Typical approaches for <del> authorizing clients, such as through the use of long-term cookies, are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information.  These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </del> <ins> authorizing clients, such as through the use of long-term state (cookies), are not privacy-friendly since they allow servers to track clients across sessions and interactions.  Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the client is an authorized user or has completed some prior challenge, clients present unlinkable proofs that attest to this information. These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued. </ins> At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance.  The redemption protocol,

Discussion:
The interaction model here doesn't really need to use HTTP as far as I can tell. Obviously, the specific protocols need to be more concrete, but the architecture works without specifically saying that the interactions use HTTP. The overview specifically mentions HTTP only with respect to the Client-Origin interactions, not other interactions, but I can't see how this is necessary.
No, it doesn't need to use HTTP. The auth scheme document that instantiates the challenges and redemption does use HTTP, but other mechanisms can be used.
I'm OK de-emphasizing HTTP in the architecture if it helps simplify the presentation. Beyond it overly restrictive, was there another reason that led to this issue, NAME
Only that I know that this has obvious applications beyond HTTP and the architecture has no direct need to use it.
Request/response is still a bit implying HTTP, but I'm OK with this change.
Change:
Importance: Extra <del> When we receive one or more UDP-level datagrams from the socket. </del> <ins> When one or more UDP-level datagrams are received from the socket. </ins> This is useful for determining how datagrams are passed to the user space stack from the OS.

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
section is the algorithm defining which of these options to try, when, and in what order. <del> During Candidate Gathering, an implementation first excludes all protocols and paths that match a Prohibit or do not match all Require properties.  Then, the implementation will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </del> <ins> During Candidate Gathering, an implementation prunes and sorts branches according to the Selection Property preferences (Section 6.2 of I-D.ietf-taps-interface.  It first excludes all protocols and paths that match a Prohibit property or do not match all Require properties.  Then it will sort branches according to Preferred properties, Avoided properties, and possibly other criteria. </ins> 4.1.

Discussion:
Quoting from the end of the Section 4 overview, the earliest point in the Implementation Draft where Preference Levels are explicitly mentioned: While the capitalization of "Prohibit" and "Require" does somewhat help to indicate their role as a special term, the sentence does not scan particularly well to any reader that is yet unfamiliar with the notion of Preference Levels from the API draft. At the very least it would help to better contextualize the sentence. Suggestion 1: It could also help to not explicitly refer to any Preference Levels yet. Suggestion 2: This could be sufficient for the Section 4 overview, since Section 4.1.3 "Sorting Branches" later goes into more detail about the different properties and their handling, even if the wording is a bit terse:
Change:
that use algorithm combinations that cannot be currently used with TLS. <del> 4.4.1.3. </del> <ins> 4.4.1.4. </ins> In general, detailed certificate validation procedures are out of scope for TLS (see RFC5280).  This section provides TLS-specific

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
3.2.1. <del> Each instance of User Equipment interacting with the Captive Network MUST be given an identifier that is unique among User Equipment interacting at that time. </del> <ins> The Captive Network MUST associate the User Equipment with an identifier that is unique among the User Equipment that are interacting with the Captive Network at that time. </ins> Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures

Discussion:
Fixes issue
Benjamin writes, I suggest: >perhaps "given" is the wrong term here? Should we rephrase to
Looks good. Thanks!