Early Review of draft-ietf-dmm-ondemand-mobility-14
review-ietf-dmm-ondemand-mobility-14-intdir-early-haberman-2018-05-21-00

Request Review of draft-ietf-dmm-ondemand-mobility
Requested rev. no specific revision (document currently at 16)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2018-05-30
Requested 2018-05-16
Requested by Suresh Krishnan
Other Reviews Secdir Last Call review of -16 by Daniel Migault
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
Genart Telechat review of -16 by Russ Housley
Review State Completed
Reviewer Brian Haberman
Review review-ietf-dmm-ondemand-mobility-14-intdir-early-haberman-2018-05-21
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/rOVvfpS1L5ATyxfplLcOZHHiaTE
Reviewed rev. 14 (document currently at 16)
Review result Not Ready
Draft last updated 2018-05-21
Review completed: 2018-05-21

Review
review-ietf-dmm-ondemand-mobility-14-intdir-early-haberman-2018-05-21

This is an early review request for draft-ietf-dmm-ondemand-mobility.

I am having a hard time with the thrust of this document. The following issues really need to be addressed in some form...

1. Where is the concept of an IP session defined? Given that IP is connectionless, this term is really about IP address stability and its lifetime. A new term could/should be coined to reflect what is really needed.

2. The needs described in this document have a mix of the ID/Location split issues raised in a variety of other specifications. It would be good to clarify what is different here.

3. The draft only references host-based Mobile IP specifications. What are the implications when other solutions (e.g., PMIP) are employed?

4. It is problematic that this document explicitly rules out of scope any discussion of how this API interacts with address assignment methods (e.g., DHCP). Clearly, there will need to be a way for this API to influence each of the address assignment methods available. Some of the classes of IP addresses described in this document require certain lifetime guarantees from the address assignment method. That needs to addressed since it will  require changes to every assignment method.

5. The IETF has a very checkered history of success in getting APIs standardized within the appropriate group (POSIX/Austin/Open). Has this proposed API been discussed within that community?