Draft: draft-ietf-quic-multipath

Commentary: 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
fig-example-path-close1 illustrates an example of path closing.  For
the first path, the server's 1-RTT packets use DCID C1, which has a
sequence number of 1; the client's 1-RTT packets use DCID S2, which
has a sequence number of 2.  For the second path, the server's 1-RTT
packets use DCID C2, which has a sequence number of 2; the client's
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
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
that path.
fig-example-path-close1 illustrates an example of path closing.  For
the first path, the server's 1-RTT packets use DCID C1, which has a
sequence number of 1; the client's 1-RTT packets use DCID S2, which
has a sequence number of 2.  For the second path, the server's 1-RTT
packets use DCID C2, which has a sequence number of 2; the client's
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
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
that path.