Re: [DMM] WG Review: Distributed Mobility Management (dmm)

Abdussalam Baryun <abdussalambaryun@gmail.com> Tue, 07 October 2014 05:50 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472E71A9125; Mon, 6 Oct 2014 22:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.525
X-Spam-Level:
X-Spam-Status: No, score=0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_RHS_DOB=1.514] autolearn=no
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 GN4HuLVEEraB; Mon, 6 Oct 2014 22:50:06 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0571A9124; Mon, 6 Oct 2014 22:50:05 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id c41so2677895yho.34 for <multiple recipients>; Mon, 06 Oct 2014 22:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2utE+tD+YfvtnHGDB27VyRpZGvs3b1ioEtv9ZQ/9hnM=; b=sYixUJUJDKe58bRIWXkxJEPm+HOqNGCCtuwbfikpH4T4A+C0sMC9wIgIgcdnYH5zW+ cxlqBKZFCpwQc0erWEfvKJrh91XX58KSjSvG4D8mo+eKYnm4cDeNpLkXALOUTvxSIduE bQo6y2zHju4CclUHw9TiP4NhA12nUnhqNgD+/vULJSXccofrY+7uqb7qbhchYZorwZ4v zZEZkGatdHJYwm+x7qGjRDfxd/c3QL1GJtiJM6Z5pR3bXKqBqNS/qeOjEeq0JD3k6whu KUXZFn+i6iS4Mfs9pIigFhuCwTpmcKdNwjrx0mXI4CECiDpae0fvrR0lM0KcRoX2pM1M 9mrg==
MIME-Version: 1.0
X-Received: by 10.236.131.48 with SMTP id l36mr2561672yhi.110.1412661004757; Mon, 06 Oct 2014 22:50:04 -0700 (PDT)
Received: by 10.170.194.68 with HTTP; Mon, 6 Oct 2014 22:50:04 -0700 (PDT)
In-Reply-To: <20141003193829.9669.13386.idtracker@ietfa.amsl.com>
References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com>
Date: Tue, 07 Oct 2014 07:50:04 +0200
Message-ID: <CADnDZ88K0XQ11bp9hVdSrDn58-1=NOtAYRr_Z6_pP==nbr=7rw@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="20cf301b67d960703c0504cec5f9"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/blMJNZNGO1m9Zb72d8q7asdMVpc
X-Mailman-Approved-At: Mon, 06 Oct 2014 23:18:49 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, dmm WG <dmm@ietf.org>
Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 07 Oct 2014 05:50:08 -0000

Dear IESG,

I received you message request for review, but there are some issues
missing for my review. For example there is no milestones presented even
though the submitted charter states below

 "The working group may decide to extend the current milestones based on
the new information and knowledge gained during working on other
documents listed in the initial milestones. "

Where are the initial milestone, the above statement refers to? did this WG
decide on the milestones or not? When I review the WG production there is
only one RFC and one adopted draft, while previous charters were aiming for
more drafts. In first charter dated 2007 there were about three work
items/drafts suggested without milestones which is ok because it is new but
what happened? I want to know why we did not achieve that? an input from
the AD can help.

Creating/Rechartering WGs while not having clear milestones will cost
IETF. I need to see in your review request of charter/recharter the
following so that I can make better review:

- if new WG, there can be no milestones decided, but need to have some
individual drafts submitted for discussions and for future adoption plans.
- if new WG, there should be in the charter related works/RFCs in IETF that
this WG will consider.
- if recharter WG, I need to know its evaluation of previous charter(s),
and why recharter?
- if recharter WG, I need to know clear milestones (dates of submissions
and date of conclude) and clear/stated adopted drafts and non adopted
drafts that are under consideration.
- All WG charters MUST have a date of conclude/recharter, otherwise we may
waste time/space/money in IETF.
- I prefer if the IETF charter has sections that are must and sections that
are optional, so that we agree on how we review such charter. I think
milestones are must for recharters and optional for new WG charter.
- I require for my best review for recharter, a review AD evaluation
section for the WG's previous charter(s) and challenges.

Please note we need to take care with the charter details,
the WG-decisions and then recharter review. Therefore, I object this WG to
recharter until its WG decides the milestones and have clear work adoption
plan related to drafts mentioned in the charter.

Regards,

AB

On Friday, October 3, 2014, The IESG wrote:

