jiebi/CodeConvo huggingface dataset:
Change:
If no SenML Records match, empty SenML Pack (i.e., array with no elements) is returned as a response. <del> All other Fetch Record fields than name, base name, time, base time, unit, and base unit MUST be ignored. </del> <ins> Fetch Records MUST NOT contain other fields than name, base name, time, base time, unit, and base unit.  Implementations MUST reject and generate an error for a Fetch Pack with other fields. </ins> 3.2.

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
Template: <del> Code: The label to be included in the URN for this error, </del> <ins> Type: The label to be included in the URN for this error, </ins> following "urn:ietf:params:acme:" Description: A human-readable description of the error Reference: Where the error is defined <del> Initial contents: The codes and descriptions in the table in errors </del> <ins> Initial contents: The types and descriptions in the table in errors </ins> above, with the Reference field set to point to this specification. 8.6.4.

Discussion:
Usage of is slightly confusing when we are not using int-enumerated error codes. RFC 7807 also refers to the problem document error types as and the field is called so this seems to make the most sense.
Change:
QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR. <ins> Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error. For QUIC version 1, version negotiation errors are signaled using a transport error of type VERSION_NEGOTIATION_ERROR; see iana-error. </ins> If the Version Information was missing, the endpoints MAY complete the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the <del> client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </del> <ins> client MUST close the connection with a version negotiation error. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other

Discussion:
Defining an error code for QUICv1 is good, but I think that you need to frame this differently. It probably needs to be framed in terms of a requirement on all QUIC versions. So rather than: You might say something like:
I like this. Can you make it a PR?
Change:
Note that maxLength does not guarantee that the application will receive that many bytes if they are available; the interface may return ReceivedPartial events with less data than maxLength according <del> to implementation constraints. </del> <ins> to implementation constraints.  Note also that maxLength and minIncompleteLength are intended only to manage buffering, and are not interpreted as a reciever preference for message reordering. </ins> 8.2.

Discussion:
It should be made more clear in what order queued receives are considered, i.e. what happens if an application calls Receive(minIncompleteLength=20), then calls Receive(minIncompleteLength=1). What now happens if e.g. 10 bytes of data arrive? Will the second receive only be considered after the first has been fulfilled?
It would seem natural to me that enqueuing is what it is - i.e., saying once "I can receive blocks of at least 20 bytes" cannot be undone. So, if the sequence is: 1) Receive(minIncompleteLength=20) 2) Receive(minIncompleteLength=1) 3) 10 bytes arrive ... then the first Receive call should be the one that matters, and the 10 bytes would have to wait until another 10 bytes arrive before the second Receive call can be processed. I think that NAME should add a clarifying sentence because his implementation probably already does it in one way or another.
Perhaps its not such a big issue, but I think this would take the option away from application developers to have an OR option for receives. For example, an application would have no way to say that it wants to receive either something with minIncompleteLength 100 or MaxLength 10. I also think there might be some confusion when it comes to requiring message ordering. For example: Application calls Receive(maxLength=10) Application calls Receive(maxLength=20) Message with length 20 arrives Message with length 10 arrives Application get received callback for message with length 10 Application get received callback for message with length 20 For the application it now seems that the message with length 10 arrived before the one with length 20 even though that is not the case.
Change:
Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmle </ins> Macintosh file type code(s): none

Discussion:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...
Change:
4.1. In this model, the Origin, Attester, and Issuer are all operated by <del> the same entity, as shown in the figure below. </del> <ins> the same entity, as shown in fig-deploy-shared. </ins> This model represents the initial deployment of Privacy Pass, as described in PrivacyPassCloudflare.  In this model, the Attester,

Discussion:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.
Change:
1.1. <del> The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document.  It's not shouting; when these words are capitalized, they have a special meaning as defined in RFC2119. </del> <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

