jiebi/CodeConvo huggingface dataset:
Change:
(OK, so it's not the biggest contribution I've ever made, but I DID notice it, while reading the master branch ...
This relates to only one typo, so I merge this PR.
Thanks for correcting this!

Discussion:
the packet number.  If multiple packet number spaces are used, the packet number alone would not guarantee the uniqueness of the nonce. <del> In order to guarantee the uniqueness of the None, the nonce N is </del> <ins> In order to guarantee the uniqueness of the nonce, the nonce N is </ins> calculated by combining the packet protection IV with the packet number and with the path identifier.
Change:
fixes issue
Good point but I guess this definition is inline with what's already specified for QUIC given NATs...
Consider adding this entry to the terminology section: This also clarifies the link with "network path" in RFC9000.
PR merged
Note that this definition is different from RFC6182 that required the utilization of at least one different addresses for different subflows. In practice, there were deployments where this requirement was not respected and it was overly conservative.

Discussion:
We assume that the reader is familiar with the terminology used in QUIC-TRANSPORT.  In addition, we define the following terms: <ins> Path: refers to the 4-tuple {source IP address, source port number, destination IP address, destination port number}. A path refers to "network path" used in QUIC-TRANSPORT. </ins> Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is used in multipath control frames (etc.  PATH_ABANDON frame) to
Change:
To estimate path delay accurately, loss recovery of QUIC utilizes the ACK Delay field of ACK frame (see ). However, when single packet number space is being used, it is difficult for the sender to obtain ACK Delay for all the paths being used, because ACK Delay is reported only for the packet carrying the largest packet number. It is the only the ACK delay of the path with shortest path-delay that can be reported. I think it might be a good idea to acknowledge this shortcoming in the documentation, so that we do not miss the downside when we compare the approaches (or when we try to address the shortcomings of the single packet number space approach).
I agree that this issue should be addressed in the current draft. Regarding the problem itself, I think using the one-way timestamp can solve this problem for single PN.
I believe this is discussed in section 5: URL Can you propose a PR if you think more text is useful?!
I think Section 5 should relate to both packet number space designs, while this issue is specific to one. I summarised the discussion in .
We move section 5 from the single packet number section into an own section, as we agreed that it is applicable to both cases as we don't require ack to be send on the same path and the packet was received. I also don't understand the point about being only able to measure the shortest path with a single PN space. It kind of randomly depends on with packet you ack as discussed in section 5. If we want to add some additional consideration we should probably add them to section 5.
Yes, there is an issue with single space here. Suppose that the sender sends packets 1 and later 3 on path long delay path A, packets 2 and later 4 on short delay path B. The receiver will get the packets in the order 2, 1, 4, 2. The ACK will be: ACK, highest = 2. Ack delay = time ACK sent minus time 2 received. ACK, highest = 2, also ACK 1. Ack delay = time ACK sent minus time 2 received. ACK, highest = 4, also ACK 2 and 1. Ack delay = time ACK sent minus time 4 received. ACK, highest = 4, also ACK 3, 2 and 1. Ack delay = time ACK sent minus time 4 received. The RTT of path B will be evaluated precisely, with the help of the ACK delay. The RTT of path A will be evaluated less precisely. When the ACK of 2 and 1 is received, the sender cannot use the ACK delay to narrow the estimate of the RTT of path A. Same for packet 4.
Looks good.

Discussion:
uses a series of consecutive sequence numbers without creating holes. <ins> 7.1.2. The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported host delay will most of the time relate to the path with the shortest latency.  To collect ACK delays on all the paths, hosts should rely on time stamps as described in QUIC-Timestamp. </ins> 7.2. If the multipath option is enabled with a value of 2, each path has
Change:
The sentence above is part of the introduction, but the should is misleading for congestion control at least (we have a MUST for per-path congestion control later). I would suggest to split the above sentence in two parts: Congestion Control must be performed per-path Path MTU should be performed per path We should probably list somewhere in the document the state that must/should be maintained on a per-path basis and the state that is related to the connection. This could clarify some of the mechanisms. Concerning PathMTU, I would suggest to stay with a should and not a must since an implementation could simply track the minimum MTU among the different paths without maintaining per-path MTU. Such an implementation would work and if the MTUs do not differ significantly, it would probably be simpler than an implementation than maintains per-path MTU and needs to adjust the packets based on the path where each packet is sent. Concerning RTT, we discuss the problem of measuring the RTT later with the packet number spaces discussion. Furthermore, some congestion control schemes need an accurate per-path RTT while others do not strictly require rtt estimations.
NAME this "should" in the intro was not meant to be normative. However, I anyway created PR to clarify. However, I didn't address your point about having a list of all state. Do we really need that? If so, where does that below? A new section somewhere? Can you provide such a list or create a PR? Or should we open a new separate issue for that?
I agree that specifying PMTUD per path is a good idea. We do have a slight ambiguity, because the draft uses the overlapping notions of "path" and "number space", with the number space tied to the DCID of packets. The DCID may change over time for privacy reasons, or because the server wants to retire old CIDs tied to a previous configuration of the load balancer. In these cases, there is no need to restart PMTUD or reset congestion control.

Discussion:
risk of packets being dropped by middleboxes (which may only support QUIC version 1) <del> Congestion Control, RTT measurements and PMTU discovery should be per-path (following QUIC-TRANSPORT) </del> <ins> Congestion Control must be per-path (following QUIC-TRANSPORT) which usually also requires per-path RTT measurements PMTU discovery should be performed per-path </ins> A path is determined by the 4-tuple of source and destination IP address as well as source and destination port.  Therefore there
Change:
The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.)

