jiebi/CodeConvo huggingface dataset:
Change:
201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body. <del> The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </del> <ins> 6.4.1. To prove control of the identifer and receive authorization, the client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type,

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
If the certificate_extensions list in the CertificateRequest message was non-empty, the end-entity certificate MUST match the <del> extension OIDs recognized by the client, as described in certificate-request. </del> <ins> extension OIDs recognized by the client, as described in oid- filters. </ins> Note that, as with the server certificate, there are certificates that use algorithm combinations that cannot be currently used with

Discussion:
This was the one extension that wasn't in the extensions section, which made it hard to find. Note I've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text.
Does the part that says need to be updated to point to this new location instead of {{certificate-request}}?
Good catch. Fixed.
lgtm
merge this when ready
Change:
This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST <del> NOT be sent by compliant implementations. </del> <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A TLSCiphertext record was received that had a length more than

Discussion:
Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.
Change:
The helper handles each sub-request "PAAggregateSubReq" as follows. It first checks that checks that "PAAggregateSubReq.proto == PAParam.proto".  If not, it aborts and alerts the leader with <del> "incorrect protocol for sub-request".  Otherwise, It computes the </del> <ins> "incorrect protocol for sub-request".  Otherwise, it computes the </ins> HPKE context as where "sk" is its HPKE key and computes the body of the

Discussion:
Partially addresses via clarification. Intra-batch replay attacks need more text.
NAME I was going to file a separate issue to discuss it. Stay tuned!
Currently, clients specify the report timestamp when uploading a report for a task. Presumably this timestamp is used to determine the window/batch in which a report is aggregated. Do we care if clients can spoof or change this timestamp to put reports into different batches? Since clients have no understanding of what batch their report goes into, and this is something that aggregators manage, perhaps we should drop this and let the aggregators figure out the report<>batch grouping?
Yes, that's the idea. We have no way of ensuring that the client doesn't lie about the timestamp. This "attack" is akin to the client just lying about the input itself (see ): It's something we can't do anything about, short of using a secure enclave on the client's machine. I think dealing with these problems is orthogonal to the spec here. On the other hand, it should our goal to allow an honest aggregator to ensure that each report appears in most one batch. The timestamp and batch window is intended to allow an honest aggregator to manage this reportbatch mapping efficiently, i.e., with minimal state between aggregate requests. Unless we can think of a better way, I think we should keep this in.
This issue is now subsumed by .
Might be worth adding an OPEN ISSUE to note the inter-batch replay attack we talked about yesterday.
Change:
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. <ins> 7.2. A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI.  This is described in coaps-ws-scheme. The client MUST perform a TLS handshake after opening the connection to the server.  The guidance in Section 4.1 of RFC6455 applies.  When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of RFC7925 applies towards mandatory-to- implement TLS functionality for certificates.  For the server-side requirements in accepting incoming connections over a HTTPS (HTTP- over-TLS) port, the guidance in Section 4.2 of RFC6455 applies. </ins> 8. The security considerations of RFC7252 apply.  For CoAP over

Discussion:
NAME - can you review (don't see you in the Reviewers list)?
Referencing , I have these comments: I feel the text in Section 7 discussing security solutions pertains to both TCP as well as WebSockets, and therefore propose the following amendment: "A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate." In addition I have the following suggestion for a new subsection as follows: A CoAP client requesting a resource identified by a “coaps+ws” URI negotiates a secure WebSocket connection to a WebSocket server endpoint, with a “wss" URI. This is described and depicted in section 6.4. As provided by the guidance in Section 4.1 of [RFC6455], the client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates, when a CoAP server exposes resources identified by a “coaps+ws” URI. For the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies.
Minor. Regarding for the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies .... RFC6455 actually refers to an HTTPS (HTTP-over-TLS) port in this section:
Thanks Brian, this is ok with me
Change:
request-authentication).  The inner JWS MUST meet the normal requirements, with the following exceptions: <del> The inner JWS MUST have the same "url" parameter as the outer JWS. </del> <ins> The inner JWS MUST have the same "url" header parameter as the outer JWS. </ins> <del> The inner JWS is NOT REQUIRED to have a "nonce" parameter.  The server MUST ignore any value provided for the "nonce" header </del> <ins> The inner JWS is NOT REQUIRED to have a "nonce" header parameter. The server MUST ignore any value provided for the "nonce" header </ins> parameter. This transaction has signatures from both the old and new keys so

