Draft: draft-ietf-taps-interface

Commentary: addresses However , we now have this path change event but it seems we actually do n't have an interface to the access the path object to figure out what exactly changed ... ? 
 So the point is that we do n'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 do n'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 did n'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  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 .    7.1.9 . We 're going to need an event for MTU changes . These ca n't simply be Send errors because the Sent event might go first , or the transport might be sending a probe with padding that does n'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 do n'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  . 
 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
Paragraph (version B):
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.