jiebi/CodeConvo huggingface dataset:
Change:
8.1. A sender needs to be responsive to notifications of congestion, such <del> as a packet loss or an ECN CE marking.  To enable a sender to respond to potential network congestion in a timely fashion, usually at least one acknowledgement per round trip is needed if there are unacknowledged ack-eliciting packets in flight.  A sender can accomplish this by setting the Ack-Eliciting Threshold to a value no larger than the current congestion window or the Request Max Ack Delay value to no more than the estimated round trip.  Note that the congestion window particularly but also the RTT are dynamic and therefore might require frequent updates if the selected value are close to these limits.  Alternatively, a sender can accomplish this by sending an IMMEDIATE_ACK frame once per round trip, though if the packet containing an IMMEDIATE_ACK is lost, detection of that loss will be delayed by the reordering threshold or requested max ack delay. Note that it is possible that the RTT is smaller than the receiver's timer granularity, as communicated via the 'min_ack_delay' transport </del> <ins> as a packet loss or an ECN CE marking.  Decreasing the acknowledgement frequency can delay a sender's response to network congestion or cause it to underutilize the available bandwidth. To limit the consequences of reduced acknowledgement frequency, a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack-eliciting packets in flight. A sender can accomplish this by setting the Ack-Eliciting Threshold to a value no larger than the current congestion window or the Request Max Ack Delay value to no more than the estimated round trip. Alternatively, a sender can accomplish this by sending an IMMEDIATE_ACK frame once per round trip, though if the packet containing an IMMEDIATE_ACK is lost, detection of that loss will be delayed by the reordering threshold or requested max ack delay. Note that the congestion window and the RTT are dynamic and therefore might require sending frequent ACK_FREQUENCY frames to ensure optimal performance. It is possible that the RTT is smaller than the receiver's timer granularity, as communicated via the 'min_ack_delay' transport </ins> parameter, preventing the receiver from sending an acknowledgment <del> every RTT in time.  In these cases, Reordering Threshold values other than 1 can be harmful, because it delays fast loss detection. </del> <ins> every RTT in time unless packets are acknowledged immediately. Additionally, Reordering Threshold values other than 1 can be harmful, because it can delay loss detection more than an RTT. </ins> A congestion controller that is congestion window limited relies upon receiving acknowledgements to send additional data into the network.

Discussion:
We had similar text in the two sections, and the latter one was where the SHOULD was, so this consolidates the duplicate text into the Congestion Control section. This is intended as an editorial cleanup prior the the PR for
Change:
of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system, <del> an application can define Connection Contexts to control caching boundaries, as discussed in conn-context. </del> <ins> an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in conn-context. </ins> 4.2.

Discussion:
URL In this section - can we be clear on stating what properties we are taking about and what the caches. see the first line of the section. the second paragraph should at least mention why the connection is cloned. We haven't introduced the cloning before. we need to discuss the relation with Connection Context, does a Connection group have same connection context? My current understanding is if the Connection Context is separate then those Connections wont be grouped. But I fear that this can create confusion.
Latest merged master fixes bullet 2. The others need new text.
LGTM! Many thanks for doing this
Change:
given endpoint name.  This applies both to registration and later to operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the <del> registration: The RD can not tell the difference, and CTs may use </del> <ins> registration: The RD cannot tell the difference, and CTs may use </ins> authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names.

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
use a pre-shared key and validated the client's pre-shared key binder; see Section 4.2.11 of TLS13. <del> The client has not demonstrated liveness, unless a RETRY packet was used. </del> <ins> The client has not demonstrated liveness, unless the server has validated the client's address with a Retry packet or other means; see Section 8.1 of QUIC-TRANSPORT. </ins> Any received 0-RTT data that the server responds to might be due to a replay attack.