Discussion:
This pull request includes changes to: Consistently use "header parameter" when referring to JWS header parameters. Insert a missing right curly bracket in a section reference. Use "server-initiated" instead of "administratively initiated" for clarity. Use parallel sentence structure for clarity/readability.
Change:
size for every QUIC version it supports. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCIL field to match. </del> <ins> its choosing and sets the SCIL field to indicate the length. The first flight of 0-RTT packets use the same Destination and Source Connection ID values as the client's first Initial. </ins> The Destination Connection ID field in the server's Initial packet contains a connection ID that is chosen by the recipient of the

Discussion:
For and NAME
Thanks
Note that section 17.2.3. 0-RTT does not mention 0-RTT CID but the following section 7.2.4. Handshake Packet does mention Handshake CID's. In existing draft.
LGTM, given the incorporated changes.
Change:
more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as <del> described in HTTP2, Section 8.1.2.5. </del> <ins> described in Section 8.1.2.5 of HTTP2. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A

Discussion:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1
Change:
Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism <del> necessary to negotiate the format of that content over the lifetime </del> <ins> necessary to determine the format of that content over the lifetime </ins> of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- <del> D.mahy-mls-content-neg, unless the specific application defines </del> <ins> D.mahy-mls-content-adv, unless the specific application defines </ins> another mechanism which more appropriately addresses the same requirements for that application of MLS.

Discussion:
Made minor changes to the section of content and framing. Updated reference draft-mahy-mls-content-neg -> draft-mahy-mls-content-adv The recommended mechanism is advertising content/media types, not a full negotiation mechanism.
Change:
field; and the public key for its DH or ECDH key pair is placed in the "dh" <del> parameter of the Encryption-Key header field. </del> <ins> parameter of the Crypto-Key header field. </ins> An application server MUST encrypt a push message with a single record.  This allows for a minimal receiver implementation that <del> handles a single record.  If the message is 4096 octets long, or longer, this means that the "rs" parameter MUST be set to a value that is longer than the encrypted push message length. </del> <ins> handles a single record.  If the message is 4096 octets or longer, the "rs" parameter MUST be set to a value that is longer than the encrypted push message length. </ins> Note that a push service is not required to support more than 4096 octets of payload body, which equates to 4080 octets of cleartext, so

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:
bitrate. Here are a few common resolutions used for video content, with <del> typical ranges of bitrate for the two most popular video codecs </del> <ins> typical ranges of bitrates for the two most popular video codecs </ins> Encodings. 2.1.2.

