Re: [DMM] Intdir early review of draft-ietf-dmm-ondemand-mobility-14

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 01 June 2018 21:28 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3012E048; Fri, 1 Jun 2018 14:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S32b5UEhc7O; Fri, 1 Jun 2018 14:28:46 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B7012E041; Fri, 1 Jun 2018 14:28:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1879; q=dns/txt; s=iport; t=1527888526; x=1529098126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wXX+ZOvp7OKtPT9OGIufWahCItGy3OdRP415V+8/UJI=; b=iLZC2qmZZkAIMQv9u5zAlARJr/OW7pa7YbzbilICSHal+wRdHhUkSGOM pArE+uMqJF11DoKwcNVcopThFz/1wwOIBMakp7Xs40F8su/Nw3yu3Bq9C jjg5kda85hTVlTEE+KvBbbYZASy4tqhTC7RV0zIdDzhhL1rHY+9KTRd31 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CjAADFuRFb/4kNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYNDgWEoCotxjGeWRYF4C4RsAoIFITQYAQIBAQEBAQECbCiFKQY6PxACAQg2EDIlAgQBDQUUB4UIqReIP4FoiD+BVD+BD4MNikcCkSWHRwkCjl+BPIN3h2KQcgIREwGBJB04gVJwFYJ+kE5vjk+BGQEB
X-IronPort-AV: E=Sophos;i="5.49,467,1520899200"; d="scan'208";a="123711751"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 21:28:45 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w51LSjdx026410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2018 21:28:45 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 1 Jun 2018 16:28:45 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 1 Jun 2018 16:28:45 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Brian Haberman <brian@innovationslab.net>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "draft-ietf-dmm-ondemand-mobility.all@ietf.org" <draft-ietf-dmm-ondemand-mobility.all@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Intdir early review of draft-ietf-dmm-ondemand-mobility-14
Thread-Index: AQHT+e+FlMk3qYXxA0GWCoQahMW9ew==
Date: Fri, 01 Jun 2018 21:28:45 +0000
Message-ID: <D736D9A2.2B9528%sgundave@cisco.com>
References: <152691268188.22908.6810216714051964245@ietfa.amsl.com>
In-Reply-To: <152691268188.22908.6810216714051964245@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.58]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <846647D9668B534298FFE284FA4E6E63@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/lSiQYXC887jN59i3w6-KdSFtY4w>
Subject: Re: [DMM] Intdir early review of draft-ietf-dmm-ondemand-mobility-14
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 21:28:55 -0000

Hi Brian,

Thanks for the review.

Authors: 

Can you please respond to these review comments and address all the
issues? Unless you address all the issues from these IESG initiated
reviews, this document is not going any where.

Sri






On 5/21/18, 7:24 AM, "Brian Haberman" <brian@innovationslab.net> wrote:

>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?