jiebi/CodeConvo huggingface dataset:
Change:
5.3. <del> There are certain operations that an application MUST be able to perform when interacting with the QUIC transport.  This document does not specify an API, but any implementation of this version of QUIC MUST expose the ability to perform the operations described in this section on a QUIC connection. </del> <ins> This document does not define an API for QUIC, but instead defines a set of functions for QUIC connections that application protocols can rely upon.  An application protocol can assume that an implementation of QUIC provides an interface that includes the operations described in this section.  An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol. </ins> <del> When implementing the client role, applications need to be able to: </del> <ins> When implementing the client role, an application protocol can: </ins> open a connection, which begins the exchange described in handshake;

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:
Server are delivered to a User Agent via a Push Service. This document describes how messages sent using this protocol can be <del> secured against inspection or modification by a Push Service. </del> <ins> secured against inspection, modification and falsification by a Push Service. </ins> Web Push messages are the payload of an HTTP message RFC7230.  These messages are encrypted using an encrypted content encoding I-

Discussion:
Adam Langley and David Benjamin identified a risk with the proposed security design for push messages. In the existing design, a user agent shares two pieces of information with an application server that form the basis of authenticating messages. endpoint - The secrecy of the endpoint URL is used to protect the user agent from receiving unauthenticated and unwanted messages. Unfortunately, this URL is necessarily known to user agent, push service and application server, so any of those three can generate spam. DH public key - The secrecy of the Diffie-Hellman public key is relied on to ensure that a valid push message can't be sent by anyone other than the application server. Only the user agent and the application server know this information. The concern here is that a DH public key is not typically treated like a secret. That means that when it is used, there is no guarantee that an implementation won't leak bits of the public key. For instance, if an implementation isn't constant time with respect to its contents, . If this secret is leaked to the push service, then the push service is able to generate push messages that will be accepted by the user agent. Those messages will appear to come from the application server. In the modern spirit of belt-and-braces design for security protocols, this change adds a new authentication secret that the application server has to prove ownership of to send a message. This secret is mixed into the key derivation process. Any entity that doesn't know this value will be unable to derive a valid content encryption key. The suggested alternative, a HMAC key, was rejected on the basis that it increased the signaling load on the path from application server -> push service -> user agent. This provides similar protection without increasing the size of push messages. This change builds on martinthomson/http-encryption by adding the authentication secret to the context that is passed as the HKDF label.
Attention NAME
Updated to be based on martinthomson/http-encryption based on URL
Change:
backward-compatibility for details about backward compatibility.) <del> This structure is generated by the server and MUST be independently generated from the ClientHello.random. </del> <ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> This is the identity of the session corresponding to this

Discussion:
Server Hello is slightly confusing english. Must this be generated from the URL I'm pretty sure the opposite is the intent. A clearer form of words might be: or
Merged.
Change:
The main purpose of this document is providing guidelines for how Working Groups might integrate the capabilities provided by GitHub <del> into their processes for developing Internet-Drafts. </del> <ins> into their processes for developing Internet-Drafts.  The choices of whether to use GitHub and whether to adopt these practices if they do is at the discretion of the Working Group. </ins> This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and

