On-Demand Mobility Management
draft-ietf-dmm-ondemand-mobility-18

Thank you for this document.

I don't mind presence of socket API, but I would like to point out that it is not very friendly to platforms (e.g. Windows) where sockfd type is not "int".

Thanks for responding to my previous ballot.

Nits:

Don't put references in the Abstract: s/[RFC7333]/RFC7333

s/new concep/new concept

In §5: s/Backwards compatibility support is REQUIRED/Backwards compatibility support is required     In this case, you're not specifying anything, just stating a fact, so Normative language is not needed.

Thanks for addressing my discuss. Sorry for the long delay on my side!

Here is my old  comment still:

Please also note that address mobility is actually more a transport question that an application layer question. For TCP session-lasting addresses will always be more efficient if available while an application using TCP will always need to cover the case where an TCP connection fails or is interrupted and therefore the application needs to reconnect. However, in contrast QUIC supports IP address mobility and will survive changing IP addresses. I think that should be also clarified in the draft and it should be double-check if the use of the word application is always correct or if it should be replaced sometimes with e.g. transport system or a more general term.