Discussion:
...addressing NAME
Middlebox vendors (and others as well) used to TCP want to assume that the smallest packet might be ack packets. This is not true in QUIC, and manageabiity draft may want to say something about it.
Thanks for writing this up!
Change:
of I-D.ietf-tls-dtls13.  The EKTKey message and Ack MUST be retransmitted following the rules in Section 4.2.4 of RFC6347. <del> Note: To be clear, EKT can be used with versions of DTLS prior to 1.3.  The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. </del> <ins> EKT MAY be used with versions of DTLS prior to 1.3.  In such cases, the Ack message is still used to provide reliability.  Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have explicit affordances for sending the Ack message in response to an EKTKey message, and for verifying that an Ack message was received. The retransmission rules for both sides are the same as in DTLS 1.3. </ins> If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert.

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
starts, we can convey the same information to the client via "Retry- After", with the advantage that the server can now specify the policy's nominal limit and window that will apply after the reset, <del> ie. assuming the resource exhaustion is likely to be gone by then, so the advertised policy does not need to be adjusted, yet we managed to stop requests for a while and slow down the rest of the current </del> <ins> e.g. assuming the resource exhaustion is likely to be gone by then, so the advertised policy does not need to be adjusted, yet we managed to stop requests for a while and slow down the rest of the current </ins> window. Request:

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS <del> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Ed25519 and Ed448 are signature-only curves defined in CFRG- EdDSA.  Values 0xFE00 through 0xFEFF are reserved for private use. </del> <ins> 186-4 FIPS.186-4. ecdh_x25519 and ecdh_x448 are defined in CFRG- Curves. eddsa_ed25519 and eddsa_ed448 are signature-only curves defined in CFRG-EdDSA.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added.

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce <del> and the hash of a valid TokenChallenge.  For interactive tokens, origins store the nonces of previous TokenChallenge structures in order to validate uniqueness.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  For non-interactive tokens, origins SHOULD implement some form of double spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges. </del> <ins> and the hash of a valid TokenChallenge.  For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges.  For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness. </ins> If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response.

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter <del> of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. </del> <ins> of "; " (ASCII 0x3b, 0x20) before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. </ins> 4.2.2.

