Original text:
When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services <del> implementation is responsible for notifying the application of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. </del>  For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should

Reviewer comments:
Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps? 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!

Revised text:
When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services  <ins> implementation is responsible for notifying the Protocol Instance of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths.  Note that, from the Transport Services API point of view, migration is considered a part of multipath connectivity; it is just a limiting policy on multipath usage.  If the "multipath" Selection Property is set to "Disabled", migration is disallowed. </ins> For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should