Change:
This is a follow-up issue for – As we have the ready to support connection coalescing and connection pooling, we have to describe it more closely in the Implementation.
Thanks for the fixes - I think this can be merged now.LGTM And: thanks for doing this! This can make the transport system a lot more powerful, and it's good to tell people about these interesting implementation options this draft, IMO.

Discussion:
and negotiations complete in order to gather metrics to influence future connections.  Similarly, an implementation may choose to hold onto fully established leaf nodes that were not the first to <del> establish for use in future connections, but this approach is not recommended since those attempts were slower to connect and may exhibit less desirable properties. </del> <ins> establish for use as part of a Pooled Connection, see pooled- connections, or in future connections.  In both cases, keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties. </ins> 4.5.1.

6.1. <ins> For protocols that employ request/response pairs and do not require in-order delivery of the responses, like HTTP, the transport implementation may distribute interactions across several underlying transport connections.  For these kinds of protocols, implementations may hide the connection management and only expose a single Connection object and the individual requests/responses as messages. These Pooled Connections can use multiple connections or multiple streams of multi-streaming connections between endpoints, as long as all of these satisfy the requirements, and prohibitions specified in the Selection Properties of the Pooled Connection.  This enables implementations to realize transparent connection coalescing, connection migration, and to perform per-message endpoint and path selection by choosing among these underlying connections. 6.2. </ins> When a path change occurs, the Transport Services implementation is responsible for notifying Protocol Instances in the Protocol Stack. If the Protocol Stack includes a transport protocol that supports

permissible based on the Selection Properties passed by the application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no <del> longer available.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </del> <ins> longer available.  Pooled Connections pooled-connections may add or remove underlying transport connections in a similar manner.  If the Protocol Stack includes a transport protocol that does not support multipath, but support migrating between paths, the update to available paths can be used as the trigger to migrating the connection.  For protocols that do not support multipath or migration, the Protocol Instances may be informed of the path change, but should not be forcibly disconnected if the previously used path becomes unavailable.  An exception to this case is if the System Policy changes to prohibit traffic from the Connection based on its properties, in which case the Protocol Stack should be disconnected. </ins> 7.