On-Demand Mobility Management
Note: This ballot was opened for revision 15 and is now closed.
(Suresh Krishnan) Yes
(Deborah Brungard) No Objection
(Ben Campbell) No Objection
(Alissa Cooper) (was Discuss) No Objection
Comment (2019-07-12 for -17)
Thanks for responding to my previous ballot.
(Mirja Kühlewind) (was Discuss) No Objection
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.
(Alexey Melnikov) No Objection
Comment (2019-02-21 for -16)
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".
Alvaro Retana No Objection
Comment (2019-02-20 for -16)
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.