Original text:
will only happen if the underlying protocol stack supports reliability and, with it, such notifications.  8. Data is sent and received as Messages, which allows the application

Reviewer comments:
addresses However, we now have this path change event but it seems we actually don't have an interface to the access the path object to figure out what exactly changed...?
So the point is that we don't have an interface anymore to configure when and if a new subpath should be opened (or closed) for multipath transports, so I guess we need a way to provide the respective information to the application in order to potentially implement some logic there. We can separate this out into two events if we are sure that these are the only two cases where we would want to trigger the application.
You say "I guess" and "potentially", which gives me the impression that you also don't know what that logic would be. I tend towards not including control over subpaths (or information about them, which may only be useful if the application can also exercise some control) unless we have a clear idea about how an application should use this. or was there consensus already on adding such information? In this case, I'm not going to fight it, but clearly that's much more than just addressing . I didn't follow this particular discussion back when it happened, but there has to be a reason for RFC 6897 only being Informational... I've seen others presenting MPTCP APIs but somehow these things never made it into a standards recommendation. Maybe there's agreement somewhere that such logic should be placed below the application, not inside? Then that logic also seems more in line with TAPS to me.
Maybe I misunderstand?, I think this seems like rather MP centric thinking. There are other events, we talked on the call about an MPS change, and I am sure some people will wish to see ICMP events, etc. I am hopeful we can evolve to have more signals ... if we have an interface that can supply the events and so apps can expect to eat these. So I think for me at least this is at best a reason come in the event, splitting this into multiple events seems a bad idea. Gorry
sec 7.1.9. We're going to need an event for MTU changes. These can't simply be Send errors because the Sent event might go first, or the transport might be sending a probe with padding that doesn't correspond to a message.
So does this mean MTU of the interface or PMTU of the path? It seems simple to add an event for interface MTU changes. For the PMTU, this raises a few questions before we add: (i) I can see the motivation for an event for a decrease in PMTU, and that seems relatively easy to add ... and could also return the new upper limit (ii) Would the same also be true of an increase in the PMTU? If so, it could be helpful if the upper layer probably says how "large" it is interested in using - e.g., DPLPMTUD has the notion of MAX_PLPMTU as an upper bound on probing.
PMTU of the path. I don't have a strong opinion on increases, but I would probably have an event for increases and not bother with the maximum. An unnecessary increase notification seems less expensive than another bit of API to specify the max.
Just add a path changed event to the application (similar to the one in implementation).
Add event to Section 7.3?
Just to be sure: This is a Path Changed Event, not a specific event relating to PMTU size.
New text looked good, I think this issue has been resolved.
closed this.
LGTM

Revised text:
will only happen if the underlying protocol stack supports reliability and, with it, such notifications. <ins> 7.3.3. This event notifies the application when at least one of the paths underlying a Connection has changed.  Changes occur on a single path when the PMTU changes as well as when multiple paths are used and paths are added or removed, or a handover has been performed. </ins> 8. Data is sent and received as Messages, which allows the application