jiebi/TextFlow huggingface dataset:
Original text:
1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by <del> the sequence number of the received packet's DCID over that path, hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </del>  that path. 7.

Reviewer comments:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
I would also suggest to slightly update the text related to the field of the PATHABANDON and PATHSTATUS frames to indicate it refers to the sender's Path ID.LGTM

Revised text:
1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by  <ins> the sequence number of the DCID it uses for sending packets over that path, hence using the path_id 2.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the DCID it uses to send over that path as path identifier, which corresponds to the path_id 1.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for </ins> that path. 7.
Original text:
connection IDs for distinguishing packets sent to that node over different paths.  This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths are assumed to be handled by the application that is using the QUIC <del> multipath extension.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </del>  implementation guidance.  However, more advanced algorithms as well as potential extensions to enhance signaling of the current path state are expected as future work.

Reviewer comments:
This draft only enables clients to open a new path, so the most common scenario is that the client has another interface and opens a new path from a new IP address. However, if the client knows another IP that the server is listing on to accept new paths for an existing quic connection (e.g. provided on the higher layer or out of band), that can be used as well. It would be useful to discussion this case more in the draft to ensure that it is clear that this case is supported.
I think as people who implement multipath will mostly refer to this draft, we may want to clarify all scenarios supported by this draft: (1) client has multiple IPs while server listens on single IP, (2) client uses single IP while server listens on multiple IP, and (3) client uses multiple IPs and the server also uses multiple IPs.
LGTM

Revised text:
connection IDs for distinguishing packets sent to that node over different paths. <ins> Each endhost may use several IP addresses to serve the connection. In particular, the multipath extension supports the following scenarios. The client uses multiple IP addresses and the server listens on only one. The client uses only one IP address and the server listens on several ones. The client uses multiple IP addresses and the server listens on several ones. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths are assumed to be handled by the application that is using the QUIC  <ins> multipath extension.  This is sufficient to address the first aforementioned scenario.  However, this document does not prevent future extensions from defining mechanisms to address the remaining scenarios.  Further, this proposal only specifies a simple basic packet scheduling algorithm, in order to provide some basic </ins> implementation guidance.  However, more advanced algorithms as well as potential extensions to enhance signaling of the current path state are expected as future work.
Original text:
5. <del> The simultaneous usage of several sending uniflows introduces new </del>  algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like

Reviewer comments:
This is really a minor issue, but the word "uniflow" appears just once in the draft, in section 5, packet scheduling. I think the packet scheduling text could simply use the word "path".

Revised text:
5.  <ins> The simultaneous usage of several sending paths introduces new </ins> algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like
Original text:
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del>  10.  This document defines a new transport parameter for the negotiation of enable multiple paths for QUIC, and two new frame types.  The draft defines provisional values for experiments, but we expect IANA The following frame types defined in frame-types should be added to the "QUIC Frame Types" registry under the "QUIC Protocol" heading. <del> 11. </del>  TBD <del> 12. </del>  TBD

Reviewer comments:
If we want an MP specific error type we need to also add this to the IANA section.
Submitted PR for this issue. I just added MPPROTOCOLVIOLATION for connection close. If we have more specific error codes in the future, we can add them in the table.
Looks OK.

Revised text:
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type  <ins> MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. <ins> Multi-path QUIC transport error codes are 62-bit unsigned integers following QUIC-TRANSPORT. This section lists the defined Multi-path QUIC transport error codes that can be used in a CONNECTION_CLOSE frame with a type of 0x1c. These errors apply to the entire connection. MP_PROTOCOL_VIOLATION (experiments use 0xba01): An endpoint detected an error with protocol compliance that was not covered by more specific error codes. 11. </ins> This document defines a new transport parameter for the negotiation of enable multiple paths for QUIC, and two new frame types.  The draft defines provisional values for experiments, but we expect IANA The following frame types defined in frame-types should be added to the "QUIC Frame Types" registry under the "QUIC Protocol" heading.  <ins> The following transport error code defined in tab-error-code should be added to the "QUIC Transport Error Codes" registry under the "QUIC Protocol" heading. 12. </ins> TBD  <ins> 13. </ins> TBD
Original text:
The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  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>  ACK_MP frame is formatted as shown in fig-mp-ack-format. space ID, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  10. Multi-path QUIC transport error codes are 62-bit unsigned integers