Discussion:
This is a request for the entire body. This is used to confirm that the current set of MAX_PAYLOADS <del> payloads have been successfully received and that, upon receipt, the peer can continue to sent the next set of payloads.  This is the 'Continue' Q-Block-2. </del> <ins> payloads (the latest one having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next set of payloads (the first one having block number NUM).  This is the 'Continue' Q-Block-2. </ins> <del> This is a request for the remaining payloads in the current MAX_PAYLOADS set. </del> <ins> This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set. </ins> If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and later blocks) and

these missing blocks is as follows: The token to use for the response SHOULD be the token that was used <del> in the highest block number received payload.  Note that the use of any received token would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to match the request to find what Request- Tag value is currently being used. </del> <ins> in the highest block number received so far with the same Request-Tag value.  Note that the use of any received token with the same Request-Tag would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used. </ins> If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 RFC7252, then the number
Change:
Truly, the most interesting forwarding is what occurs at the Oblivious Request Resource, but this is a point of inflexibility that some people struggle with. No point in hiding how we might intend for a generic proxy to operate. The alternatives people invent are likely to be worse if we don't at least point in the rough direction of a good solution.
Resource and the Oblivious Request Resource. This means that any encapsulated request sent to the Oblivious Proxy Resource will always be forwarded to the Oblivious Request Resource. This constraint was imposed to simplify proxy configuration and mitigate against the Oblivious Proxy Resource being used as a generic proxy for unknown Oblivious Request Resources. The proxy will only forward for Oblivious Request Resources that it has explicitly configured and allowed. This seems like it's pretty inflexible. I wonder if maybe a compromise would be some kind of URL pattern?
I agree that it's written as very inflexible — I'd be happy to see this change for wording. I've personally interpreted this, though, to mean that the mapping could coincide with a URI template, but it's up to the proxy of what to do. So, one proxy could say: maps to But another could say: maps to Both of these are 1:1 technically. The latter case needs to be careful that it has correct ACLs to not allow arbitrary access, but it's still a mapped resource.
Yes, I think this explanation does a lot to clarify the possible approaches.

Discussion:
It is possible for a server to be configured with multiple Oblivious Proxy Resources, each for a different Oblivious Request Resource as <del> needed. </del> <ins> needed.  If the goal is to support a large number of Oblivious Request Resources, clients might be provided with a URI template TEMPLATE, from which multiple Oblivious Proxy Resources could be constructed. </ins> 9.3.
Change:
cc NAME
Alt-Used sticks out to me. So I looked for whether Alt-Svc is some prerequisite for oblivious HTTP and it doesn't seem so. I'm not sure many folks would be that familiar with Alt-Used, ? Is there some other, more familiar, filed that you could use as an example?

