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 rev. no specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-01-16
Requested 2019-01-02
Other Reviews Intdir Early review of -14 by Brian Haberman (diff)
Secdir Last Call review of -15 by Daniel Migault (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)
Review State Completed
Reviewer Éric Vyncke
Review review-ietf-dmm-ondemand-mobility-15-opsdir-lc-vyncke-2019-01-13
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/Sqc1ozWBvfYmEK5on3GD6lKPtdY
Reviewed rev. 15 (document currently at 16)
Review result Has Issues
Draft last updated 2019-01-13
Review completed: 2019-01-13

Review
review-ietf-dmm-ondemand-mobility-15-opsdir-lc-vyncke-2019-01-13

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