jiebi/CodeConvo huggingface dataset:
Code change:
URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?

Related discussion:
text: 12.2. A group member creating a commit and a group member processing a <del> commit MUST verify that the list of committed proposals is valid </del> <ins> Commit MUST verify that the list of committed proposals is valid </ins> using one of the following procedures, depending on whether the <del> commit is external or not. </del> <ins> commit is external or not.  If the list of proposals is invalid, then the Commit message MUST be rejected as invalid. </ins> For a regular, i.e. not external, commit the list is invalid if any of the following occurs:
Code change:
The draft states that Shouldn't be the result 6b2611489cba2b63a9e873e2 instead of 6b2611489cba2b63a9a873e2?
Yes, I submitted PR for this issue.

Related discussion:
text: For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the connection ID sequence number is "3", and the packet number is <del> "aead", the nonce will be set to "6b2611489cba2b63a9a873e2". </del> <ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". </ins> 6.3.2.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multipath control frames (etc.  PATH_ABANDON frame) to identify a path.  The Path ID is defined as the sequence number of the destination Connection ID used for sending packets on that particular path. Packet Number Space Identifier (PNS ID): An identifier that is used to distinguish packet number spaces for different paths.  It is used in 1-RTT packets and ACK_MP frames.  Each node maintains a list of "Received Packets" for each of the CID that it provided to the peer, which is used for acknowledging packets received with that CID. The difference between Path Identifier and Packet Number Space Identifier, is that the Path Identifier is used in multipath control frames to identify a path, and the Packet Number Space Identifier is used in 1-RTT packets and ACK_MP frames to distinguish packet number spaces for different paths.  Both identifiers have the same value, which is the sequence number of the connection ID, when a new path is established. The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC- TRANSPORT. </del> <ins> used in multipath control frames (e.g., PATH_ABANDON frame) to identify a path.  The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC-TRANSPORT that is used for sending packets on that particular path. </ins> 2.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: Associated Destination Connection ID: The Connection ID used to send packets over the path. <del> If multiple packet number spaces are used over the connection, hosts MUST also track the following information. </del> <ins> In Active state, hosts MUST also track the following information: </ins> <del> Path Packet Number Space: The endpoint maintains a separate packet number for sending and receiving packets over this path.  Packet number considerations described in QUIC-TRANSPORT apply within the given path. </del> <ins> Path ID: The endpoint maintains a separate packet number space for sending and receiving packets over this path which is identified by the path ID.  Packet number considerations as described in Section 12.3 of QUIC-TRANSPORT apply within the given path. </ins> In the "Active" state, hosts MUST also track the following information.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: The ACK_MP frame, as specified in ack-mp-frame, is used to acknowledge 1-RTT packets.  Compared to the QUIC version 1 ACK frame, <del> the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID.  Therefore, the packet number space for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </del> <ins> the ACK_MP frame additionally contains a Path ID.  The Path ID is used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the Path ID for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </ins> Acknowledgements of Initial and Handshake packets MUST be carried using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with <del> the packet number.  If multiple packet number spaces are used, the </del> <ins> the packet number.  When multiple packet number spaces are used, the </ins> packet number alone would not guarantee the uniqueness of the nonce. In order to guarantee the uniqueness of the nonce, the nonce N is calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of the </del> <ins> The Path ID for 1-RTT packets is the sequence number of the </ins> Connection ID as specified in QUIC-TRANSPORT.  Section 19 of QUIC- TRANSPORT encodes the Connection ID Sequence Number as a variable- length integer, allowing values up to 2^62-1; in this specification,
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: nonce. For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the <del> connection ID sequence number is "3", and the packet number is </del> <ins> Connection ID Sequence Number is "3", and the packet number is </ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". 5.3.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: If the client has used all the allocated CID, it is supposed to retire those that are not used anymore, and the server is supposed to provide replacements, as specified in QUIC-TRANSPORT.  Usually, it is <del> desired to provide one more connection ID as currently in use, to </del> <ins> desired to provide one more Connection ID as currently in use, to </ins> allow for new paths or migration. 6.2.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. PATH_ABANDON frames MAY be sent on any path, not only the path <del> identified by the Packet Number Space Identifier. </del> <ins> identified by the Path Identifier. </ins> 8.2.
Code change:
From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.