> The Distributed Mobility Management (dmm) working group in the Internet
> Area of the IETF is undergoing rechartering. The IESG has not made any
> determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to
> the IESG mailing list (iesg at ietf.org) by 2014-10-13.
>
> Distributed Mobility Management (dmm)
> ------------------------------------------------
> Current Status: Active WG
>
> Chairs:
>   Dapeng Liu <liudapeng@chinamobile.com <javascript:;>>
>   Jouni Korhonen <jouni.nospam@gmail.com <javascript:;>>
>
> Assigned Area Director:
>   Brian Haberman <brian@innovationslab.net <javascript:;>>
>
> Mailing list
>   Address: dmm@ietf.org <javascript:;>
>   To Subscribe: https://www.ietf.org/mailman/listinfo/dmm
>   Archive: http://www.ietf.org/mail-archive/web/dmm
>
> Charter:
>
> Mobility management solutions lie at the center of the wireless Internet
> and enable mobile devices to partake in IP networks anytime and
> anywhere. The IETF Distributed Mobility Management (DMM) working group
> (WG) specifies solutions for IP networks so that traffic between mobile
> and correspondent nodes can take an optimal route. DMM solutions aim for
> transparency above the IP layer, including maintenance of active
> transport level sessions when mobile hosts or mobile networks change
> their point of attachment to the Internet.
>
> Wireless network deployments have traditionally relied on hierarchical
> schemes that often lead to centralized deployment models, where a small
> number of mobility anchors manage both mobility and reachability for a
> mobile node. The DMM WG will consider the latest developments in mobile
> networking research and operational practice (i.e. flattening network
> architectures, the impact of virtualization, new deployment needs as
> wireless access technologies evolve in the coming years) and will
> describe how distributed mobility management addresses the new needs in
> this area better than previously standardized solutions.
>
> A topic of particular focus will be mobility anchoring in this new
> context, and the DMM working group is chartered to work on
> maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
> 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new
> approaches which capitalize on other protocols specified by the IETF.
> For example, mobility management in a limited area, such as within an
> autonomous system, is not strictly limited to mentioned IP mobility
> protocols but can be any existing or a new protocol solution enabling
> the movement of a mobile node such as routing protocols. When extending
> protocols that are not based on Mobile IP, DMM solutions will have to be
> reviewed by the corresponding WGs.
>
> IPv6 is assumed to be present in both the mobile host/router and the
> access networks. DMM solutions are primarily targeted at IPv6
> deployments and are not required to support IPv4, in particular for the
> case where private IPv4 addresses and/or NATs are used. DMM solutions
> must maintain backward compatibility:  If the network or the mobile
> host/router does not support the distributed mobility management
> protocol that should not prevent the mobile host/router gaining basic
> access (i.e., nomadic) to the network.
>
> Contrary to earlier IP mobility protocols, mobility management signaling
> paths and end-user traffic forwarding paths may differ. Further,
> mobility-related functions may be located in separate network nodes. DMM
> solutions should not distinguish between physical or virtualized
> networking functions. Whenever applicable, clarifications and additional
> features/capabilities for specific networking function deployment
> models, e.g. in virtualized environments, are in-scope and encouraged.
> Solutions may also specify the selection between the care-of addresses
> and home address(es)/prefix(es) for different application use cases.
>
> The working group will produce both informational architectural and
> standards track protocol solutions on the following work item topics.
>
>       o Distributed mobility management deployment models and scenarios:
>         describe the target high-level network architectures and
>         deployment models where distributed mobility management
>         protocol solutions would apply.
>
>       o Enhanced mobility anchoring: define protocol solutions for a
>         gateway and mobility anchor assignment and mid-session mobility
>         anchor switching that go beyond what has been specified, for
>         example, in RFC 6097, 6463, and 5142. Traffic steering
>         associated with the anchor switch is also in-scope if deemed
>         appropriate.
>
>       o Forwarding path and signaling management: the function
>         that handles mobility management signaling interacts with the
>         DMM network elements for managing the forwarding state
>         associated with a mobile node's IP traffic.  These two functions
>         may or may not be collocated. Furthermore, the forwarding state
>         may also be distributed into multiple network elements instead
>         of a single network element (e.g., anchor).  Protocol extensions
>         or new protocols will be specified to allow the above mentioned
>         forwarding path and signalling management.
>
>       o Exposing mobility state to mobile nodes and network nodes:
>         define solutions that allow, for example, mobile nodes to select
>         either a care-of address or a home address depending on an
>         application' mobility needs. In order to enable this
>         functionality, the network-side control functions and other
>         networking nodes must also be able to exchange appropriate
>         control information, as well as to the mobile nodes and their
>         applications.
>
> The working group may decide to extend the current milestones based on
> the new information and knowledge gained during working on other
> documents listed in the initial milestones. Possible new documents and
> milestones must still fit into the overall DMM charter scope as outlined
> above.
>
> Milestones:
>
>
>