jiebi/TextFlow huggingface dataset:
Original text:
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames to issue usable connections IDs to reach it.  Before an endpoint adds <del> a new path, it SHOULD check whether there is at least one unused </del>  available Connection ID for each side. If the transport parameter "active_connection_id_limit" is negotiated

Reviewer comments:
I copied this sentence from draft-liu: Shouldn't this be a MUST instead of a SHOULD?
We can describe it in a more accurate way: Before an endpoint adds a new path, it MUST check whether there is at lease one unused available Connection ID for each side, unless the endpoints use zero-length Connection ID.
Submitted PR for this issue.
LGTM.

Revised text:
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames to issue usable connections IDs to reach it.  Before an endpoint adds  <ins> a new path, it MUST check whether there is at least one unused </ins> available Connection ID for each side. If the transport parameter "active_connection_id_limit" is negotiated
Original text:
If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new <del> ACK frame format is used as specified in mp-ack-frame.  Compared to the QUIC v1 ACK frame, the MP_ACK frames additionally contains a </del>  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. actively using N paths, the limit is reached.  If the client wants to start a new path, it has to retire one of the established paths. <del> ACK_MP frame mp-ack-frame can be returned via either a different </del>  path, or the same path identified by the Path Identifier, based on different strategies of sending ACK_MP frames. packets with associated ECN marks received on the connection up to this point. <del> ACK_MP frame is formatted as shown in fig-mp-ack-format. </del>  Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added.

Reviewer comments:
This should be a simple fix. There was only one place where MP_ACK appeared.
In the current draft, we are having two names of multi-path ACK. I think we should stick to just one.
I have a slight preference for ACKMP, on the model of ACKECN.
I submitted PR to fix this.
I would be consistent in how the I-D identifies MP additions vs. RFC9000. Given that the document uses MPCONNECTIONERROR and MPPROTOCOLVIOLATION, I have a preference for MP_ACK.
I added changes of the tag "mp-ack-frame" to "ack-mp-frame" for consistency...

Revised text:
If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new  <ins> ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC v1 ACK frame, the ACK_MP frames additionally contains a </ins> 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. actively using N paths, the limit is reached.  If the client wants to start a new path, it has to retire one of the established paths.  <ins> ACK_MP frame ack-mp-frame can be returned via either a different </ins> path, or the same path identified by the Path Identifier, based on different strategies of sending ACK_MP frames. 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. </ins> Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added.
Original text:
name: enable_multipath (TBD - experiments use 0xbabf) <del> value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the peer does not carry the enable_multipath transport parameter, which means the peer does not support multipath, endpoint MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document.  If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </del>  Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits

Reviewer comments:
Lack of the reference to Section 7.4/Section 7.4.2 of 9000 where the general handling of (new) transport parameters is discussed. When the new transport parameter is not present, this does not necessarily mean multipath is not supported as it can be supported, but disabled (for this connection as a function of local policy). I would update this text
The absence of the parameter does indeed indicate that the peer will not support multipath for this connection. But yes, the current text does not read too well. I think we should simplify and just say the same as QUIc V1, i.e. "Transport parameters have a default value of 0 if the transport parameter is absent". So something like:
The negotiation only refers to "support for this connection". We cannot make any statement about whether the same server might negotiate the feature in another connection attempt. There is no practical difference between "not supported" and "supported, but disabled". It could very well be for example that some server in a farm support the feature and some don't.
NAME please review PR
Looks good to me. Thanks.

Revised text:
name: enable_multipath (TBD - experiments use 0xbabf)  <ins> value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available option value for client and server are listed in param_value_definition : If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits
Original 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 multi-path control frames (etc.  PATH_ABANDON frame) to </del>  identify a path.  By default, it is defined as the sequence number of the destination Connection ID used for sending packets on that particular path, but alternative definitions can be used if the does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. <del> This proposal adds one multi-path control frame for path management: </del>  PATH_ABANDON frame for the receiver side to abandon the path 11. <del> Multi-path QUIC transport error codes are 62-bit unsigned integers </del>  following QUIC-TRANSPORT. This section lists the defined multipath QUIC transport error codes

Reviewer comments:
Be consistent with title.
NAME flagged in his PRs that there are many places using hyphenated "multi-path" and many using "multipath". We need to fix that.
This is due to the merge of the different drafts. I thought I fixed most of them, but I guess I could have done a search :-) Will do

Revised text:
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is  <ins> used in multipath control frames (etc.  PATH_ABANDON frame) to </ins> identify a path.  By default, it is defined as the sequence number of the destination Connection ID used for sending packets on that particular path, but alternative definitions can be used if the does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents.  <ins> This proposal adds one multipath control frame for path management: </ins> PATH_ABANDON frame for the receiver side to abandon the path 11.  <ins> Multipath QUIC transport error codes are 62-bit unsigned integers </ins> following QUIC-TRANSPORT. This section lists the defined multipath QUIC transport error codes
Original text:
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>  calculated by combining the packet protection IV with the packet number and with the path identifier.

Reviewer comments:
(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!

Revised text:
the packet number.  If multiple packet number spaces are used, the packet number alone would not guarantee the uniqueness of the nonce.  <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.
Original text:
We assume that the reader is familiar with the terminology used in QUIC-TRANSPORT.  In addition, we define the following terms:  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

Reviewer comments:
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.

Revised text:
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
Original text:
uses a series of consecutive sequence numbers without creating holes.  7.2. If the multipath option is enabled with a value of 2, each path has

Reviewer comments:
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.

Revised text:
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
Original text:
Multipath Extension for QUIC <del> draft-lmbdhk-quic-multipath-latest </del>  Abstract

Reviewer comments:
Renames the markdown document and updates the README. The new links in the README that point to github-hosted pages might be dead for a while during the process.
Looks good.

Revised text:
Multipath Extension for QUIC  <ins> draft-ietf-quic-multipath-latest </ins> Abstract
Original text:
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>  A path is determined by the 4-tuple of source and destination IP address as well as source and destination port.  Therefore there

Reviewer comments:
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.

Revised text:
risk of packets being dropped by middleboxes (which may only support QUIC version 1)  <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
Original text:
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>  9.3.

Reviewer comments:
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.

Revised text:
It is possible for a server to be configured with multiple Oblivious Proxy Resources, each for a different Oblivious Request Resource as  <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.
Original text:
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>  The client role in this protocol acts as an HTTP client both with respect to the oblivious proxy resource and the oblivious target

Reviewer comments:
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?

Revised text:
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.  <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
Original text:
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>  9.

Reviewer comments:
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.

Revised text:
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  <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.