Reviewer comments:
When negotiating the use of a single packet number space, it is not clear whether the use of ACKMP frame is acceptable or not. Should we only stick to ACK frames and consider reception of ACKMP frames to be MPPROTOCOLVIOLATION error? Or should we tolerate their reception if the packet number space identifier is 0?
Ah good point. I moved the text about ACKMP this morning because I assumed that you would only implement this frame if you use multiple packet number spaces. If that's the case receiving an ACKMP with enablemultipath=2 should be a PROTOCOLVIOLATION and we should specify that.
Look good to me.

Revised text:
The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that  <ins> were sent on 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. </ins> ACK_MP frame is formatted as shown in fig-mp-ack-format. space ID, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. <ins> When using a single packet number space, endhosts MUST NOT send ACK_MP frames.  If an endhost receives an ACK_MP frame while a single packet number space was negotiated, it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection. </ins> 10. Multi-path QUIC transport error codes are 62-bit unsigned integers
Original text:
for an excessive time or having to promptly reestablish a path after a spurious estimate of path abandonment by the client.  4. Senders MUST manage per-path congestion status, and MUST NOT send

Reviewer comments:
Initial attempt to solve .
One more editorial comment: This section is now somehow in the middle between the cc section and the packet scheduling section. I think it would be better to have this new section as a subsection of section 3 (on Path Setup and Removal).
Indeed, let me fix that.
Given that paths are initiating/validating/active/closed, it looks like we will need at some point to specify some path state (finite state machine?) and what behavior is acceptable in each of them (e.g., we cannot send packets on a closed state,...).
Can you create a PR?

Revised text:
for an excessive time or having to promptly reestablish a path after a spurious estimate of path abandonment by the client. <ins> 3.3. fig-path-states shows the states that an endpoint's path can have. In non-final states, hosts have to track the following information. Associated 4-tuple: The tuple (source IP, source port, destination IP, destination port) used by the endhost to send packets over the path. Associated Destination Connection ID: The Connection ID used to send packets over the path. If multiple packet number spaces are used over the connection, hosts MUST also track the following information. 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. In the "Active" state, hosts MUST also track the following information. Associated Source Connection ID: The Connection ID used to receive packets over the path. A path in the "Validating" state performs path validation as described in Section 8.2 of QUIC-TRANSPORT.  An endhost should not send non-probing frames on a path in "Validating" state, as it has no guarantee that packets will actually reach the peer. The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending of new data on a path. In the "Closing" state, the endhost SHOULD NOT send packets on this path anymore, as there is no guarantee that the peer can still map the packets to the connection.  The endhost SHOULD wait for the acknowledgment of the PATH_ABANDONED frame before moving the path to the "Closed" state to ensure a graceful termination of the path. When a path reaches the "Closed" state, the endhost releases all the path's associated resources.  Consequently, the endhost is not able to send nor receive packets on this path anymore. </ins> 4. Senders MUST manage per-path congestion status, and MUST NOT send
Original text:
as specified in QUIC-TRANSPORT.  The new transport parameter is defined as follow: <del> name: enable_multipath (TBD) </del>  value: 0 (default) for disabled.  Endpoints use 2-bits in the value field for negotiating one or more PN spaces, available

Reviewer comments:
For issue
Ok too.
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
NAME please confirm that this is okay and merge!

Revised text:
as specified in QUIC-TRANSPORT.  The new transport parameter is defined as follow:  <ins> 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
Original text:
or received. Path Identifier Content: A variable-length integer specifying the <del> path identifier. </del>  Note: If the receiver of the PATH_ABANDON frame is using non-zero length Connection ID on that path, endpoint SHOULD use type 0x00 for

Reviewer comments:
Fix issue .
In the "path abandon" frame, the path identifier is defined as: But in the identifier type 2, the "path identifier content" is empty. We should fix that.
Submitted PR for this issue.
Yes, perfect.

