jiebi/CodeConvo huggingface dataset:
Change:
The use of client-generated incoming DCIDs does not persist beyond a few round trips in the connection. <del> In this interval, some exposed fields (e.g.  UDP address and port, source and client-generated destination Connection ID) remain constant for all packets in the connection.  For example, 0RTT and Initial packets use the same CIDs and ports. </del> <ins> While the client is using DCIDs it generated, some exposed fields (IP address, UDP port, client-generated destination Connection ID) remain constant for all packets sent on the same connection. While this document does not update the commitments in QUIC- INVARIANTS, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can use with minimal risk of version- dependence. </ins> If these assumptions are invalid, this specification is likely to lead to loss of packets that contain non-compliant DCIDs, and in

Discussion:
Carefully phrased language that considers NAME 's suggestion that SCID may not be stable across versions, and tries to suggest (IP, port, DCID) as a suitable long header hash without making promises on behalf of quic-invariants.
NAME sayeth on the list: It would be useful to include something like this in Section 4 as a non-normative hint on what fields to use, since our hint currently consists of an example that just uses the DCID. Similarly, make that assumption clearer in Section 8.
For what it's worth, Google's load balancer only uses destination CIDs for routing. We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs.
Do all CIDs resolve to a valid server ID?
NAME do you not care about an attacker specifically crafting destination CIDs to attack a particular server?
NAME We do not have a concept of server ID, but yes every CID routes to a server. NAME We do not care about that attack. I haven't seen any indication that it can actually cause harm in real life.
NAME very well, then you have no non-compliant DCIDs. You would only need to upgrade your LBs for new versions if they allowed client-chosen DCIDs < 8 bytes.
Change:
The maximum Connection ID length could be below the minimum necessary for one or more encoding algorithms. <del> non-compliant provides guidance about how load balancers should handle non-compliant DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </del> <ins> unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </ins> Incoming short headers do not contain DCIDs that are client- generated.

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:
connection, with the following added behavior: It MUST include the "encrypted_client_hello" extension with the <del> "retry_keys" field set to one or more ECHConfig structures with </del> <ins> "retry_configs" field set to one or more ECHConfig structures with </ins> up-to-date keys.  Servers MAY supply multiple ECHConfig values of different versions.  This allows a server to support multiple versions at once.

Discussion:
Addresses
The spec uses both and when referring to the contents of . These should be made consistent (preferably using the former).
Agreed -- let's unify around ! Would you be able to propose text?
( is a remnant of the old name. I guess we missed a few.)
Thanks!
Change:
Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see <del> Section 11 of PRIORITY. </del> <ins> PRIORITY. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
is therefore in general unsuitable for deriving a NAI to use in the Identity Response. <del> A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket is shown in figresumption. A subsequent successful resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server does not provision any new tickets is shown in figresumption2. </del> <ins> figresumption shows an example message flow for a subsequent succesfull EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket. </ins> As specified in Section 2.2 of RFC8446, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
the message exchange, they must be received and processed before the message can be consumed.  See header-formatting for more details. <del> Transfer codings (see Section 6.1 of HTTP11) are not defined for </del> <ins> Transfer codings (see Section 7 of HTTP11) are not defined for </ins> HTTP/3; the Transfer-Encoding header field MUST NOT be used. A response MAY consist of multiple messages when and only when one or

Discussion:
Noticed in URL that we're pointing to different sections: 6.1 is the Transfer-Encoding header 7.1 is specifically 7 is transfer codings in general Since this passage is referring to the concept in general not being present in HTTP/3, Section 7 is the correct reference.
Change:
client. The value of "n" is determined by the length of the <del> "ClientIssuanceElement" vector in the "ClientIssuanceMessage" struct. The internal data types are described below: </del> <ins> "ClientIssuanceElement" vector in the "ClientIssuanceRequest" struct. The internal data types are described below. </ins> 3.1.8.

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
4.1.1. Both Local and Remote Endpoint Candidates must be discovered during <del> connection establishment.  To support ICE, or similar protocols, that involve out-of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </del> <ins> connection establishment.  To support Interactive Connectivity Establishment (ICE) RFC8445, or similar protocols, that involve out- of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </ins> 4.1.1.1.

