Skip to main content

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 revision No specific revision (document currently at 18)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2018-05-30
Requested 2018-05-16
Requested by Suresh Krishnan
Authors Alper E. Yegin , Danny Moses , Seil Jeon
I-D last updated 2018-05-21
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 Brian Haberman
State Completed
Request Early review on draft-ietf-dmm-ondemand-mobility by Internet Area Directorate Assigned
Reviewed revision 14 (document currently at 18)
Result Not ready
Completed 2018-05-21
review-ietf-dmm-ondemand-mobility-14-intdir-early-haberman-2018-05-21-00
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?