jiebi/CodeConvo huggingface dataset:
Change:
TSN capabilities of the TSN sub-network are made available for MPLS (DetNet) flows via the protocol interworking function defined in <del> IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast MPLS (DetNet) flow to use a specific Layer-2 multicast destination MAC address and a VLAN, in order to direct the packet through a specific path inside the bridged network.  A similar interworking function pair at the other end of the TSN sub-network would restore the packet to its original Layer-2 destination MAC address and VLAN. </del> <ins> Annex C.5 of IEEE8021CB.  For example, applied on the TSN edge port it can convert an ingress unicast MPLS (DetNet) flow to use a specific Layer-2 multicast destination MAC address and a VLAN, in order to direct the packet through a specific path inside the bridged network.  A similar interworking function pair at the other end of the TSN sub-network would restore the packet to its original Layer-2 destination MAC address and VLAN. </ins> Placement of TSN functions depends on the TSN capabilities of nodes. MPLS (DetNet) Nodes may or may not support TSN functions.  For a

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
corresponding to a unique client report.  Sub-requests are structured as follows: <del> The "time" and "jitter" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report. [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </del> <ins> The "time", "jitter", and "extensions" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report.  [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </ins> In order to provide replay protection, the leader is required to send aggregate sub-requests in ascending order, where the ordering on sub-

Discussion:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.
Change:
Allocate response will provide the agent with a server reflexive candidate (obtained from the mapped address) and a relayed candidate in the XOR-RELAYED-ADDRESS attribute.  If the Allocate request is <del> rejected because the server lacks resources to fulfil it, the agent </del> <ins> rejected because the server lacks resources to fulfill it, the agent </ins> SHOULD instead send a Binding request to obtain a server reflexive candidate.  A Binding response will provide the agent with only a server reflexive candidate (also obtained from the mapped address).

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
different vendors, allowing interoperable distributed deployments of GNAP-protected systems. <del> This specification defines several means for a RS and AS to </del> <ins> This specification defines several means for an RS and AS to </ins> communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another

Discussion:
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: ee6b3fc9832467191449ff86c6651ebf548d33ea :mag: Inspect the deploy log: :sunglasses: Browse the preview:
A couple of other minor things it sounds to me like an optional step for the RS to validate the signature if the key object is presented in the introspection response. That should be MUST, right? The third step in section "Token Introspection" states that I think that the AS should validate the RS's request and only after that the AT's value.
The RS always has to validate the signature, but sometimes it can't fully validate it until after it looks up the token's data using introspection. We should look at what OAuth MTLS and DPoP say in terms of RS validation steps. The intent of the language for the AS validation was not to imply an order in either direction, so we can look to tweak this to make that more clear.
Change:
VN packet to indicate that the version the client offered is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported <del> version.  With proper safety mechanisms in place, the VN packet can be part of a mechanism to allow two QUIC implementations to negotiate between two totally disjoint versions of QUIC, at the cost of an extra round trip.  However, it is beneficial to avoid that cost whenever possible, especially given that most incremental versions are broadly similar to the the previous version. This specification describes a simple version negotiation mechanism which optionally leverages similarities between versions and can negotiate between the set of "compatible" versions in a single round trip. </del> <ins> version. With proper safety mechanisms in place, the VN packet can be part of a mechanism to allow two QUIC implementations to negotiate between two totally disjoint versions of QUIC.  This document specifies version negotiation using VN packets, which adds an extra round trip to connection establishment if needed. It is beneficial to avoid additional round trips whenever possible, especially given that most incremental versions are broadly similar to the the previous version.  This specification also defines a simple version negotiation mechanism which leverages similarities between versions and can negotiate between the set of "compatible" versions without additional round trips. </ins> 1.1.

Discussion:
The "single round trip" thing isn't really a guarantee given various factors. Setting this up as additional round trips is cleaner and more accurate. I adjusted the paragraph structure to match.
The introduction reads like the draft only defines compatible version negotiation. It probably needs to be written to be more general.
Fair enough.
Thanks, that is a lot clearer
Change:
An is shown in fig-enc-response. response describes the process for constructing and processing an . <del> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del> <ins> That is, an contains a Nonce and an AEAD-Protected Response.  The Nonce field is either "Nn" or "Nk" bytes long, whichever is larger. The "Nn" and "Nk" values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [1]. "Nn" and "Nk" refer to the size of the AEAD nonce and key respectively, in bytes. </ins> 4.3.

Discussion:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...
Change:
When using the GET method the URI path MUST contain a query parameter with the name of "ct" and a value indicating the media-format used <del> for the body parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&body=...) or it may be </del> <ins> for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be </ins> empty.  An empty value indicates the default application/dns- <del> udpwireformat type (e.g. ct&body=...). </del> <ins> udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter <del> with the name of "body".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. </del> <ins> with the name of "dns".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. </ins> Specifications that define media types for use with DOH, such as DNS Wire Format dnswire of this document, MUST indicate if the body parameter uses base64url encoding.

Discussion:
partially addresses martin is right - the naming of this query parameter was just asking for pain. new coat of paint is in order.
:+1:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.
Change:
5.5. <del> No updates to Section 5.5 of RFC5216. </del> <ins> As decscribed in RFC3748 and Section 5.5 of RFC5216, the only information that is integrity and replay protected in EAP-TLS are the parts of the TLS Data that TLS protects.  All other information in the EAP-TLS message exchange including EAP-Request and EAP-Response headers, the identity in the identity response, EAP-TLS packet header fields, Type, and Flags, EAP-Success, and EAP-Failure can be modified, spoofed, or replayed.  This section updates Section 5.5 of RFC5216. Protected TLS Error alerts are protected failure result indications and enables the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker.  Protected failure result indications provide integrity protection and replay but MAY be unauthenticated.  Protected failure result does not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error. </ins> 5.6.

Discussion:
Bernard has provided links to academic paper describing attacks on availability and ask for updates to the draft describing this. The new paragraph do just that. Added that most things can be spoofed was requested by several persons including Security AD Ben and several TLS people. This was misunderstandings. This is related to the pull request "EAP state machine"
This should address issue
protected failure indicatioin gives the peer an authenticated way to know that the real server sent the failure. It does little or nothing to improve availability as basically any forged message makes TLS fall hard and fatal.
I don't think there is a way to protect the exchange from injection of errors without doing something more extreme like moving to DTLS. It's also not clear that even if the method protected against it that many of the lower layers might have equivalent problems.
"I don't think there is a way to protect the exchange from injection of errors" I don't think so either and think that is fine. I think the important availability goal is that the client and server can try again. I.e. an attacker needs to constantly be active to drop the handshake. I brought this up as Bernard stated that protected failure was important to improve availability. My conclusion is that protected failure does not improve availability as there are other easier was to drop the connection.
I agree with John's analysis. I think this can be closed.
Looks good to me. We may need to edit to add protected success indications.
Change:
between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons. <ins> Note that, when used with WebTransport over HTTP/2, the capsule exists alongside the ability to pad HTTP/2 frames (Section 10.7 of RFC9113).  HTTP/2 padding is hop-by-hop and can be modified by intermediaries, while the capsule traverses intermedaries.  The capsule is also constrained to be no smaller than the capsule overhead itself. </ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.

Discussion:
This is not a bad thing. In fact it's a deliberate choice. It might be worth noting the redundancy so people don't think we're a bit dim. We might also add that this padding is less tunable than h2 padding.
Do we actually need WT_PADDING, and if so, does it need to be in this document?
NAME do you remember why we deliberately chose to have this separate padding instead of just relying on the h2 padding?
I don't recall the specifics 18 months on. However, the basic problems are invariant. The different padding schemes offer different capabilities due to a bunch of different design trade-offs and inherent properties of each approach. h2 padding only applies to one hop, but WTPADDING would traverse intermediaries (because it is application data as far as they are concerned). Consequently, you might want to use WTPADDING if your goal is to protect against leaks on remote hops. This is because each operates on a different scope. WTPADDING doesn't get to be smaller than the minimum capsule size, but h2 padding can be any size. That means that a padding strategy is potentially more efficient in h2 as you need to include WTPADDING and its overheads. This is because the more padding integration in h2 is more complete, but also more complex. Finally, there are all the usual software engineering constraints. Maybe you have access to padding functions in your WT stack, but not the h2 stack.
Many thanks NAME Added a version of that to the padding section (noting that padding is a generic capsule being defined here, so others can use it even if not over HTTP/2).
Change:
"echo_nonce" to the ClientHelloInner (but not to the outer ClientHello).  This nonce ensures that the server's encrypted Certificate can only be read by the entity which sent this <del> ClientHello.  [[TODO: Describe HRR cut-and-paste 1 in Security Considerations.]] This extension is defined as follows: </del> <ins> ClientHello.  This extension is defined as follows: </ins> A 16-byte nonce exported from the HPKE encryption context.  See send-echo for details about its computation.

Discussion:
Addresses . This is for motivating some of our design decisions (and documenting what we know along the way). I meant to do this a while ago, but never got around to it. In particular, it describes why we have the following three bindings: Transcript to ECHO secret (to prevent client reaction attacks). CH1 to CH2 (to prevent HRR oracles). ClientHello to resumption PSK binder (to prevent resumption oracles). I'm sure the language and presentation can be improved, so suggestions to that effect are very much welcome! cc NAME NAME NAME NAME NAME NAME NAME
Thanks for the feedback! I incorporated your suggestions and clarified a few more things. I'm merging as-is since they seemed mostly editorial.
Addressed in .
Change:
digest being signed are both the corresponding hash algorithm as defined in SHS.  When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest <del> output. </del> <ins> output.  This codepoint is defined for use with TLS 1.2 as well as TLS 1.3.  A server uses RSASSA-PSS signatures with RSA cipher suites. </ins> Indicates a signature algorithm using EdDSA as defined in I- D.irtf-cfrg-eddsa or its successors.  Note that these correspond <del> to the "PureEdDSA" algorithms and not the "prehash" variants. </del> <ins> to the "PureEdDSA" algorithms and not the "prehash" variants.  A server uses EdDSA signatures with ECDSA cipher suites. </ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list

Discussion:
The document was pretty crisp about the version downgrade protections, but was less good about the changes to signature schemes. I have made a few changes to the description of signature_algorithms that should improve that. In particular, I have made it clear that the RSASSA-PSS codepoints are also defined for TLS 1.2 and that they can be used there. That means that TLS implementations need to be prepared to accept PSS signatures. This also adds a section that points to the pieces that 1.2 implementations need to consider.
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?
Change:
4.6.1. Connected protocols such as TCP and TLS-over-TCP have a strong <del> mapping between the Local and Remote Endpoints (five-tuple) and their </del> <ins> mapping between the Local and Remote Endpoints (four-tuple) and their </ins> protocol connection state.  These map into Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection object and pass it to the

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
to an attacker and causing overhead.  An amplification factor of 3 (i.e., don't send more than three times the number of bytes received until the peer's address is confirmed) is <del> considered acceptable for unconstrained applications I-D.ietf- quic-transport. </del> <ins> considered acceptable for unconstrained applications in RFC9000 Section 8. </ins> When that limit is applied and no further context is available, a safe default is sending initial responses no larger than 136

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> registration and lookup of those resources. </del> <ins> discovery, for the creation, the maintenance and the removal of registrations, and for lookup of the registered resources. </ins> In the context of a Resource Directory, a sector is a logical

Discussion:
This is to address Russ's genart comment:
The reflowing commit went here by accident (wrong branch / didn't check on upload). I'm pushing it to master, hoping this makes the PR's diff show only what's intended.
Change:
this might be provided by the redemption protocol in HTTP- Authentication. <del> Both Client and Issuer also share a common public string called "info". </del> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.  This section uses notation described in OPRF, Section 4, including SerializeElement and

Discussion:
Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM
Change:
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields <del> indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided within the request. </del> <ins> indicate the desired WebTransport server.  If the WebTransport session is coming from a browser client, an "Origin" header RFC6454 MUST be provided within the request; otherwise, the header is OPTIONAL. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a

Discussion:
This is vaguely based on the similar text in the WebSocket RFC.
In draft 03 the following requirement is made WebTransport's closest equivalent in this regard is WebSockets, which doesn't mandate the origin header; see URL This requirement makes it weird to use for user agents that have no concept of an origin model. So the MUST level seems a bit overzealous.
It is not just the user agent. Take for example the proposed use of . That application does not have any concept of "origin" -- indeed, there is no mention of the word "origin" in that draft.