Revised text:
or received. Path Identifier Content: A variable-length integer specifying the  <ins> path identifier.  If Identifier Type is 2, the Path Identifier Content MUST be empty. </ins> Note: If the receiver of the PATH_ABANDON frame is using non-zero length Connection ID on that path, endpoint SHOULD use type 0x00 for
Original text:
10.2. The ACK_MP frame (types TBD-00 and TBD-01; experiments use <del> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that were sent on 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>  ACK_MP frame is formatted as shown in fig-mp-ack-format.

Reviewer comments:
Given the deadline, let's first have one set of values instead of two. We may want to decide a third value set later.
Ok for me!
The current text on the defintion of ACK MP says: The figure is too wide, and I am fixing that with issue , but really we should pick just one set of identifiers, not 2. I understand that draft-liu and draft-deconinck were using these two values, but we should pick one of them, or a third one.
I submitted PR to fix this issue.
PR merged.
Fixed conflict.NAME please review and merge if you agree!

Revised text:
10.2. The ACK_MP frame (types TBD-00 and TBD-01; experiments use  <ins> 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths 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. </ins> ACK_MP frame is formatted as shown in fig-mp-ack-format.
Original text:
more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT. <del> Multipath TCP uses the LIA congestion control scheme specified in RFC6356.  This scheme can immediately be adapted to Multipath QUIC. Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </del>  5.

Reviewer comments:
Some more text in the congestion control section explaining why coupled congestion control is suggested. We could later add SHOULD or MUST to request the utilization of coupled congestion control schemes for multipath QUIC.

Revised text:
more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT.  <ins> When a Multipath QUIC connection uses two or more paths, there is no guarantee that these paths are fully disjoint.  When two (or more paths) share the same bottleneck, using a standard congestion control scheme could result in an unfair distribution of the bandwidth with the multipath connection getting more bandwidth than competing single paths connections.  Multipath TCP uses the LIA congestion control scheme specified in RFC6356 to solve this problem.  This scheme can immediately be adapted to Multipath QUIC.  Other coupled congestion control schemes have been proposed for Multipath TCP such as OLIA. </ins> 5.
Original text:
3. After completing the handshake, endpoints have agreed to enable <del> multipath feature and can start using multiple paths. </del>  This proposal adds one multi-path control frame for path management: 6. <del> The simultaneous usage of several sending paths introduces new algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like Multipath TCP, CMT-SCTP and Multipath DCCP.  A companion draft I- D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals.  A similar document can be created to discuss path management considerations. </del>  7.

Reviewer comments:
Some more text for the scheduling section to clarify it.
A suggestion to resolve Mirja's point, also agree on the proposed change in line 248.

Revised text:
3. After completing the handshake, endpoints have agreed to enable  <ins> multipath feature and can start using multiple paths.  This document does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </ins> This proposal adds one multi-path control frame for path management: 6.  <ins> The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet scheduler that decides, among the paths whose congestion window is open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their previse definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. </ins> 7.
Original text:
packet number space for all paths or the use of separate packet number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly <del> difference latencies, this approach requires the use of a connection </del>  ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the <del> connection ID in the header.  More evaluation and implementation experience is needed to select one approach before final publlication. </del>  As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both

Reviewer comments:
Based on the discussed from the side meeting, we need to Clarify that the goal is to only select one approach for the finally published solution in an RFC Add some discussion about the pros and cons to the appendix
Yes, I think we should have these discussions in the current draft.
Should we use a new code point for the transport parameter of the options? For 2 reasons: It's a new joint version As we use a different value definition in our current implementation, it's hard to deploy the new version in a synchronised way, at least we could keep compatible if we use a new transport parameter. What do you think? Or maybe we should keep it unchanged until the WG is ready to adopt the draft?
I think it is fine to define a new value for the transport parameter, the 00 version of this draft is not yet out anyway.
Yes, please use a new parameter.
I created to add one more sentence and a reference to the slides from the side meeting. I believe this is sufficient to address this issue for -00.
Ok with the PR, I can make a quick commit to fix the listed typos

Revised text:
packet number space for all paths or the use of separate packet number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly  <ins> different latencies, this approach requires the use of a connection </ins> ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the  <ins> connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf </ins> As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both