Discussion:
and spell out ICE.
I also updated a later reference and added references for STUN and TURN in this same PR now.
Change:
and 7.1 of YAML) as fragment identifiers to designate nodes. A YAML alias node can be represented in a URI fragment identifier by <del> encoding it into octects using UTF-8 UTF-8, while percent-encoding </del> <ins> encoding it into bytes using UTF-8 UTF-8, while percent-encoding </ins> those characters not allowed by the fragment rule in Section 3.5 of URI.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
protocol. The Issuer parameters can be obtained from an Issuer via a directory <del> object, which is a JSON object whose values are other JSON objects and URLs for the parameters. </del> <ins> object, which is a JSON object RFC8259, Section 4 whose values are other JSON values RFC8259, Section 3 for the parameters. </ins> Each "token-keys" JSON object contains the following fields and corresponding raw values.

Discussion:
The configuration section lists several requirements that depend on JSON, but a JSON specification is not given. I'm guessing you probably want URL
Issuers MUST provide a configuration , so what spec should they be referring to in order to ensure that this URI is well formed? I started wondering about how percent-encoding might apply, and that got me on to thinking whether you really want to support something like `"issuer-request-uri": "https://EMAIL:123/forum/questions/?tag=networking&order=newest#top",
Unless I'm missing something, I don't think there should be any constraints on how the URI is constructed. We should say something about how it's encoded, though. That's a good point.
Change:
that function.  This specification also defines the default cipher that is used in EKT.  The default cipher described in DefaultCipher MUST be implemented, but another cipher that conforms to this <del> interface MAY be used. </del> <ins> interface MAY be used.  The cipher used for a given EKTCiphertext value is negotiated using the supported_ekt_ciphers and indicated with the SPI value in the FullEKTField. </ins> An EKTCipher consists of an encryption function and a decryption function.  The encryption function E(K, P) takes the following

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral Multicast DNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </del> <ins> registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates.  WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2.

Discussion:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.
Change:
A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying <del> application specific actions.  Compare /relying party/ in RFC4949. </del> <ins> application specific actions.  Compare: /relying party/ in RFC4949. </ins> Consumes: Attestation Results, Appraisal Policy for Attestation Results

Discussion:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`
Change:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 0 and 2^14 or greater are invalid, and </del> <ins> acknowledgement.  Values of 0 and 2^24 or greater are invalid, and </ins> receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION.

Discussion:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24
Change:
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames to issue usable connections IDs to reach it.  Before an endpoint adds <del> a new path, it SHOULD check whether there is at least one unused </del> <ins> a new path, it MUST check whether there is at least one unused </ins> available Connection ID for each side. If the transport parameter "active_connection_id_limit" is negotiated

Discussion:
I copied this sentence from draft-liu: Shouldn't this be a MUST instead of a SHOULD?
We can describe it in a more accurate way: Before an endpoint adds a new path, it MUST check whether there is at lease one unused available Connection ID for each side, unless the endpoints use zero-length Connection ID.
Submitted PR for this issue.
LGTM.
Change:
within a domain, they must be advertised to their upstream DetNet service-aware peer nodes (e.g., a DetNet MPLS End System or a DetNet Relay or Edge Node) and interpreted in the context of their received <del> F-Label(s). </del> <ins> F-Label(s).  In some PREOF topologies, the node performing replication will be sending to multiple nodes performing PEF or POF, and may need to send different S-Label values for the different member flows for the same DetNet service. </ins> An S-Label will normally be at the bottom of the label stack once the last F-Label is removed, immediately preceding the d-CW.  To support

Discussion:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).
Change:
and "sender_base_key" values on demand, as it needs to encrypt/ decrypt for a given member. <del> MLS also provides an authenticated signing key pair for each participant.  When SFrame uses signatures, these are the keys used to generate SFrame signatures. </del> 6. 6.1.

Discussion:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?
Change:
Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard <del> limits on what its video decoder can process, or it may wish to constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed. </del> <ins> limits on what its video decoder can process, or it may have some maximum set by policy. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP

