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