Related discussion:
text: 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 <del> different paths when 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. </del> <ins> 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. </ins> 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. <del> The identifier of the path packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. If an endpoint receives an ACK_MP frame with a packet number space ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  If an endpoint receives an ACK_MP frame with a packet number space ID which is no more active (e.g., retired by a RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST ignore the ACK_MP frame without causing a connection error. </del> <ins> The identifier of the path to identify the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. If an endpoint receives an ACK_MP frame with a Path ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  If an endpoint receives an ACK_MP frame with a Path ID which is no more active (e.g., retired by a RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST ignore the ACK_MP frame without causing a connection error. </ins> 9.
Code change:
Each line is limited to 72 characters.
I verified that this PR produces the draft that we expect. I did one small change: remove spaces at the end of lines.
There are many isntances in the markdown source where a whole paragraph is entered in a single line of text. This makes the reviewing harder, and messes up the "what changed" view when reviewing PRs.
Just to be on the same page, how should we format the text? I see two possible ways. Hard-constraint the number of characters per line to a given limit (e.g., 80) Make one sentence = one line I have a slight preference for option 2, but I can of course live with the other or a mix of both.
I would prefer something like 72 characters, because the last 8 positions are used for numbering the cards in your deck.

Related discussion:
text: 7.2.1. <del> Packet protection for QUIC version 1 is specified is Section 5 of </del> <ins> Packet protection for QUIC version 1 is specified in Section 5 of </ins> QUIC-TLS.  The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT
Code change:
Let's be clearer about what it means to proxy here. Also, since it is the same text, talk about TLS assumptions more directly. This will interact poorly with . Sorry about that NAME
From Vienna chat. A proxy is not a generic HTTP intermediary, and therefore is not subject to the same rules.
From NAME Generic proxies would forward unknown HTTP headers between clients and targets. We should be very clear that oblivious proxies are not generic, and should not be doing things like forwarding unknown headers arbitrarily between client and target, or target and client.
requests. This includes the Via field, the Forwarded field {{?FORWARDED=RFC7239}}, and any similar information. A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. Obviously, you need encryption on one or the other side of the proxy, right? Probably this document should require it on the inbound side, but I don't see the text that requires it. Did I just miss it?
Yeah, it's only necessary on the inbound side, per the analysis, though the document assumes it's on both sides.

Related discussion:
text: request of the oblivious request resource that includes the same content.  When it receives a response, it sends a response to the client that includes the content of the response from the oblivious <del> request resource.  When generating a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP. </del> <ins> request resource. When forwarding a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP.  A generic HTTP intermediary implementation is suitable for the purposes of serving an oblivious proxy resource, but additional care is needed to ensure that client privacy is maintained. Firstly, a generic implementation will forward unknown fields.  For oblivious HTTP, a proxy SHOULD NOT forward unknown fields.  Though clients are not expected to include fields that might contain identifying information, removing unknown fields removes this privacy risk. Secondly, generic implementations are often configured to augment requests with information about the client, such as the Via field or the Forwarded field FORWARDED.  A proxy MUST NOT add information about the client identity when forwarding requests. </ins> A proxy can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an encapsulated response. <del> A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </del> 7.2.1. As there are privacy benefits from having a large rate of requests
Code change:
Let's be clearer about what it means to proxy here. Also, since it is the same text, talk about TLS assumptions more directly. This will interact poorly with . Sorry about that NAME
From Vienna chat. A proxy is not a generic HTTP intermediary, and therefore is not subject to the same rules.
From NAME Generic proxies would forward unknown HTTP headers between clients and targets. We should be very clear that oblivious proxies are not generic, and should not be doing things like forwarding unknown headers arbitrarily between client and target, or target and client.
requests. This includes the Via field, the Forwarded field {{?FORWARDED=RFC7239}}, and any similar information. A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. Obviously, you need encryption on one or the other side of the proxy, right? Probably this document should require it on the inbound side, but I don't see the text that requires it. Did I just miss it?
Yeah, it's only necessary on the inbound side, per the analysis, though the document assumes it's on both sides.

Related discussion:
text: 7.2.2. <ins> This document assumes that all communication between different entities 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 proxy. </ins> As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages exchanged between the oblivious proxy resource and the oblivious
Code change:
Most of the text was correct in that we talk about making a request of a resource. Where the text refers to making requests of a server, those usages seem to be correct.
Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around
mnot recently made a PR (now merged) that replaced "requests of a server" with "requests to an origin server" and that feels both grammatically and technically more correct. However, there are still few cases peppered through the doc that use "requests of a server". I'd kindly ask the editors to revisit these and consider if they could be made more consistent with the above

Related discussion:
text: 6. In this design, a client wishes to make a request of a server that is <del> authoritative for the Target Resource.  The client wishes to make this request without linking that request with either: </del> <ins> authoritative for a Target Resource.  The client wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the client (that is, the client IP address and TCP or UDP port number the
Code change:
I presume the idea here is to add jitter to the system (different delays for different requests) rather than compound delays on a single request? Even if not, this paragraph could probably benefit from some language fixups. There's a missing word and "might not be what some clients want" could benefit from a rephrasing to make it stronger.
clearer, thanks

Related discussion:
text: analysis could be used to match messages that are forwarded by the relay. <del> A relay could, as part of its function, add delays in order to increase the anonymity set into which each message is attributed. This could latency to the overall time clients take to receive a response, which might not be what some clients want. </del> <ins> A relay could, as part of its function, delay requests before forwarding them.  Delays might increase the anonymity set into which each request is attributed.  Any delay also increases the time that a client waits for a response, so delays SHOULD only be added with the consent - or at least awareness - of clients. </ins> A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.
Code change:
This starts by moving the good text from to the "Errors" section, where I realized that it duplicated some of that language. It was more complete, so I merged the two. I then added some language about what happens to errors prior to decapsulation. This doesn't define an error signaling format. Though that might be useful, it is also a lot more work and I'm leery of scope creep in this document. My view: if you get an error, you have screwed up somewhere. You probably want to have a human look at what is going on. The privacy consequences of automated responses are difficult to work out properly. Hence this proposed change.
This is an improvement but still insufficient with respect to configuration mismatch signaling.
Let's start with this one and I'll look at addressing the open issue in a follow-up.
Thanks, I think this is clear enough now.

Related discussion:
text: response to the POST request made to that resource. Errors detected by the after successfully removing encapsulation and <del> errors detected by the MUST be sent in an . </del> <ins> errors detected by the MUST be sent in an .  This might be because the request is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or outdated.  The can generate and send a response with an error status to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </ins> 6.