Change:
Please carefully review the text about abandon frames on the last active path. This is new and maybe not what you intended, however, because of potential crossing of abandon frames from each direction (as mentioned by NAME in the issue), I don't think receiving an abandon frame on the last active path should be a protocol violation.
The text says that both endpoint can send an abandon frame. However, if I understand the current text correctly it only says that the receiving peer of that frame can remove its state as the sender of the abandon frame indicated it will not send any more packets ion that path. However, the sender of the abandon frame can't remove its state until it also receives an abandon frame from the other end. That would mean a path can "half-open"... Do we need to say something that that the receiver of an abandon frame SHOULD also send an abandon frame in response? Or MAY? Or MUST? Or is the path considered completely closed as soon as an ACK for the packet containing the abandon frame is received? In this case we need to say that when an abandon frame is received, the receiver MUST not use that path anymore. I think we need to clarify that! Please provide a PR or let me know what the intention was and I can write something!
For me, ABANDONPATH means "please stop sending on that path, I may soon stop listening". The peer should definitely stop sending on that path. It may want to keep listening for a short time, because some packets may still be sent out of order. It may also want to keep some context to process acknowledgement of packets previously sent on that path. The general guidance is to to wait for something like 3xRTO before dropping path management resource. I don't think that we need symmetry, that both peers have to abandon the path before they can release resource. But we have to solve a potential path suicide problem. Suppose we have two paths, peer 1 abandons path , peer 2 abandon path . Now we have zero path, and the connection is closed -- unless the client promptly opens a new path . My original intention is that only the client ever sends an ABANDONPATH, since only the client can initiate a new path, which dodges the path suicide issue.
Good questions! For me, the issue is that when an endpoint decides to close a path, it is probably due to that the path condition is getting worse, which also means that further communication on that path may fail. When we use non-zero CID, as we should have at least one path that is working (if no path is working, the connection will be closed), and we are not constraint to send PATHABANDON frame on the same path that we want to close, the sender should be able to receive the ACK of PATHABANDON. But when we use null CID, we use pathidtype 0x02, which refers to the path where the packet is coming from, and hence, we are constraint to send PATHABANDON on the same path we want to close. In such a case, it is likely that the ACK of PATHABANDON will not be received, resulting in the "half-open" problem. Therefore, we should say sth like "when the sender moves into the "ABANDONSENT" state, and after 3RTO, it should close the path even if it hasn't seen the PATHABANDON sent from its peer".
Also, regarding when a path is considered completely closed, the current intention is that a path is considered closed when both the sender-side and the receiver-side resources of that path are released. The sender-side resources can be readily released when PATHABANDON is acked (We may need to retransmit the pathabandon). The receiver-side resources are released when the RETIRECID frame is received. However, when zero-CID is used, it is possible that an endpoint is not going to receive any RETIRECID frames, so the receiver-side resources are released 3RTO after sending out the PATH_ABANDON.
I created PR . I think this is the biggest issue we need to address and agree on before submission of -00. So please review NAME NAME NAME !
Sounds good. I think the next feedback will come once we have implemented and tested the feature.

Discussion:
Each endpoint manages the set of paths that are available for transmission.  At any time in the connection, each endpoint can decide to abandon one of these paths, following for example changes <del> in local connectivity or changes in local preferences.  After a client abandons a path, the server will not receive any more non- </del> <ins> in local connectivity or changes in local preferences.  After an endpoint abandons a path, the peer will not receive any more non- </ins> probing packets on that path. An endpoint that wants to close a path SHOULD NOT rely on implicit

Both endpoints, namely the client and the server, can close a path, by sending PATH_ABANDON frame (see path-abandon-frame) which abandons the path with a corresponding Path Identifier.  Once a path is marked <del> as "abandoned", it means that the resources related to the path can be released. </del> <ins> as "abandoned", it means that the resources related to the path, such as the used connection IDs, can be released.  However, information related to data delivered over that path SHOULD not be released immediately as acknowledgments can still be received or other frames that also may trigger retransmission of data on another path. The endpoint sending the PATH_ABANDON frame SHOULD consider a path as abandoned when the packet that contained the PATH_ABANDON frame is acknowledged.  When releasing resources of a path, the endpoint SHOULD send a RETIRE_CONNECTION_ID frame for the connection IDs used on the path, if any. The receiver of a PATH_ABANDON frame SHOULD NOT release its resources immediately but SHOULD wait for the receive of the RETIRE_CONNECTION_ID frame for the used connection IDs or 3 RTOs. Usually it is expected that the PATH_ABANDON frame is used by the client to indicate to the server that path conditions have changed such that the path is or will be not usable anymore, e.g. in case of an mobility event.  The PATH_ABANDON frame therefore indicates to the receiving peer that the sender does not intend to send any packets on that path anymore but also recommends to the receiver that no packets should be sent in either direction.  The receiver of an PATH_ABANDON frame MAY also send an PATH_ABANDON frame to signal its own willingness to not send any packet on this path anymore. If connection IDs are used, PATH_ABANDON frames can be sent on any path, not only the path that is intended to be closed.  Thus a connection can be abandoned even if connectivity on that path is already broken.  If no connection IDs are used and the PATH_ABANDON frame has to sent on the path that is intended to be closed, it is possible that the packet containing the PATH_ABANDON frame or the packet containing the ACK for the PATH_ABANDON frame cannot be received anymore and the endpoint might need to rely on an idle time out to close the path, as described in Section idle-time-close. Retransmittable frame, that have previously been send on the abandoned path and are considered lost, SHOULD be retransmitted on a different path. If a PATH_ABANDON frame is received for the only active path of a QUIC connection, the receiving peer SHOULD send a CONNECTION_CLOSE frame and enters the closing state.  If the client received a PATH_ABANDON frame for the last open path, it MAY instead try to open a new path, if available, and only initiate connection closure if path validation fails or a CONNECTION_CLOSE frame is received from the server.  Similarly the server MAY wait for a short, limited time such as one RTO if a path probing packet is received on a new path before sending the CONNECTION_CLOSE frame. </ins> 3.2.2.

9.1. <del> The PATH_ABANDON frame informs the peer to abandon a path, and release the corresponding resources.  An endpoint uses the sequence number of the CID used by the peer for PATH_ABANDON frames (describing the sender's path identifier).  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </del> <ins> The PATH_ABANDON frame informs the peer to abandon a path.  An endpoint uses the sequence number of the CID used by the peer for PATH_ABANDON frames (describing the sender's path identifier).  More complex path management can be made possible with additional extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ). </ins> PATH_ABANDON frames are formatted as shown in fig-path-abandon- format.

one that created the text. PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a <del> PATH_ABANDON frame is considered lost, the peer should repeat it. </del> <ins> PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. </ins> <del> PATH_ABANDON frames can sent on any path, not only the path </del> <ins> PATH_ABANDON frames MAY be sent on any path, not only the path </ins> identified by the Path Identifier field. 9.2.