jiebi/CodeConvo huggingface dataset:
Change:
CNAME Canonical name Child <ins> Class </ins> Class independent Closest encloser Closest provable encloser

Discussion:
I like the additional wording. I'll add it and take the question to the chairs to take to the WG.
Good catch on "DNS over TLS" -> "DNS over HTTPS". I didn't go with "DNS Queries over HTTPS" because it doesn't really describe the protocol.
Simple mistake: "DNS over TLS" should be "DNS over HTTPS" at line 1040. Or "DNS Queries over HTTPS" may be better because it is a draft name.If we're going to add class here, then I think (1) we need to go back to the WG and (2) we need to add something: "In practice, the class for nearly every query is IN. There are some queries for CH, but they are usually for the purposes of information about the server itself rather than for a different type of address" I wrote a doc some time ago attempting to deprecate class, because of the way it keeps popping up as though it is viable.
Change:
[17] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz <del> [18] https://tools.ietf.org/html/rfc8152#section-11 </del> <ins> [18] https://tools.ietf.org/html/rfc6749#section-5.2 </ins> <del> [19] https://tools.ietf.org/html/rfc8152#section-11.2 </del> <ins> [19] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 5.7.3 </ins> <del> [20] https://tools.ietf.org/html/rfc6749#section-5.2 </del> <ins> [20] https://tools.ietf.org/html/rfc8152#section-11 </ins> <del> [21] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz#section- 5.7.3 </del> <ins> [21] https://tools.ietf.org/html/rfc8152#section-11.2 </ins> [22] https://tools.ietf.org/html/rfc4279#section-2

Discussion:
The normative specification of how to use a salt for deriving a symmetric key to use between C and RS is changed into an example using cnf = COSE_key.
The text claims to present an example, but contains a lot of normative language (probably heritage from when it was normative text). I don't think that goes well together and it leaves the reader with an unclear feeling as to where the example ends and normative text resumes. I would suggest to remove all normative language from the example and make it clear at which point the example ends and normative text resumes. I do like the idea to present this mechanism as an example however, since it is really up to the applications how they retrieve a key based on a key identifier, and I believe derivation is a fine example here.
In 9624eea the normative text is removed from the example and the example is moved to the end of the section to separate the example from the rest of the text.
Just to clarify if my understanding is correct: The proposal says that if the access token contains but no , the RS needs to derive K{C, RS} in some application-specific way?
Yes, with the interpretation that "derive" could mean "look up", "retrieve" etc. I.e. the RS needs to know how to obtain k{C, RS} from kid. Can the text be further clarified?
No, this is what I also think that the text says. Thus, I am fine merging this PR.
Since two co-authors are OK I merge this now. Further comments can be added on the master branch.
Change:
server overwrites the payload of the "encrypted_client_hello" extension with the following string: <del> As above, the payload of "encrypted_client_hello" is expected to be a "ClientECH" with "ClientECH.type" is "inner".  If this is not the case, the backend server MUST abort the handshake with an "illegal_parameter" alert. Note that, in case of HelloRetryRequest, the backend server confirms ECH acceptance twice: first In HelloRetryRequest, as described here; and then in the subsequent ServerHello, as described above. </del> <ins> In the subsequent ServerHello message, the backend server sends the accept_confirmation value as described in backend-server. </ins> 8.

Discussion:
The requirement to check the ClientHello for an inner ClientECH doesn't make sense because the entire section is already conditioned by observing an inner ClientECH. Also clarify that the client-facing vs. backend server dispatch happens at the initial ClientHello. Switching roles mid-connection will not work very well.
Change:
The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client <del> selects the version it believes to be best supported from the versions that are compatible with the client's most preferred version.  Without additional information this could mean selecting the oldest version that the client supports. </del> <ins> selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest version that the client supports. </ins> 8.

