Change:
Path Identifier Content: A variable-length integer specifying the path identifier. <del> Note: If the receiver of the PATH_STATUS frame is using non-zero </del> <ins> Note: If the receiver of the PATH_ABANDON frame is using non-zero </ins> length Connection ID on that path, endpoint SHOULD use type 0x00 for path identifier in the control frame.  If the receiver of the <del> PATH_STATUS frame is using 0-length Connection ID, but the peer is </del> <ins> PATH_ABANDON frame is using 0-length Connection ID, but the peer is </ins> using non-zero length Connection ID on that path, endpoints SHOULD use type 0x01 for path identifier.  If both endpoints are using 0-length Connection IDs on that path, endpoints SHOULD only use type 0x02 for path identifier. <del> Path Status sequence number: A variable-length integer specifying the sequence number assigned for this PATH_STATUS frame.  There is a different path status sequence number space for each path. Available values of Path Status field are: 0: Abandon 1: Standby 2: Available </del> <ins> A variable-length integer that indicates the reason for abandoning this path. </ins> <del> If the value of Path Status field is 2 ("available"), the receiver side can use the Path Priority field to express the priority weight of a path for the peer. </del> <ins> A variable-length integer specifying the length of the reason phrase in bytes.  Because an PATH_ABANDON frame cannot be split between packets, any limits on packet size will also limit the space available for a reason phrase. </ins> <del> Frames may be received out of order.  A peer MUST ignore an incoming PATH_STATUS frame if it previously received another PATH_STATUS frame for the same Path Identifier with a sequence number equal to or higher than the sequence number of the incoming frame. </del> <ins> Additional diagnostic information for the closure.  This can be zero length if the sender chooses not to give details beyond the Error Code value.  This SHOULD be a UTF-8 encoded string RFC3629, though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text. </ins> <del> PATH_STATUS frames SHOULD be acknowledged.  If a packet containing a PATH_STATUS frame is considered lost, the peer should only repeat it if it was the last status sent for that path - as indicated by the sequence number. </del> <ins> PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer should repeat it. </ins> 9.2.

Discussion:
Simplify pathstatus frame with pathabandon frame following the discussion on issue. Error code and Reason Phrase are left TBD.
I actually think we should have keep stand-by. I think this was useful in MPTCP and it's not really related to scheduling. Stand-by only means: I won't use this path but please keep it open.
The current draft says "Servers SHOULD stop sending traffic on paths through which non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule if it would disqualify all available paths". First, I believe there is a typo, where the "non-probing packet" should be "no non-probing packet". Second, 3 RTT is too short for our applications and we prefer a longer timeout. Maybe we want to add a new parameter (e.g. maxpathidle_timeout) to allow the server and client to negotiate?
I fixed the missing no. I took this text from Christian's draft. So maybe he can comment. NAME ?
I would suggest to leave the path closing problem for further work and indicate that the next version of the draft will define how a path can be closed by one of the endpoints.
There are two issues, path closing and packet scheduling. For path closing, the simplest solution is to use an idle timer, either the idle timer negotiated for the connection or a new parameter negotiated as part of multipath setup. For packet scheduling, the first rule is to not send data on paths that do not work, e.g., lots of packet losses, or maybe absence of ACK. This is basically the same issue as determining whether a connection is broken, just applied to a path. But that is not entirely sufficient, because the server needs to also infer whether the client still wants to use that path. The monitoring of non probing packets is just an heuristic. The server observes that if the client is not using the path, and deduces that it should not be using it itself. That's not a bad heuristic, but it requires the client to send some kinds of "keep alive" if it wants the server to continue using a path. We may debate how often that should happen. Maybe reuse the same timeout as for jettisoning paths.

Another solution may be for the client to tell something like "please don't use that path anymore", but that requires adding a new frame as part of the core multipath specification. In draft-liu, this was done with a specialization of the "path status", setting the status to "Abandon". Maybe we should just use a simplified for of the PATH_STATUS, leaving out the complexities of managing priorities for the advanced scheduling drafts:
I prefer the second approach that Christian proposed, i.e., sending explicit signals like "abandon". But there is an issue with path id type 0x02 in the current draft, which refers to the path over which the control frame is sent or received. The current draft says " If both endpoints are using 0-length Connection IDs on that path, endpoints SHOULD only use type 0x02 for path identifier", so in this case, if a path is broken, we cannot send an explicit "abandon" signal for that path thru other paths, and we have to rely on implicit signals like an idle timeout. That means we may still want to negotiate the idle timer?
The client can always force the issue by dropping all packets received on an old path. They will not be acknowledged, and the server will automatically deduce that the path does not work. Of course, that is ugly...
Note that the "Abandon Path" would be a replacement or a simplification of the "Path Status" frame in the current draft. In my code, I only use the "Abandon" variant of the Path Status. I wonder whether we need alternative statuses like "standby", and whether we should define priorities here, rather than in a separate draft for advanced scheduling.
Yes, I agree. We should put the alternative statuses and priority in a separate draft on advanced scheduling.
I submitted PR on this issue.
This PR was merged.
Look good to me.I made a typo, see comment on closing this path. Apart from that, looks good.