Skip to main content

Last Call Review of draft-ietf-dmm-ondemand-mobility-15
review-ietf-dmm-ondemand-mobility-15-opsdir-lc-vyncke-2019-01-13-00

Request Review of draft-ietf-dmm-ondemand-mobility
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-01-16
Requested 2019-01-02
Authors Alper E. Yegin , Danny Moses , Seil Jeon
I-D last updated 2019-01-13
Completed reviews Intdir Early review of -14 by Brian Haberman (diff)
Secdir Last Call review of -17 by Daniel Migault (diff)
Opsdir Last Call review of -15 by Éric Vyncke (diff)
Genart Last Call review of -15 by Russ Housley (diff)
Tsvart Last Call review of -15 by Magnus Westerlund (diff)
Rtgdir Telechat review of -15 by Jonathan Hardwick (diff)
Secdir Telechat review of -16 by Daniel Migault (diff)
Genart Telechat review of -16 by Russ Housley (diff)
Assignment Reviewer Éric Vyncke
State Completed
Request Last Call review on draft-ietf-dmm-ondemand-mobility by Ops Directorate Assigned
Reviewed revision 15 (document currently at 18)
Result Has issues
Completed 2019-01-13
review-ietf-dmm-ondemand-mobility-15-opsdir-lc-vyncke-2019-01-13-00
Reviewer: Eric Vyncke
Review Status: has issues

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

This informational document is about extended the host socket() API to select
between short term (for one app) or long term (for ever) persistence of the IP
address when doing mobility.

As a side personal note, I do not agree with the statement "...a typical client
application ... does not necessarily require IP address reachability..." which
may actually be true in a NAT'ed IPv4 cloud world but not in a real end-to-end
Internet. Another one where I do not agree with an IPv6 point of view "Mobile
IP protocol forces the mobile host's IP traffic to traverse a centrally-located
router" esp when section 3.4 is about IPv6. But, let's skip this statement
anyway as I am reviewing this from an OPS point of view.

Some more important comments:
- the abstract is not clear: it take several pages to understand that it is
about a host local API - section 3.1: 'fixed IP address' but not more
information whether it is public or ISP private address - section 5 is about
backwards compatibility which is good but sometimes it is rather vague "If an
application does not use On-Demand functionality, the IP stack MUST respond in
a legacy manner"

Missing: definition of the getsc() API.

Cosmetic: when introducing getsc() / secsc() in section 3.4, it would be nice
explaining where the 'sc' part means ;-)

As a last side note, I would like to bring to the authors' attention this INT
area draft draft-ietf-intarea-provisioning-domains.

Hope this helps

-éric