Discussion:
This draft talks about clients and servers "thinking" and "believing" things. Those verbs don't necessarily apply to protocol implementations, no matter what new frontiers we're exploring in the machine learning space. Might be worth a pass to rephrase these in terms of client or server capabilities and information. "Know" is a little fuzzier, since an endpoint does in fact possess information at certain points in the process.
So... when my computer says "thinking ...", are you saying it's lying to me?
URL
Change:
The Privacy Pass architecture consists of four logical entities - Client, Origin, Issuer, and Attester - that work in concert for token redemption and issuance.  This section describes the purpose of token <del> redemption and issuance and the requirements on the relevant participants. </del> <ins> the redemption and issuance protocols and the requirements on the relevant participants. </ins> The typical interaction flow for Privacy Pass uses the following steps:

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:
encryption process (i.e. detached content) then the value 'nil' is encoded here. <del> contains the recipient information.  The field can have one of three data types: </del> <ins> contains the recipient information.  The field can have one of two data types: </ins> An array of COSE_encrypt elements, one for each recipient. <del> A single COSE_encrypt element, encoded as an extension to the containing COSE_encrypt element, for a single recipient.  Single recipients can be encoded either this way or as a single array element. </del> A 'nil' value if there are no recipients. 4.1.

Discussion:
Following discussions on the mailing list. Removing the ability to have flattened encoding for signers and recipients.
Closes issue
JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar. Current syntax is "recipients : COSEencrypta null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it. Not really that hard to do from a programmers point of view.
Open for group discussion
Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue.
Change:
body. Note that this mechanism is implicitly implemented when the security <del> layer guarantees ordered delivery (e.g.  CoAP over TLS I- D.tschofenig-core-coap-tcp-tls).  This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </del> <ins> layer guarantees ordered delivery (e.g.  CoAP over TLS RFC8323). This is because with each message, any earlier operation can be regarded as concluded by the client, so it never needs to set the Request-Tag option unless it wants to perform concurrent operations. </ins> 3.3.2.

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
In the static allocation method, the configuration agent assigns at least one server ID to each server. <del> When forwarding a packet with a long header and non-compliant DCID, load balancers MUST forward packets with long headers and non- compliant DCIDs using an arbitrary algorithm as specified in arbitrary-algorithm. </del> <ins> When forwarding a packet with a long header and unroutable DCID, load balancers MUST forward packets with long headers and unroutable DCIDs using an fallback algorithm as specified in fallback-algorithm. </ins> 4.3.2.

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:
Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets.  Instance identifier values MUST be unguessable and MUST NOT contain any <del> sensitive information.  Instance identifier values are opaque to the client instance. </del> <ins> information that would compromise any party if revealed.  Instance identifier values are opaque to the client instance. </ins> This non-normative example shows an instance identifier along side an issued access token.

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 7e9a352ebd6b48adb5f0a834a94bd083c38cb53c Inspect the deploy log: Browse the preview:
The text says: protected by the client instance as secrets. Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information. This is weird, because we're saying both that they should be treated as secrets and that they are not sensitive. I would suggest instead: protected by the client instance as secrets. Instance identifier values MUST be unguessable and MUST NOT contain any information that would compromise the AS if revealed.
We're not saying that they're not sensitive, we're saying that they can't contain sensitive information. This is like saying your password is sensitive and it also shouldn't contain your medical record number at your hospital, because that's also a sensitive piece of information. Still I think the wording is an improvement, thanks!
I agree the proposed wording is better, thanks !
Change:
5.2. <del> Similar to sending, Receiving a Message is determined by the top- </del> <ins> Similar to sending, receiving a Message is determined by the top- </ins> level protocol in the established Protocol Stack.  The main <del> difference with Receiving is that the size and boundaries of the </del> <ins> difference with receiving is that the size and boundaries of the </ins> Message are not known beforehand.  The application can communicate in its Receive action the parameters for the Message, which can help the Transport Services implementation know how much data to deliver and

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
Integer This property, if applicable, represents the maximum Message size <del> that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  It exposes the Maximum Packet Size (MPS) as described in Datagram PLPMTUD RFC8899. </del> <ins> that can be sent without incurring network-layer fragmentation at the sender.  It exposes a value to the application based on the Maximum Packet Size (MPS) as described in Datagram PLPMTUD RFC8899.  This can allow a sending stack to avoid unwanted fragmentation at the network- layer or segmentation by the transport layer. </ins> 6.1.11.3.

