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 18) | |
| Type | Early Review | |
| Team | Internet Area Directorate (intdir) | |
| Deadline | 2018-05-30 | |
| Requested | 2018-05-16 | |
| Requested by | Suresh Krishnan | |
| Authors | Alper Yegin, Danny Moses, Seil Jeon | |
| Draft 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 | |
| Review | review-ietf-dmm-ondemand-mobility-14-intdir-early-haberman-2018-05-21 | |
| Reviewed rev. | 14 (document currently at 18) | |
| Review result | Not Ready | |
| 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?