Code change:
implementation should not aggressively close connections in these scenarios. <del> If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API provides an interface to set a multipath policy that indicates when and how different paths should </del> <ins> If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API's Connection Property "multipath-policy" allows an application to indicate when and how different paths should </ins> be used.  However, detailed handling of these policies is still <del> implementation-specific.  The decision about when to create a new </del> <ins> implementation-specific.  For example, if the "multipath" Selection Property is set to "active", the decision about when to create a new </ins> path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is <del> implementation-specific or could be be supported by future API extensions.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection </del> <ins> implementation-specific.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the Transport Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection </ins> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed

Related discussion:
text: Not sure this is a case we need to worry about though...
Ah, a multipath protocol that doesn't do multipath :-)
Well, it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning, but this is what I could think of...
Looks good to me!Thanks for fixing the nits!