Discussion:
Merged after discussion with NAME ...
This was a brillant ideq, and has worked in other groups, but I can't remember any contribution that was made using this template ...
We should probably talk about how to update This document aims to provide a taxonomy of networking issues as they relate to quality of experience in internet video delivery. The focus is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. NAME might suggest this (but didn't put it in -05): This document focuses is on capturing characteristics of video delivery that have surprised network designers or transport experts without specific video expertise, since these highlight key differences between common assumptions in existing networking documents and observations of video delivery issues in practice. Thoughts from NAME or NAME
Sure, that works for me.
Change:
receive similar treatment regardless of why they're unroutable: The config rotation bits (config-rotation) may not correspond to <del> an active configuration.  Note: a packet with a DCID that indicates 5-tuple routing (see config-failover) is always routable. </del> <ins> an active configuration.  Note: a packet with a DCID with config ID codepoint 0b11 (see config-failover) is always routable. </ins> The DCID might not be long enough for the decoder to process.

Discussion:
The '11' codepoint might be better defined. It would be good, for instance, if a stateful load balancer actually stored the observed CID so that the connection can survive a NAT rebinding.
Actually this is a bit harder than we'd like. If the load balancer is stateless, then the short-header processing would have to be based on the destination connection ID to be robust to NAT rebinding. But then, as the connection ID will change mid-handshake, long-header processing needs a different approach. I don't see how, logically, a stateless LB can maintain consistency between these two results unless we force the unconfigured server to retain most of the client-generated CID.
Having reflected on this a bit more, this is what I think we should do: Keep 0b11 as 4-tuple routing. However Load Balancers MAY observe destination connection IDs and keep state on them, to later survive a NAT rebinding. I see two use cases for 0b11: (1) a general purpose server that always uses QUIC-LB, whether or not it's behind an LB, for simplicity. So when it's not behind a Layer 4 LB it just generates random CIDs except for the first byte. As an added bonus, if there is an unknown L4 LB in front of it the behavior will not be pathological, at least until there's a migration. But in general, the rebinding performance is not all that important. (2) As a panic mode when things are misconfigured or the server has run out of nonces. Again, I'm not sure rebinding performance is super-critical. In other words, if a server is behind an L4 load balancer is and is using 0b11, something has gone very wrong.
Change:
of the connection's RTT.  An endpoint computes the following three values: the minimum value observed over the lifetime of the connection (min_rtt), an exponentially-weighted moving average <del> (smoothed_rtt), and the variance in the observed RTT samples (rttvar). </del> <ins> (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 4.1.

Discussion:
It's a mean deviation. This has confused at least one reader.
True-ish, but nor is smoothed_rtt a mean. And now you have a variable with a name that bears no semblance to the concept you use to describe it. You could instead play apologist and explain that this isn't a variance in the statistical sense, but variance in a purely colloquial sense.
Section 2 of RFC2988 says "To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation)." It does subsequently use the term variance in one spot, but given the original definition is a better one, I'd rather use variation than variance. RFC6298 does the exact same thing, and defines RTTVAR as "round-trip time variation".
In both sentences, minrtt and smoothedrtt are described in technically accurate terms, so I think it makes sense to describe rttvar as a mean deviation, because that's the most technically accurate term. I also understand the need for consistency, so if you have suggestions on how to improve that without removing the technical description, it'd be appreciated.
Change:
header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <del> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </del> A direction attribute which is the same as that of the associated transceiver.

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
(see external-senders-extension).  The "content_type" of the message MUST be "proposal". <del> "new_member": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". </del> <ins> "new_member_commit": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". "new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The "content_type" of the message MUST be "proposal"and the "proposal_type" of the Proposal MUST be "add". </ins> Recipients of an MLSMessage MUST verify the signature with the key depending on the "sender_type" of the sender as described above.

Discussion:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.
Change:
8.2. Attackers in this privileged position are intrinsically able to map <del> two connection IDs to the same server.  The QUIC-LB algorithms do prevent the linkage of two connection IDs to the same individual connection if servers make reasonable selections when generating new IDs for that connection. </del> <ins> two connection IDs to the same server.  These algorithms ensure that two connection IDs for the same connection cannot be identified as such as long as the server chooses the first octet and any plaintext nonce correctly. </ins> 8.3.

Discussion:
I would think that you instead want to say if the nonce part is chosen in a manner that is unpredictable to the adversary, or encrypted.
Change:
When multiple sets of outgoing F-Labels or interfaces are provisioned for a particular DetNet service, a copy of the outgoing packet, <del> including the pushed S-Label, MUST be made per F-label set and outgoing interface.  Each set of provisioned F-Labels are then pushed onto a copy of the packet.  Each copy is then forwarded as described below in f-labels-all. </del> <ins> including the pushed member flow-specific S-Label, MUST be made per F-label set and outgoing interface.  Each set of provisioned F-Labels are then pushed onto a copy of the packet.  Each copy is then forwarded as described below in f-labels-all. </ins> As described in the previous section, when receiving a DetNet MPLS flow, an implementation identifies the DetNet service associated with

Discussion:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).
Change:
8.1. <del> The PATH_ABANDON frame informs the peer to abandon a path.  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </del> <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. 8.2. The PATH_ABANDON frame informs the peer to abandon a path. </ins> PATH_ABANDON frames are formatted as shown in fig-path-abandon- format.

Discussion:
The ACKMP text does not change, it just comes before PATHABANDON and PATHSTATUS. The rationale is that 1) the new order follows the encoding numbering (lowest to highest), and 2) the ACKMP is a critical frame, the PATHABANDON is an important one yet still "indicative" (it suggests the peer to abandon this path) and the PATHSTATUS frame is an indicative one.
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
OK. It's reasonable.
Change:
participants know that at least one aggregator is defective, and it may be possible to identify the defector (i.e., if a majority of runs agree, and a single aggregator appears in every run that disagrees). <del> See #22 [2] for discussion. </del> <ins> See #22 [1] for discussion. </ins> 6.7.

Discussion:
This is just converting to defn. list format. I'm going to submit a separate PR to clean up the contents.