[Int-dir] Intdir early review of draft-ietf-dmm-ondemand-mobility-14

Brian Haberman <brian@innovationslab.net> Mon, 21 May 2018 14:24 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6013127137; Mon, 21 May 2018 07:24:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Haberman <brian@innovationslab.net>
To: <int-dir@ietf.org>
Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152691268188.22908.6810216714051964245@ietfa.amsl.com>
Date: Mon, 21 May 2018 07:24:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/rOVvfpS1L5ATyxfplLcOZHHiaTE>
Subject: [Int-dir] Intdir early review of draft-ietf-dmm-ondemand-mobility-14
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2018 14:24:42 -0000

Reviewer: Brian Haberman
Review result: Not Ready

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?