Discussion:
The second paragraph of section 3.6.1 seems odd when talking about creating answers, and downright incorrect when talking about offers. Minimally, it needs text to explain why x=0/y=0 would ever make more sense than using "a=sendonly/recvonly/inactive."
There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up.
NAME -- >There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up. Ideally, this rationale would be added to the document once you find it.
Sounds like a good idea.
I was able to find it - the concern was that if you offered a=recvonly, you could then potentially change that to a=sendrecv via transceiver.setDirection, so a=imageattr of [0, 0] provided a way to prevent any video from being sent without additional complexity. URL
I'm coming around to Adam's viewpoint on this one - not sure we should be inventing a new syntax for saying 'don't send me this video stream'.
Section 3.6.1 describes mandatory constraints applied to an incoming track resulting in a new offer-answer exchange. Since this is "action at a distance" (modify the track and the PeerConnection emits a negotiation-needed), I think this needs to be synced with the webrtc-1.0 API spec, and possibly even media-capture. Also, what's the state of the track between the changing of constraints at the receiver and the renegotiation? It seems to me that the track should be scaled at the receiver to fit the agreed-upon constraints.
OK, agreed we have moved away from this sort of approach. I guess we could add a new API to RtpReceiver if we decide we need this sort of functionality; we can either spec said API here in JSEP for future implementation, or drop discussion of it altogether. NAME wdyt?
Dropping discussion seems like the simplest approach; that will mean that the receiver hands whatever comes to it into the track, and the track processes it like it processes any other source. Simple is good.
See PR
Change:
The removes the encapsulation to obtain the response to the original request. <ins> This interaction provides authentication and confidentiality protection between the and the Oblivious Gateway, but importantly not between the and the . While the is a distinct HTTP resource from the , they are both logically under the control of the Oblivious Gateway, since the can unilaterally dictate the responses returned from the to the . This arrangement is shown in fig-overview.  See security for more information about and Oblivious Relay, and Oblivous Gateway resources in running this protocol. </ins> 2.1. <del> Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies (COOKIES), authentication (HTTP), or even alternative services (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. </del> <ins> Oblivious HTTP has limited applicability.  Imporantly, it requires expicit support from a willing and , thereby limiting the use of Oblivious HTTP for generic applications; see server-responsibilities for more information. Many uses of HTTP benefit from being able to carry state between requests, such as with cookies (COOKIES), authentication (HTTP), or even alternative services (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. </ins> Oblivious HTTP is primarily useful where privacy risks associated with possible stateful treatment of requests are sufficiently large

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. <del> A SoftError can inform the application about the receipt of an ICMP error message that does not force termination of the connection, if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </del> 11. As this interface is designed to be independent of an

Discussion:
Rather than saying "this can only be queried" everywhere, I split this into setting and querying now, and I also moved SoftErrors in there. It's not precisely "querying" for a Property, but it's the closest match - better than "Connection Termination", I think (this is where SoftErrors were before).
NAME what about "Connection Maintenance: Setting Properties and Obtaining Information" ?
Maintenance sounds a bit strange to me, "Managing Connections: Setting Properties and Obtaining Information" ?
I like it (and I agree about "maintenance" being slightly strange)
Managing sounds good to me too.
Ack, done
lgtm, thanks!
Change:
output of AEAD_AES_128_GCM AEAD used with the following inputs: The secret key, K, is 128 bits equal to <del> 0xf5ed4642e0e4c8d878bbbc8a828821c9. </del> <ins> 0x4d32ecdb2a2133c841e4043df27d4430. </ins> <del> The nonce, N, is 96 bits all set to zero. </del> <ins> The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575. </ins> The plaintext, P, is empty. The associated data, A, is the contents of the Retry Pseudo- Packet, as illustrated in retry-pseudo: <ins> The secret key and the nonce are values derived by calling HKDF- Expand-Label using 0x656e61e336ae9417f7f0edd8d78d461e2aa7084aba7a14c1e9f726d55709169a as the secret, with labels being "quic key" and "quic iv" (protection- keys). </ins> The Retry Pseudo-Packet is not sent over the wire.  It is computed by taking the transmitted Retry packet, removing the Retry Integrity Tag and prepending the two following fields:

Discussion:
Just to set expectations, I think that I want to reserve the ability to pick new values for these. Just as there will be a new value for the Initial salt when we publish an RFC, this probably needs a new value at the same time.
Retry integrity protection () specifies the AES-GCM key and IV directly. While that works fine for people using TLS stacks that provide direct access to AES-GCM, it does not for people using TLS stacks that only provides access to TLS AEAD API. Previously, we have been consistent in using HKDF-Expand-Label in a specific way so that people could rely on the "TLS" stack generating AEAD contexts. I think we can resolve the concern by simply changing the hard-coded AES-GCM key and IV we specify in the TLS draft to a set of values that can be derived by using the TLS AEAD API.
It would be easier for me to do as NAME suggested, but the overall effort is small. I can live with either answer. Note that the additional indirection can be hard-coded out if people find they want to prime their AES directly. Of course, you don't need to run AES at all if you want to go that far.
I agree that this is not a must, even though it's about helping some of the implementations. I would highly appreciate it if you could merge the PR before -25 ships, as I think changing the default key before shipping the first draft that adopts the GCM-based Retry protection would have the least friction.
This is useful, and we should merge this. I don't think this needs to be design.
If this is the outcome, then this seems fine.I think this is useful -- we should merge this.