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 (path identifier type 0x00), 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 (path identifier type 0x00) as path identifier, which </del>  corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. PATH_ABANDON frames contain the following fields: <del> Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format. Identifier Type: Identifier Type field is set to indicate the type of path identifier. Type 0: Refer to the connection identifier issued by the sender of the control frame.  Note that this is the connection identifier used by the peer when sending packets on the to-be- closed path.  This method SHOULD be used by default. Type 1: Refer to the connection identifier issued by the receiver of the control frame.  Note that this is the connection identifier used by the sender when sending packets on the to-be-closed path. Type 2: Refer to the path over which the control frame is sent or received. Path Identifier Content: A variable-length integer specifying the path identifier.  If Identifier Type is 2, the Path Identifier Content MUST be empty. </del>  A variable-length integer that indicates the reason for abandoning this path. PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. <del> If the Identifier Type is 0x00 or 0x01, PATH_ABANDON frames MAY be sent on any path, not only the path identified by the Path Identifier Content field.  If the Identifier Type if 0x02, the PATH_ABANDON frame MUST only be sent on the path that is intended to be abandoned. </del>  12.2. PATH_STATUS Frames contain the following fields: <del> Path Identifier: An identifier of the path, which is formatted as shown in fig-path-identifier-format.  Exactly the same as the definition of Path Identifier in {#path-abandon-frame}. </del>  <del> Path Status sequence number: A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  The sequence number MUST be monotonically increasing generated by the sender of the Path Status frame in the same connection.  The receiver of the Path Status frame needs to use and compare the sequence numbers separately for each Path Identifier. </del>  Available values of Path Status field are: Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. <del> Packet Number Space Identifier: An identifier of the path packet number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. </del>  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

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.
From PR by NAME
Looks good to me

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 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 </ins> corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. PATH_ABANDON frames contain the following fields:  <ins> The identifier of the path that should be abandoned. </ins> A variable-length integer that indicates the reason for abandoning this path. PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it.  <ins> PATH_ABANDON frames MAY be sent on any path, not only the path identified by the Packet Number Space Identifier. </ins> 12.2. PATH_STATUS Frames contain the following fields:  <ins> The identifier of the path that the status update correspondes to. </ins>  <ins> A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  The sequence number MUST be monotonically increasing generated by the sender of the Path Status frame in the same connection.  The receiver of the Path Status frame needs to use and compare the sequence numbers separately for each Path Identifier. </ins> Available values of Path Status field are: Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added.  <ins> The identifier of the path packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. </ins> 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