Original text:
The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending <del> of new data on a path. </del>  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 "Closed" state to ensure a graceful termination of the path. When a path reaches the "Closed" state, the endhost releases all the <del> path's associated resources.  Consequently, the endhost is not able to send nor receive packets on this path anymore. </del>  5.

Reviewer comments:
Fix issue and
For the transition from a "closing" state to a "closed" state In the path state figure in section 4.2, I find the phrase "path idle timeout" a bit confusing, because right now this value is supposed to be equal to maxidletimeout, but shouldn't a transition from a "closing" state to a "closed" state be much quicker than that from an "active" state to a "closed" state since the first transition is just what we expect to happen?
I think this is now fixed by .
In Section 4.3 we wrote: There are 2 problems in this figure: "Associated CID have been retired" should not cause the path turn into closed state, because in Section : So retiring associated CID only cause the resources belonging to the corresponding packet number space to be released, but not the whole path to be closed. In CID migration cases, endpoints just want to retire the old CID and use a new one, as path is defined as "refers to the 4-tuple" in the current draft, this operation will not cause the whole path context (including congestion control states, RTT measurements, etc.) to be removed. Path closing is triggered by PATHABANDONED frame, and does not have dependency on CID retiring (Although path closing would trigger the retirement of CID resource). So when pathstate transmit from "Closing" to "Closed", the proper condition might be "Acknowledgement of PATHABANDONED frame received" or "Path's draining timeout for at least 3 times the current PTO interval".
First, regarding the transitioning from a "closing" state to a "closed" state, there will be a problem if we use the receipt of the ACK of a PATHABANDON as a condition for the transitioning due to possible out-of-order delivery. Suppose a client uses DCID S2 to on its first path to send three pkts with the packet number 100, 101, and 102, where PATHABANDON frame is sent in packet 102. However, due to the out-of-order delivery, it is possible that 102 is acked first, while packet 100 and 101 are still in flight. Therefore, at this point, we cannot mark the first path as "closed" since it is also possible that the acks of those two packets will later return from the first path. Due to the above reasons, in the initial design, we say that the path should be closed after CIDs are retired. As shown in the path-closing figure (Fig.3) in the draft, after the client makes sure that the packets (100, 101) sent before PATHABANDON on path 1 are also acknowledged, it then decides that the CID S2 is no longer needed, and thus sending out the RETIRECONNECTION_ID frame. Second, regarding the transitioning from an "active" state to a "closed" state, yes, it is possible that we want to retire the old CID and use a new one, and I think the current figure is a bit confusing. The purpose of this transitioning is to handle exceptions and it basically says that when there are no available CIDs to use for communication on a particular path, we should close it. I think we can simply keep the "path's timeout" as the condition because when there are no available CIDs, the path timeout will be triggered anyway.
I agree that the transitioning from "Active" to "Closed" should not be directly done if we retire the associated CID. We could instead have an intermediate "Idle" state in which as long as you have no associated CID, keep relevant recovery/RTT/... contexts. In general, I think it could be worthwhile to make a clearer distinction between the acknowledgment/packet number context and the recovery one. For instance, if for any reason a host changes the DCID used over a given path, it should still keeps track of packets sent with the previous DCID (and thus possibly sent with a different packet number space). For the "Closing" to "Closed" transition, I tend to agree with Yunfei and I would not directly rely on the acknowledgment of the PATHABANDON frame to close my path. But as a sender, I can react to the acknowledgment of my PATHABANDON frame and send the RETIRECONNECTIONID frame. On the other hand, relying on 3*PTO to transition from "Closing" to "Closed" is probably more relevant than using the path's idle timeout.
I've just submitted PR for this issue, containing the suggestions from Yunfei and Quentin. The core points for this modification: Retiring CIDs would not trigger path closure. If a path is idle timeout, endpoints should send PATHABANDON frame before closing the path, so the path state transition would be "Active" -> "Closing" -> "Closed" in this situation If a path is detected blackhole or can't be used for some reason such as the whole network environment failed, endpoints can close the path immediately, because sending PATHABANDON frame on this path seem to be useless.
NAME your PR () says While you wrote in your comment above that it might be useless to send PATH_ABANDONED. Am I missing something?

Revised text:
The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending  <ins> of new data on a path.  Note that if a path became idle due to a timeout, endpoints SHOULD send PATH_ABANDONED frame before closing the path. </ins> 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 "Closed" state to ensure a graceful termination of the path. When a path reaches the "Closed" state, the endhost releases all the  <ins> path's associated resources, including the associated Connection IDs. Endpoints SHOULD send RETIRE_CONNECTION_ID frames for releasing the associated Connection IDs following QUIC-TRANSPORT.  Considering endpoints are not expected to send packets on the current path in the "Closed" state, endpoints can send RETIRE_CONNECTION_ID frames on other available paths.  Consequently, the endhost is not able to send nor receive packets on this path anymore. </ins> 5.