Discussion:
I agreed to change from DISCUSS to Abstain if this change was made - email thread for the curious / archives: URL A PR is close enough to integrated for me...
NAME I'm curious why this change is adequate; it's effectively just a rewording. It doesn't address the issue of the group choosing to adopt the policies.
NAME Yes, it is just a rewording -- but (for me at least) it made it enough clearer that this was optional (WGs can choose to use GH, not WGs are expected to use GH) that I was willing to move to Abstain instead. The WG has consensus, and the charter sent us down the "GH FTW!" path - it isn't appropriate for me to block this just because I don't like it / think there is a better way of using RCS tooling / GH. The process was followed, and the document is valuable - I don't like the tone, I don't like the implication, but it now falls into the "Well, that's just, like, your opinion, man..." territory. (There isn't a technical objection, nor do I think it is specifically dangerous to the IETF / IETF stream, so...)
NAME - OK. This is made moot by the other changes that Martin made to the draft, but to be clear, I don't think that's a good line of argumentation. The WG was charted to an explicit scope - that WGs had to opt into the practices it documented. If it were producing a document that exceeded that scope (which is arguably did before the recent change referenced above), saying that the WG "has consensus" to violate its charter is meaningless, and letting that stand is damaging. That's because charters allow people to decide whether or not they're going to follow a WG. If a WG can violate its charter and justify that with "but we had consensus to do so", charters are meaningless, and the check that requiring IETF consensus places upon WGs is seriously diminished. Thank you -- I would even be OK with just changing to Abstract to be: "This document describes best practices for Working Groups that choose to use GitHub for their work." and leave it as BCP. Would that work better for everyone?

It would be enough for me to no longer feel that this is saying that WGs using GitHub is a BCP, but rather that if a WG decided to use GitHub, this is the best way to do so (I'm still not sure that this really is the best way, but that's just my opinion, and I'm OK being in the rough) W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Change:
DTLS 1.3, the client indicates its version preferences in the "supported_versions" extension (see Section 4.2.1 of TLS13) and the legacy_version field MUST be set to {254, 253}, which was the <del> version number for DTLS 1.2. </del> <ins> version number for DTLS 1.2.  The version fields for DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but the version field for DTLS 1.3 is 0x0304. </ins> Same as for TLS 1.3.

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher <del> Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </del> <ins> Suite, TLS Supported Groups, and TLS Exporters Label registries. Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </ins> Establish Designated Expert pool rules for Specification Required registries.

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
KP: KeyPackage messages <del> W: Welcome messages </del> <ins> GI: GroupInfo objects </ins> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended"

Discussion:
This PR makes a few minor fixes to extensions: Coalesces and into a single extension Adds a list of supported extensions in parallel with the versions and ciphersuites Adds a missing value to the IANA table for the extension
Change:
A timestamp of the request in integer seconds <del> When to bind a request to an access token, the access token hash </del> <ins> When a request is bound to an access token, the access token hash </ins> value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash

Discussion:
Changes field to , adds to DPoP definition for parity with other JOSE signature methods.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fc15fc873432dae90bce38706aa85313d831d419 https://deploy-preview-195--gnap-core-protocol-editors-URL
The signature methods all need to cover the access token, but the DPoP method currently does not. We can add the method used in the and methods.
The FAPI WG is proposing a similar DPoP profile: URL This uses the field instead of , and we could align with that.
Convergence would be helpful, do we know the status of the document?
Is this something that can be standardized in , even as a best practice or recommendation? Trying to align with all documents out there is not a long time strategy...
I've reached out to the OAuth WG on the topic of defining the field in DPoP itself. If that happens we can remove this field from our spec, but until that happens then it makes sense to keep FAPI and GNAP aligned, for now.
Regarding alignment between FAPI and GNAP... DPoP describes "htu" as while GNAP as which obviously isn't the same.
Change:
This document defines QUIC version 1, which conforms to the protocol invariants in QUIC-INVARIANTS. <ins> To refer to QUIC version 1, cite this document.  References to the limited set of version-independent properties of QUIC can cite QUIC- INVARIANTS. </ins> 1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
I don't see much point in doing the same for invariants, but I'm willing to take input on that choice.
The chairs just had a question from someone who wanted to cite "QUIC" on what document they should be citing. We responded that they should cite -transport, since we see this as the central document. Should we add brief notes to the documents saying "if you want to cite QUIC, cite -transport"?
That seems reasonable, since we say in there that accompanying documents describe TLS and recovery. Where are you thinking of adding that note?
As early as possible?
If you want to cite QUIC version 1, transport. If you want to cite QUIC all-up, invariants.
, or immediately after it, seems like as good a place as any.
I probably would have made it part of the preceding paragraph, but I don't feel strongly.
Change:
<del> An unsigned value implementing the DetNet sequence number. </del> <ins> An unsigned value implementing the DetNet sequence number.  The sequence number space is a circular one. </ins> A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence

Discussion:
IESG review comment resolutions in this version: DONE Sabrina Tanamal, IANA, (03-12), OK Michael Tüxen, (03-15), Ready with Issues: Seq.Num.Space Shwetha Bhandari, (03-13), Ready TO BE DISCUSSED: Security section Watson Ladd, SecDir, (03-11), Not Ready Uri Blumenthal, (03-13), Security Deborah, (04-09), decrease authors to 6 !!!
reviewed in April 22 meeting
Change:
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. Clients that want to break continuity of identity with a server MAY <del> discard tokens provided using the NEW_TOKEN frame.  A token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection attempts. A client SHOULD NOT reuse a token in different connections.  Reusing a token allows connections to be linked by entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </del> <ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection attempts. A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.  Reusing a token allows connections to be linked by entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </ins> Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
If decryption fails, the server continues to the next candidate ECHConfig.  Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in encoding-inner.  It then <del> stops considering candidate ECHConfigs. </del> <ins> stops iterating over the candidate ECHConfig values. </ins> Upon determining the ClientHelloInner, the client-facing server then forwards the ClientHelloInner to the appropriate backend server,

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
credentials MUST be ignored. Clients present this Token structure to origins in a new HTTP request <del> using the Authorization header as follows: </del> <ins> using the Authorization header field as follows: </ins> For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate

Discussion:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list
Change:
MAX_STREAMS frames contain the following fields: A count of the cumulative number of streams of the corresponding <del> type that can be opened over the lifetime of the connection. Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAME_ENCODING_ERROR. </del> <ins> type that can be opened over the lifetime of the connection.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1.  Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAME_ENCODING_ERROR. </ins> Loss or reordering can cause a MAX_STREAMS frame to be received which states a lower stream limit than an endpoint has previously received.

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
MAX_STREAMS frames contain the following fields: A count of the cumulative number of streams of the corresponding <del> type that can be opened over the lifetime of the connection. Stream IDs cannot exceed 2^62-1, as it is not possible to encode stream IDs larger than this value.  Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAME_ENCODING_ERROR. </del> <ins> type that can be opened over the lifetime of the connection.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1.  Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a FRAME_ENCODING_ERROR. </ins> Loss or reordering can cause a MAX_STREAMS frame to be received which states a lower stream limit than an endpoint has previously received.

Discussion:
This is based on and is targeted for that. Careful. I did a bit of language tweaking to the 260 limits on the MAX_STREAMS frame to make it a little more useful. The text there was a little old.
Change:
8.1. IANA is requested to Create an entry, encrypted_server_name(0xffce), <del> in the existing registry for ExtensionType (defined in I-D.ietf-tls- tls13), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </ins> 8.2.

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.