Re: [MEXT] The first proposal for the DMM charter

Jari Arkko <jari.arkko@piuha.net> Tue, 20 December 2011 08:29 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15C21F89BA for <mext@ietfa.amsl.com>; Tue, 20 Dec 2011 00:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNBZDzoGF5Sz for <mext@ietfa.amsl.com>; Tue, 20 Dec 2011 00:29:57 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8C21F89B8 for <mext@ietf.org>; Tue, 20 Dec 2011 00:29:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 592812CC4D; Tue, 20 Dec 2011 10:29:55 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT03rpQE+06d; Tue, 20 Dec 2011 10:29:53 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 99D6A2CC31; Tue, 20 Dec 2011 10:29:53 +0200 (EET)
Message-ID: <4EF04781.3080700@piuha.net>
Date: Tue, 20 Dec 2011 10:29:53 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: jouni korhonen <jouni.nospam@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
In-Reply-To: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "julien.ietf@gmail.com Laganier" <julien.ietf@gmail.com>, mext@ietf.org
Subject: Re: [MEXT] The first proposal for the DMM charter
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 08:29:58 -0000

I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility protocol part", because it confuses me. And per questions on the list, it seems to confuse other people too.

Suggested edits below. I have sent this version to the IESG and IAB, but I expect that the chairs may produce additional refined versions.

Distributed Mobility Management (DMM)
-------------------------------------

Charter

  Current Status: Active

  Chairs:
      Julien Laganier <julien.ietf@gmail.com>;
      Jouni Korhonen <jouni.nospam@gmail.com>;

  Internet Area Directors:
      Ralph Droms <rdroms.ietf@gmail.com>;
      Jari Arkko <jari.arkko@piuha.net>;

  Internet Area Advisor:
      Jari Arkko <jari.arkko@piuha.net>;

  Mailing Lists:
      General Discussion: mext@ietf.org
      To Subscribe:       https://www.ietf.org/mailman/listinfo/mext
      Archive:            http://www.ietf.org/mail-archive/web/mext

Description of Working Group:

   The Distributed Mobility Management (DMM) working group specifies IP
   mobility, access network and routing solutions, which allow for
   setting up IP networks so that traffic is distributed in an
   optimal way and does not rely on centrally deployed anchors to manage
   IP mobility sessions. The distributed mobility management solutions
   aim for transparency above the IP layer, including maintenance of
   active transport level sessions as mobile hosts or entire mobile
   networks change their point of attachment to the Internet.

   The protocol solutions should be based on existing IP mobility
   protocols, either host- or network-based, such as Mobile IPv6
   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
   NEMO [RFC3963]. Solutions may also focus specifically
   on managing the use of care-of versus home addresses in an
   efficient manner for different types of communications.

   Although the maintenance of stable home address(es) and/or prefix(es)
   and upper level sessions is a desirable goal when mobile hosts/routers
   change their point of attachment to the Internet, it is not a strict
   requirement. Mobile hosts/routers should not assume that IP
   addressing including home address(es) and/or home network prefix(es)
   remain the same throughout the entire upper level session lifetime,
   or that support for mobility functions is provided on the network side
   in all conditions.

   The distributed mobility management solutions primarily target IPv6
   Deployment and should not be tailored specifically to support IPv4,
   in particular in situations where private IPv4 addresses and/or NATs
   are used. At least IPv6 is assumed to be present in both the mobile
   host/router and the access networks. Independent of the distributed
   mobility management solution, backward compatibility must be
   maintained. If the network or the mobile host/router do not support
   the distributed mobility management enabling protocol, nothing should
   break.

Work items related to the distributed mobility management include:

   o Solution Requirements: Define precisely the problem of distributed
     mobility management and identity the requirements for a distributed
     mobility management solution.

   o Best practices: Document best practices for the
      deployment of existing mobility protocols in a distributed mobility
      management environment.

  o  Gap Analysis and extensions: identify the limitations in the best current
      practices with respect to providing the expected functionality.

   o If limitations are identified as part of the above deliverable,
     specify extensions to existing protocols that removes these
     limitations within a distributed mobility management environment.

Goals and Milestones:

   Aug 2012 - Submit I-D 'Solution Requirements' as a working
              group document. To be Informational RFC.
   Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
              group document. To be Informational RFC.
   Nov 2012 - Evaluate the need for additional working group document(s)
              for extensions to fill the identified gaps.
   Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
              consideration as an Informational RFC.
   Jan 2013 - Submit I-D 'Best practices ' to the IESG for
              consideration as an Informational RFC.
   Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for
              consideration as an Informational RFC.
   Mar 2013 - Evaluate the need for further work based on the identified gaps
              and revise the milestones and/or the charter of the group