Discussion:
encapsulated request: a method of POST, a target URI of the oblivious proxy resource, a header field containing the content type (see (media-types), and the encapsulated request as the request content. <del> Clients MAY include fields that do not reveal information about the content of the request, such as Alt-Used ALT-SVC, or information that it trusts the oblivious proxy resource to remove, such as fields that are listed in the Connection header field. </del> <ins> In the request to the oblivious proxy resource, clients MAY include additional fields.  However, those fields MUST be independent of the encapsulated request and MUST be fields that the oblivious proxy resource will remove before forwarding the encapsulated request towards the target, such as the Connection or Proxy-Authorization header fields SEMANTICS. </ins> The client role in this protocol acts as an HTTP client both with respect to the oblivious proxy resource and the oblivious target
Change:
URL a partial one. From IETF 114: I don't know if it is worth enumerating all of the combinations is viable, but we might consider talking about the exact shape of the consistency requirements here.

Discussion:
by matching KeyConfig.key_id, or, if the Target Resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An Oblivious Relay Resource can link requests <del> using the public key corresponding to KeyConfig.key_id. Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. Specifically, servers can maliciously construct key configurations to track individual clients.  A specific method for a client to acquire key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations to mitigate tracking using key configurations.  CONSISTENCY provides an analysis of the options for ensuring the key configurations are consistent between different clients. </del> <ins> using the public key corresponding to KeyConfig.key_id or via the URI of the Oblivious Gateway Resource.  We refer to this set of information as the gateway's configuration. Whether or not targets can link requests depends on how gateway configuration information is produced and discovered by clients. Specifically, gateways can maliciously construct configurations to track individual clients. Ideally, all clients share a consistent view of the gateway configuration.  The number of different valid configurations can exponentially partition the anonymity set of clients.  For example, if there are two valid configurations, that would yield two anonymity sets consisting of clients that used one configuration and clients that used the other configuration.  If the size of each set is large enough, this may not be a significant loss of privacy in practice. Ensuring that many clients share a configuration is necessary to provide privacy for clients. A specific method for a client to acquire configurations is not included in this specification.  Applications using this design MUST provide accommodations to mitigate tracking using gateway configurations.  CONSISTENCY provides options for ensuring that configurations are consistent between clients. </ins> 9.
Change:
The text noted in was correct, but we didn't have a single place where we outlined this as a direct requirement. The day where HTTP presupposes TLS has come for some, but not all of us. Until then, we can be more careful.
The document uses the term TLS connection(s) in four places: My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care. Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. URL states many requirements but not the use of HTTPS. That seems implicit via URL However, that seems in conflict with URL, which says In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.

Discussion:
A server operates both the Oblivious Gateway Resource and the Target Resource <ins> Connections between the client, Oblvious Relay Resource, and Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.  The scheme of the encapsulated request detemrines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> To achieve the stated privacy goals, the Oblivious Relay Resource cannot be operated by the same entity as the Oblivious Gateway Resource.  However, colocation of the Oblivious Gateway Resource and

6.2.3. <del> This document assumes that all communication between different Oblivious Client, Oblivious Relay Resource, and Oblivious Gateway Resource is protected by HTTPS.  This protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, it does not mitigate traffic analysis by such network observers. </del> <ins> Using HTTPS protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay.  However, using HTTPS does not prevent traffic analysis by such network observers. </ins> The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages
Change:
In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though

Discussion:
string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes. <del> Formats are described using notation from QUIC. </del> <ins> Formats are described using notation from QUIC.  An extension to that notation expresses the number of bits in a field using a simple mathematical function. </ins> 3.

request describes the process for constructing and processing an Encapsulated Request. <del> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </del> <ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt.

content.  response describes the process for constructing and processing an Encapsulated Response. <del> The Nenc and Nk parameters corresponding to the HpkeKdfId can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes; Nk refers to the size of the AEAD key for the HPKE ciphersuite, in bits. </del> <ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The Encapsulated Response nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.1.
Change:
Section 4.2, prose says whereas the pseudo-code says
A few things here should improve readability: key -> aeadkey, nonce -> aeadnonce, then we should be sure to pass the response in rather than the request.
Nice catch on s/request/responseLGTM

Discussion:
Use the "Expand" function provided by the same KDF to extract an AEAD key "key", of length "Nk" - the length of the keys used by <del> the AEAD associated with "context".  Generating "key" uses a label of "key". </del> <ins> the AEAD associated with "context".  Generating "aead_key" uses a label of "key". </ins> Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD. <del> Generating "nonce" uses a label of "nonce". </del> <ins> Generating "aead_nonce" uses a label of "nonce". </ins> Encrypt "response", passing the AEAD function Seal the values of <del> "key", "nonce", empty "aad", and a "pt" input of "request", which yields "ct". </del> <ins> "aead_key", "aead_nonce", an empty "aad", and a "pt" input of "response", which yields "ct". </ins> Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-
Change:
Not even once, down from two. Using cookies is dumb, but we don't need to ban them so directly. There are tons of ways in which information from a previous request might leak across into the current one. The point is to highlight the risk of using them. A direct prohibition doesn't make sense if the use of the cookie is well understood (not that attaining such an understanding is likely to be easy).
In Section 6.1, the document states twice, in the space of two paragraphs, that clients MUST NOT use cookies. That seems a little excessive.
I'm OK with this relaxation. Clients who want to use OHTTP will presumably not do the dumb thing.

Discussion:
difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. <del> Clients MUST NOT include identifying information in the request that is encrypted.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </del> Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the <del> Oblivious Relay resource.  However, clients need to ensure that they construct requests without any information gained from previous requests.  Otherwise, the server might be able to use that information to link requests.  Cookies COOKIES are the most obvious feature that MUST NOT be used by clients.  However, clients need to include all information learned from requests, which could include the identity of resources. </del> <ins> Oblivious Relay resource.  However, the content of requests might be used by a server to correlate requests.  Cookies COOKIES are the most obvious feature that might be used to correlate requests, but any identity information and authentication credentials might have the same effect.  Clients also need to treat information learned from responses with similar care when constructing subsequent requests, which includes the identity of resources. </ins> Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not