Discussion:
The RFC Editor asks:
Along the way, there are two equivalent statements that need to be deduplicated that this change touches: I would suggest collapsing these two into the first statement, but using OPTIONS as an example and keeping the reference into http-core. Or perhaps that should be a question -- is there a difference between asterisk-form and OPTIONS-without-path?
Resolved in .
Change:
retrieve the full response.  This document clarifies that expectation. <del> While not common, real life examples of servers that fail to set TC=1 when glue records are available exist and they do cause resolution failures.  The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC RFC4033, RFC4034, RFC4035 referral response, this behaviour has also been seen with plain DNS responses as well.  The records have been truncated for display purposes.  Note that at the time of this writing, this configuration has been corrected and the response correctly sets the TC=1 flag. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
Clarify glue, slightly reorder.
Merging - as mentioned in email, I will also add a more typical case of sibling glue (that doesn't involve cross zone and circular dependency). PR forthcoming ...
Change:
The application should be notified whenever a Message or partial Message has been consumed by the Protocol Stack, or has failed to <del> send.  The meaning of the Message being consumed by the stack may vary depending on the protocol.  For a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver.  For a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer. </del> <ins> send.  The time at which a Message is considered to have been consumed by the Protocol Stack may vary depending on the protocol. For example, for a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver.  For a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer.  The time at which a message has failed to send is after the Protocol Stack or the Transport Services implementation itself has not successfully sent the entire Message content or partial Message content on any open candidate connection; this may depend on protocol-specific timeouts. </ins> 5.1.3.

Discussion:
I stared at this sentence for a while before I thought I'd made sense of it. PR forthcoming but I think this might need a little discussion.
lgtm
Change:
One of the revocation reasonCodes defined in Section 5.3.1 of RFC5280 to be used when generating OCSP responses and CRLs.  If <del> this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The </del> <ins> this field is not set the server SHOULD omit the reasonCode CRL entry extension when generating OCSP responses and CRLs.  The </ins> server MAY disallow a subset of reasonCodes from being used by the user.  If a request contains a disallowed reasonCode the server MUST reject it with the error type

Discussion:
As recommended by . Thanks to for the catch.
NAME I believe you need write, admin, or owner permissions on the repo for a "changes requested" review to show up this way in the GH UI.
(Merging myself because it's the real author is NAME I'm just the scribe)
Could you please change the spelling? (Why won't I get a "Changes requested" with red marker?) Hello, https://ietf-wg-URL states: If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs. Yet URL says the opposite: the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. Could this be reworded somehow? It would make sense to store `0' in a database but later don't add a CRLReason extension / ASN.1 field. Cheers, Jörn
Change:
The client MAY either omit the "server_name" extension or provide an innocuous dummy one (this is required for technical conformance with <del> RFC7540; Section 9.2.) </del> <ins> RFC7540; Section 9.2.).  The client MUST NOT send a "cached_info" extension RFC7924 with a CachedObject entry whose CachedInformationType is "cert". </ins> If the server does not negotiate TLS 1.3 or above, then the client MUST abort the connection with an "unsupported_version" alert.  If

Discussion:
Addresses .
An adversary who observes the certificate fingerprint could confirm certificates previously fetched by a ESNI-compatible client.
Fixed in .
Change:
could be calling the AS just to get direct user information and have no need to get an access token to call an RS. <ins> 1.5.1. The following diagram provides a general overview of GNAP, including many different optional phases and connections.  The diagrams in the following sections provide views of GNAP under more specific circumstances. </ins> (A) The end user interacts with the client instance to indicate a need for resources on behalf of the RO.  This could identify the RS the client instance needs to call, the resources needed, or the

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
This event's main goal is to prevent a large proliferation of specific purpose events (e.g., packets_acknowledged, <del> flow_control_updated, stream_data_received).  We want to give implementations the opportunity to (selectively) log this type of signal without having to log packet-level details (e.g., in packet_received).  Since for almost all cases, the effects of applying a frame to the internal state of an implementation can be inferred from that frame's contents, we aggregate these events in this single "frames_processed" event. </del> <ins> flow_control_updated, stream_data_received).  Implementations have the opportunity to (selectively) log this type of signal without having to log packet-level details (e.g., in packet_received).  Since for almost all cases, the effects of applying a frame to the internal state of an implementation can be inferred from that frame's contents, these events are aggregated into this single "frames_processed" event. </ins> Note: This event can be used to signal internal state change not resulting directly from the actual "parsing" of a frame (e.g., the

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:
requesting that the client instance present specific additional information, such as a user's credential or an assertion <del> contacting a RO through an out-of-band mechanism, such as a push </del> <ins> contacting an RO through an out-of-band mechanism, such as a push </ins> notification contacting an auxiliary software process through an out-of-band

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
this architecture. A conveyance protocol that provides authentication and integrity <del> protection can be used to convey unprotected Evidence, assuming the following properties exists: </del> <ins> protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).  Appropriate conveyance of unprotected Evidence (e.g., I-D.birkholz-rats-uccs) relies on the following conveyance protocol's protection capabilities: </ins> The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the <del> Attesting Environment(s) that collected claims about the Target </del> <ins> Attesting Environment(s) that collected Claims about the Target </ins> Environment(s). All unprotected Evidence that is conveyed is supplied exclusively

Discussion:
I assume this is an escape hatch for unsigned CBOR. But I’m not sure the sentence makes sense… if the conveyance protocol provides protection, then it’s not unprotected evidence? Or is there some other point we’re trying to get at?
"URL to convey Evidence that is otherwise unprotected, relies on the conveyance protocol for the following protections: ..." I think unsigned CBOR (the UCCS draft) is one example of "unprotected Evidence". Maybe we can add a reference pointing to the UCCS draft.
` Maybe we can say "URL to convey Evidence that is otherwise unprotected itself", or "URL to convey Evidence that is otherwise not signed itself"?
Change:
structure: The public key of the account key pair, encoded as a JSON Web Key <del> object RFC7517. </del> <ins> object RFC7517.  This field is not updateable by the client. </ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to

Discussion:
This mitigates confusion about how clients should respond when terms of service change.
Updated based on review. Took out the echoing of the field on subsequent requests, because it makes things simpler and clearer.