Discussion:
Three minor changes here; separate if needed: The section title refers to frames, but the content discusses packets The text refers to a RETRY packet; packet types are not shouting-case Retry is not the only way to verify liveness prior to handshake completion (e.g. Connection ID on packets with a multi-round-trip handshake); reference to address validation for more context
Change:
out-of-order sub-requests by ignoring any sub-request that does not follow the previous one (See anti-replay.) <del> The response consists of the helper's updated state and a sequence of </del> <ins> The response is an HTTP 200 OK with a body consisting of the helper's updated state and a sequence of </ins> , where the i-th sub-response corresponds to the i-th sub-request for each i.  The structure of each sub-response is specific to the PPM

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .
Change:
minimum), additional data exchanged, and additional CPU cost of cryptographic computations. <del> To overcome these limitations, this document defines how binary HTTP messages BINARY can be encapsulated using Hybrid Public Key Encryption (HPKE; HPKE) to protect their contents.  exchange these messages with an , which is responsible for forwarding decapsulated requests to the original and encapsulating the corresponding responses and sending them back to the client.  Critically, encapsulated messages are sent through a separate to avoid exposing the client's IP address or allowing the connection to be used as a correlator between its requests. Because it allows connection reuse between the client and , as well as between that relay and the , this scheme represents a performance improvement over using just one request in each connection.  With limited trust placed in the (see security), are assured that requests are not uniquely attributed to them or linked to other requests. </del> <ins> To overcome these limitations, this document defines Oblivious HTTP, a protocol for encrypting and sending HTTP messages from a client to a gateway through a trusted relay service.  In particular, the protocol in this document describes: an algorithm for encapsulating binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE) to protect their contents, a method for forwarding these encapsulated messages between clients and an through a trusted using HTTP, and requirements for how the handles encapsulated HTTP messages and produces encapsulated responses for the client. The combination of encapsulation and relaying ensures that never sees the client's IP address and the never sees plaintext HTTP message content. Oblivious HTTP allows connection reuse between the client and , as well as between that relay and the , so this scheme represents a performance improvement over using just one request in each connection.  With limited trust placed in the (see security), are assured that requests are not uniquely attributed to them or linked to other requests. </ins> 2.

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:
Produces: Appraisal Policy for Evidence A role performed by an entity (typically a manufacturer) whose <del> Endorsements help Verifiers appraise the authenticity of Evidence. </del> <ins> Endorsements may help Verifiers appraise the authenticity of Evidence and infer further capabilities of the Attester. </ins> Produces: Endorsements

Discussion:
Align Section 8.2 with the definition in Section 4.2 Relax the definition of Endorser in Section 4.1 to drop the exclusive coupling between Endorsements and authenticity appraisal
In §4.2 Endorsement is defined as: "A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and Evidence signing." uses a more restrictive description: "An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing capability.", which seems to limit the scope of an Endorsement to the verification of the Attester's signature on Evidence. I think §8.2 should be rephrased to align with §4.2 so to allow Endorsements to be more than just verification keys. Besides, the definition of Endorser in §4.1: "[…] Endorsements help Verifiers appraise the authenticity of Evidence" could be relaxed to drop the (seemingly) exclusive coupling of Endorsements with authenticity appraisal.
+1 Re: §4.1 the alignment of "Endorsements" with "Evidence" seems overly constraining since Reference Values are expected to match Evidence while Endorsements are not expected to be compared to Evidence. The wording "authenticity of Evidence" is what Endorsements qualify but that is too narrow as it could also appraise other Attesting Environment functionality such as Claims Collection, key generation, signing as well as launching code, transitioning to other environments, storing secrets and there could be more.
Huh. I checked both sections and... I think you both might be right here. While it's not the intent of Section 8.2, factually it seems to be artificially constraining (by accident?). I have to admit, I did not catch that discrepancy. My initial assessment is that - as we took great care with the "normative anchor" that is Section 4.2 - we did not pay enough attention to align Section 8.2 with that. Taking into account NAME and NAME assessment, I think this is an editorial issue. Could NAME please provide a proposal and NAME please review that first, so that we can address this issue along the upcoming next review phase.

This action depends on this change remaining to be a editorial harmonization (again, which I think it is). If there are any counter indications that this is bordering on normative impact, please highlight so.
"In some cases, an Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing capability."
reads good to me
Change:
Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation <del> details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. </del> <ins> details.  API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. </ins> Each protocol has a notion of Connectedness.  Possible values for Connectedness are:

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
Change:
If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the <del> Transport Parameters actually work over the available paths, then the </del> <ins> Transport Properties actually work over the available paths, then the </ins> transport system should notify the application with an InitiateError event.  An InitiateError event should also be generated in case the transport system finds no usable candidates to race.

Discussion:
Implementation draft sec 3: "In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment." I don't understand these two sentences. In the API doc it seems we use the term Transport Properties for both selection and configuration properties. Why do we only talk about selection properties in this doc? Also in the next sentence what's meant by "objects and properties"? I guess the object(s) that hold the properties? But then this is saying twice the same and we should only use one term to avoid confusion.
Also in the next section 3.1: "Once an application specifies its Transport Parameters" I guess that should be Transport Properties instead? Maybe it would also be good to say here "Once an application specifies its Transport Properties and Preference (required, prefer, ignore, avoid, prohibit - see section 5.2. of [draft-taps-arch])".
I agree; I suspect that this is ancient leftover text that should be cleaned up.
Some small changes suggested
Change:
acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying <del> packets based on packet size are likely to fail, and are not </del> <ins> packets based on packet size are very likely to fail, and are not </ins> recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions.

