jiebi/CodeConvo huggingface dataset:
Change:
unreliable delivery to WebSockets RFC6455. In datagrams, this document describes HTTP Datagrams, a convention <del> that supports the bidirectional and possibly multiplexed exchange of data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT method), and are compatible with all versions of HTTP. </del> <ins> that supports the bidirectional and optionally multiplexed exchange of data inside an HTTP connection.  While HTTP datagrams are associated with HTTP requests, they are not part of message content; instead, they are intended for use by HTTP extensions (such as the CONNECT method), and are compatible with all versions of HTTP. </ins> When HTTP is running over a transport protocol that supports unreliable delivery (such as when the QUIC DATAGRAM extension is

Discussion:
Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric
Change:
the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the <del> connection has been setup, but is vulnerable during setup (See I- D.ietf-quic-transport for more details). </del> <ins> connection has been setup.  While QUIC implements a stateless reset mechanism, such a reset is only accepted by a peer if the packet ends in a previously issued stateless reset token which is hard to guess. During the handshake, QUIC only provides effective protection against off-path attackers but is vulnerable to injection attacks by attackers that have parsed prior packets.  (See I-D.ietf-quic- transport for more details.) </ins> Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
The only nodes that needs to know the payload type of a flow are the DetNet ingress node and the DetNet egress nodes.  The ingress node has to know how to process the packet it receives from the ingress <del> AC, and egress edge node has to know how to.. </del> <ins> AC, and egress edge node has to know how to prepare the packet for transmission on the egress AC. On ingress a DetNet edge node has to classify the packets into those that are for transmission as Detnet packets and those that are for transmission as "normal" packets at one of more lower priorities. The packet type is indicated to the egress edge node through the value of the S-label.  Thus, when the egress edge node looks up the S-label one of the parameters returned is the packet type which in turn tells the egress edge node how to prepare the packet for transmission over the egress AC. The consequence of this approach is that if multiple packet encapsulations are processed on a node, each will need its own S-Label.  That is not generally a problems, since it is anticipated that only one encapsulation type intented for carriage as a DetNet flow will be present on any egress.  However, IPv4 and IPv6 have different forwarding equivalence classes (FEC) in MPLS and are therefore allocated different labels rather than being distinguished through the IP version field in the IP header.  Futhermore IPv4 and IPv6 when running directly over Ethernet are identified via the Ethertype rather than via the IP version number.  Whilst it ought to be safe to identify the IP type though the IP version number the absence this approach in practical applications suggests that it is more conservative to distinguish between IP types through the S-Label.  Thus when the payload is IP, two S-Labels are used, one to identify an IPv4 payload and one to identify an IPv6 payload. </ins> [Editor's note: We have specified the above for _data_ to leave the door open for the GAL based OAM method as an alternative to

Discussion:
Put the text that was taken out of the payload ident section back in. Fixed some compile warnings Two were figs too large One was use of [IEEE1588] instead of Rest were apparently unused references Requesting pull so we are in sync on this.
Looks OK to me. Merging all these chnanes.
Change:
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 <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </ins> Commonly used terms in this document are described below.

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
5.4. <del> When performing a Commit, the leaf KeyPackage of the committer and its direct path to the root are updated with new secret values.  The HPKE leaf public key within the KeyPackage MUST be a freshly generated value to provide post-compromise security. The generator of the Commit starts by using the HPKE secret key "leaf_hpke_secret" associated with the new leaf KeyPackage (see key- packages) to compute "path_secret[0]" and generate a sequence of "path secrets", one for each ancestor of its leaf.  That is, path_secret[0] is used for the node directly above the leaf, </del> <ins> When performing a Commit, the generator of the Commit updates its leaf KeyPackage and its direct path to the root with new secret values.  The HPKE leaf public key within the KeyPackage MUST be derived from a freshly generated HPKE secret key to provide post- compromise security. The generator of the Commit starts by sampling a fresh random value called "leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair (see key-packages) and to seed a sequence of "path secrets", one for each ancestor of its leaf.  In this setting, path_secret[0] refers to the node directly above the leaf, </ins> path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding node, from which the node's key pair is derived.

Discussion:
This PR tries to clarify these paragraphs by the following: Differentiating between HPKE public/private keys when describing how these keys are rotated for a commit Clarifying who does the actions associated with a commit Adding consistency fixes between the two paragraphs Let me know if these fixes are not quite right, as this PR tries to clarify where I had questions when reading.
Change:
have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <ins> A more detailed discussion with examples appears in time- considerations. </ins> 10. The conveyance of Evidence and the resulting Attestation Results

Discussion:
Add time considerations into an appendix and reference it from the freshness section.
For readability, I have removed extraneous event times and only kept the ones used in the discussion after at least one diagram. My goal is to keep the discussion easy to understand and not include excess details or complexity that could be left to other docs.
NAME will look into additions around purple items. NAME to work on moving table to section 9 (freshness)
Change:
client: The endpoint initiating the DTLS connection. <del> connection: A transport-layer connection between two endpoints. </del> <ins> association: Shared state between two endpoints established with a DTLS handshake. connection: Synonym for association. </ins> endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that <del> establishes the parameters of their transactions. </del> <ins> establishes the parameters of the connection. </ins> peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of

Discussion:
This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.
Change:
12.4.1. The mathematics for Elliptic Curve Diffie-Hellman can be found in <del> RFC6090. </del> <ins> RFC6090.  In this document the algorithm is extended to be used with the two curves defined in I-D.irtf-cfrg-curves. </ins> ECDH is parameterized by the following:

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
The encoded packet number is protected as described in Section 5.4 of QUIC-TLS. <del> The sender MUST use a packet number size able to represent more than </del> <ins> Prior to receiving an acknowledgement for a packet number space, the full packet number MUST be included. After an acknowledgement is received for a packet number space, the sender MUST use a packet number size able to represent more than </ins> twice as large a range than the difference between the largest acknowledged packet and packet number being sent.  A peer receiving the packet will then correctly decode the packet number, unless the

Discussion:
I noticed the 0-RTT specific text in and thought a general clarification would be better. Conveniently, I don't think anyone has gotten this wrong in their implementation.
Thanks Ian, this is much clearer.
Change:
Selection Properties are listed in the subsections below.  Note that many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can be <del> queried.  Querying a Selection Property after establishment yields the value "Require" for properties of the selected protocol and path, Avoid for properties avoided during selection, and Ignore for all other properties. </del> <ins> queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </ins> An implementation of this interface must provide sensible defaults for Selection Properties.  The defaults given for each property below

Discussion:
I chose boolean, because, when querying, it only matters whether a Selection Property was chosen or not (I believe).
From Kyle Rose: NAME says: I think this isn't very controversial, I believe we should just do this as he suggested. This issue is just a reminder for myself to do this.
Thanks
Change:
1-RTT keys have forward secrecy <del> authenticated values for the transport parameters of the peer (see transport-parameters) </del> <ins> authenticated values for transport parameters of both endpoints, and confidentiality protection for server transport parameters (see transport-parameters) </ins> authenticated negotiation of an application protocol (TLS uses ALPN RFC7301 for this purpose)

Discussion:
The TPs might carry a stateless reset token, which must be encrypted in transit. Section 7 in the transport document [1] lists some requirements for the handshake, including authentication of the TPs, yet does not include any mention of encrypting them from server to client. Should it? cc NAME NAME [1] URL
This makes sense to me. The TLS document ensures that the server's transport parameters are encrypted so an editorial PR changing the transport doc to require that should be sufficient.
Good catch. Marking as design so that we can consensus call this, but it's arguably editorial.
Change:
comparisons between a structured value and any value, including the same structured value, yield true. <del> 3.4.8.2.2.1. </del> <ins> 3.4.7.2.2.1. </ins> JSON: <del> 3.4.8.2.3. </del> <ins> 3.4.7.2.3. </ins> A regular-expression test yields true if and only if the value on the left-hand side of "=~" is a string value and it matches the regular

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
frame (frame-reset-stream) if the stream was not already in a terminal state. <del> On the receiving part of a stream, application protocols need to be able to: </del> <ins> On the receiving part of a stream, an application protocol can: </ins> read data; and abort reading of the stream and request closure, possibly resulting in a STOP_SENDING frame (frame-stop-sending). <del> Applications also need to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer aborts reading on a stream, when new data is available, and when data can or cannot be written to the stream due to flow control. </del> <ins> An application protocol can also request to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer aborts reading on a stream, when new data is available, and when data can or cannot be written to the stream due to flow control. </ins> 3.

Discussion:
The strong requirements here were wrong. What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present. Levying the requirement on implementations was incorrect. As some application protocols don't use certain QUIC features, it is not necessary to require implementations to support features if they are not general purpose. This rephrases these requirements without normative language, instead concentrating on what services the application protocol can depend on. This translates into requirements on implementations, but only via the application protocols they intend to support.
S 5.4 requires that the application be able to control resource allocation of various types, including flow control and the number of permitted streams of each type; This seems like a good idea, but it seems like one could have a reasonable QUIC stack that did not do this.
I would prefer to leave this. Noting that the level of control is not specified. This also suggests that the stack provide a keep-alive control, but there are likely cases (I'm thinking here of DNS over QUIC) where that is unlikely to be a useful feature. The goal is to list things that the specification believes a generic stack will provide. Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API.
NAME willing to fight for this one?
After discussing with editors, we think that it would be better to remove the MUST in this section and say something like: "A general purpose QUIC implementation provides the following functions:" and add "A specialized implementation might provide a subset of these." The same applies to the stream operations.
I think that is a positive change. Borderline design issue by the sound of it. It would be good to see the PR once its available.
Change:
keys from multiple network vantage points.  This is done to ensure consistent keys to seemingly different clients. <del> Clients embed server keys into software. </del> <ins> Clients embed Issuer keys into software. </ins> <del> Specific mechanisms for key management and discovery are out of scope for this document. </del> <ins> As above, specific mechanisms for key management and discovery are out of scope for this document. </ins> <del> 4.1. </del> <ins> 3.2.2.2. </ins> Token issuance associates all issued tokens with a particular choice <del> of key.  If a server issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. </del> <ins> of key.  If an Issuer issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. </ins> <del> To prevent against this, servers MUST only use one private key for </del> <ins> To prevent against this, Issuers MUST only use one private key for </ins> issuing tokens at any given time.  Servers MAY use one or more keys <del> for redemption to allow servers for seamless key rotation. </del> <ins> for redemption to allow Issuers for seamless key rotation. </ins> Servers may rotate keys as a means of revoking tokens issued under <del> old or otherwise expired keys.  Alternatively, servers may include </del> <ins> old or otherwise expired keys.  Alternatively, Issuers may include </ins> expiration information as metadata alongside the token; See metadata <del> for more discussion about metadata constraints.  Both techinques are </del> <ins> for more discussion about metadata constraints.  Both techniques are </ins> equivalent since they cryptographically bind expiration to individual tokens.

Discussion:
This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients, Mediators, Issuers, and Origins. First draft, so there may be things we want to rephrase or reflow. Rendered view of this PR .
Whitespace errors?
NAME fixed!
Merging this per the discussion during the interim meeting today.
A few comments; thanks for the quick turnaround!