Discussion:
This attempts to clarify transport segmentation (a sparate PR will propose to clarify Frag)
Closing Set part of the Frag story
Change:
Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed. <del> In the case of a Remote Attestation, the attester must consider </del> <ins> In the case of a Remote Attestation, the Attester must consider </ins> whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy

Discussion:
(As per Ned Smith's message of November 8, 2022)
Claim Key as specified in RFC8392 are currently called lables in the CDDL in the Appendix. "Claim Key" by itself is only used in the definition of UCCS and never again. Should we decide on a consistent use of Claim Key or highlight that is a synonym to label before the CDDL in appendix?
Change:
5. RRC offers an in-protocol mechanism to perform peer address <del> validation, thus complementing the "peer address update" procedure </del> <ins> validation that complements the "peer address update" procedure </ins> described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP

Discussion:
Signed-off-by: Thomas Fossati
cc NAME
From my side LGTM.
For me, "man-in-the-middle" is a synonym for "on-path". If that text addresses the general "on-path" attacks in order to clarify, that RRC is no mitigation for these general "on-path-attacks", I think we should try to find an other text. As idea, we may also refer to ideas to mitigate them, but explicitly exclude that from this draft. e.g.: "reorder": don't use the record sequence number window, just drop all packets with no higher number (that drops then reordered packets). "delay records": maybe the first idea for an extension: execute a fresh RRC exchange and the next ip-packet must have a record sequence number higher as the one of the RRC message.
Right, we need to align the terminology. I propose we use the with its three levels: Inspect Inject Reorder injected ——— Off-path ——— Reorder original Modify un-authenticated portions ——— Limited on-path ——— Delay Drop Manipulating the packetization layer ——— On-path ——— and work from there.
I miss, that I'm not sure, if we should "repeat" that. Do you know, if it's possible to just refer to that?
If it works for us as-is we can just reference the relevant sections. We need to check that everything applies -- in particular whether we want to make the distinction between "on-path" and "limited on-path".
In difference to the on-path attack, where the original packet (with the original source address) simply may get dropped, and so never reaches the destination, the off-path attack is not able to drop that original packet. Though also this attack is based on a response to that "malicious source address", a implementation may use the "internal processing delay" and check, if the same packet with the original address arrives. If so, and if that address matches the previously associated address, then the implementation may chose to use the previously associated address.
For me this looks more like the off-path case. On-path attacker may just replace the original package and only forward the spoofed one.
See also my comment on . We need to rework this section starting from establishing shared terminology.
Change:
A large field section (request-response) can cause an implementation to commit a large amount of state.  Header fields that are critical <del> for routing can appear toward the end of a header field section, which prevents streaming of the header field section to its ultimate destination.  This ordering and other reasons, such as ensuring cache correctness, mean that an endpoint likely needs to buffer the entire header field section.  Since there is no hard limit to the size of a field section, some endpoints could be forced to commit a large amount of available memory for header fields. </del> <ins> for routing can appear toward the end of a header section, which prevents streaming of the header section to its ultimate destination. This ordering and other reasons, such as ensuring cache correctness, mean that an endpoint likely needs to buffer the entire header section.  Since there is no hard limit to the size of a field section, some endpoints could be forced to commit a large amount of available memory for header fields. </ins> An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size- constraints) setting to advise peers of limits that might apply on

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?
Change:
the responsibility of the application to ensure that it will be transported without changes. <del> is either a single signature or an array of signature values. A single signature value can be represented using either data type.  Implementations MUST be able to parse both data types. </del> <ins> is an array of signature items.  Each of these items uses the COSE_signature structure for its representation. </ins> The CDDL grammar structure for a signature is:

Discussion:
Following discussions on the mailing list. Removing the ability to have flattened encoding for signers and recipients.
Closes issue
JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar. Current syntax is "recipients : COSEencrypta null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it. Not really that hard to do from a programmers point of view.
Open for group discussion
Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue.
Change:
servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets <del> or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del> <ins> or BOSH XEP-0124 or a proprietary signaling mechanism used between the application running in the browser and the web server. </ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is

Discussion:
Jingle and XMPP already had references by BOSH didn't so I added it.
Kathleen had the following comment: I had to look up jingle and BOSH, you may want to consider adding references to the XMPP specifications.