Discussion:
I set the ready to merge label but there are merge conflict, so please don't merge before accepting my suggestions...
[Ding2015] and [IPIM] are in the references of the manageability draft, but aren't actually... referenced anywhere. That suggests either some text is missing or these entries are spurious.
Yes this has been already flagged by and is fixed in (which we will all merge on Monday when Brain is back). Thanks anyway!
Unused Reference: 'Ding2015' is defined on line 1272, but no explicit reference was found in the text Unused Reference: 'IPIM' is defined on line 1293, but no explicit reference was found in the text
Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'.
There are two paragraphs that include 2119-language: RFC 2119 keyword, line 578: '... RECOMMENDED. First, it only provid...' RFC 2119 keyword, line 969: '... NOT RECOMMENDED....' Should these be made lowercase or is a 2119 paragraph needed?
I see what was done. Looks ready to go.
Change:
appropriate.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could <del> alter the internal state of the client.  However, a careful analysis of any potential attacks to the security and privacy properties of the system might reveal that there are cases where such cryptographic protections do not add value in a specific case. </del> <ins> alter the internal state of the client.  It is this reason that at least the use of integrity protection on the token is always recommended. It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value.  The authors of this document have not found such a use case as yet. </ins> RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence number and a replay window.  Where encryption is not needed, RFC6234,

Discussion:
… into more positive language
[[TODO]]
Not sure I follow the 5077 analogy. Do we ever plan to use stateless without some integrity protection? We might save a lot of weasel-wording by simply requiring it.
Change:
identifier for that key and the HPKE algorithms that are used with that key. <del> The identity of an that will accept relay requests carrying an encapsulated request as its content and forward the content in these requests to a single . See proxy-state for more information about the mapping between . </del> <ins> The identity of an that will accept relay requests carrying an as its content and forward the content in these requests to a single . See proxy-state for more information about the mapping between . </ins> This information allows the to make a request of a with that resource having only a limited ability to correlate that request with the IP

Discussion:
We weren't always capitalizing "Encapsulated Request". This does more, in direct opposition to the changes in . If we don't take that (it seems we at an impasse there), then we should at least be consistent.
NAME I resolved conflicts, but please double check the intro paragraph that had Mark's proposed changes.
Change:
8. <ins> This document makes multiple registrations in the registries defined by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following

Discussion:
RFC-to-be 9114 (draft-ietf-quic-http) includes the following note to indicate that the registrations have a status of permanent and the Change Controller is the IETF. Should a similar statement be included in this document? From RFC-to-be 9114: The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (EMAIL). In addition, note that the padding in the Settings, Stream Types, and Error Codes differs from what appears in the IANA registry. IANA included the following note when they notified us that their actions for RFC-to-be 9114 were complete: NOTE: In the new registries, the padding has been adjusted for consistency from one registry to another and with URL We understand that there may be a request to change it. We have asked Mike (as editor of RFC-to-be 9114) to review, as the padding for the HTTP/3 registries is now inconsistent with the padding for the HTTP/2 registries. Please review and dicuss and let us know if any updates are needed.
Fixed in .
The QUIC registry policies, imported to HTTP/3, specify that a change controller and their contact information should be listed with each permanent registration. QPACK doesn't provide one, though almost certainly it should be the HTTP WG.
Change:
<del> QPACK: Header Compression for HTTP over QUIC </del> <ins> QPACK: Header Compression for HTTP/3 </ins> draft-ietf-quic-qpack-latest Abstract

Discussion:
It seems appropriate given that the term is used elsewhere in the text. However, I am sorry if there is a specific reason for keeping "HTTP over QUIC" here.
This matches HPACK (Header Compression for HTTP/2), so sure. I guess if we use vanilla QPACK for HTTP/4+ people will figure it out. circleci failed but the error appears unrelated.
Thanks.
Change:
The WT_STOP_SENDING frame defines the following fields: <del> Stream ID: A variable-length integer carrying the WebTransport stream ID of the stream being ignored. </del> <ins> A variable-length integer carrying the WebTransport stream ID of the stream being ignored. </ins> <del> Application Protocol Error Code: A variable-length integer containing the application-specified reason the sender is ignoring the stream. </del> <ins> A variable-length integer containing the application-specified reason the sender is ignoring the stream. </ins> 5.4.

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
iana-considerations. Note: Values listed as RESERVED MUST NOT be used.  They were used in <del> SSLv3. </del> <ins> SSL 3.0. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Discussion:
Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.