Re: [MEXT] the future of the MEXT working group

Hidetoshi Yokota <yokota@kddilabs.jp> Fri, 11 November 2011 01:12 UTC

Return-Path: <yokota@kddilabs.jp>
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 1886E1F0C55 for <mext@ietfa.amsl.com>; Thu, 10 Nov 2011 17:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9f1zuRlwW1cu for <mext@ietfa.amsl.com>; Thu, 10 Nov 2011 17:12:47 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id A72291F0C3C for <mext@ietf.org>; Thu, 10 Nov 2011 17:12:46 -0800 (PST)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D10A2174810E; Fri, 11 Nov 2011 10:12:36 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f71z8f+42sZ; Fri, 11 Nov 2011 10:12:36 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8922A17480AB; Fri, 11 Nov 2011 10:12:36 +0900 (JST)
Received: from [127.0.0.1] (KOMOBILEX3.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 96D911B9AB; Fri, 11 Nov 2011 10:11:50 +0900 (JST)
Message-ID: <4EBC7681.8010203@kddilabs.jp>
Date: Fri, 11 Nov 2011 10:12:33 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
References: <CAD9800F.1D0F9%hesham@elevatemobile.com><350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com><4EB41DC5.1010409@earthlink.net><DF856C56-8BA2-4DCD-9CBB-BC02A3B9FCD0@nokia.com><CACvMsLE4fGeXdvRPkJvW2OZDXD8FKtjd58v0QjA39y4a7xo9Fw@mail.gmail.com> <4EBBC682.7070101@kddilabs.jp> <4EBC4537.7050501@earthlink.net>
In-Reply-To: <4EBC4537.7050501@earthlink.net>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group
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: Fri, 11 Nov 2011 01:12:48 -0000

Hi Charlie,

(2011/11/11 6:42), Charles E. Perkins wrote:
> 
> Hello Hidetoshi,
> 
> On 11/10/2011 4:41 AM, Hidetoshi Yokota wrote:
>> Hi,
>>
>> I think that the point is to give a choice to the network and user if
>> mobility is needed or not. Some applications benefit from seamless
>> mobility (e.g., VoIP), but others may not (e.g., Web access). The
>> network and user should be able to specify the capability of mobility
>> and appropriate access network for each application. In that sense,
>> Dynamic MM is an interesting feature.
> 
> I pretty much agree with this; I expect that working out the
> details will be pretty tedious and perhaps even contentious.
> 
> 
>> I agree that the current 3GPP architecture is very complicated and may
>> not be optimal, but I don't think it is a good idea to change it in 
>> IETF...
> 
> I agree we can't "change" 3GPP architecture in the IETF, but
> we can respond to the needs which are evident from considering
> the 3GPP architecture. It seems very few believe that LTE
> is really immune from further evolution and even significant
> change in the future. If IETF does NOT respond to the needs made
> evident in current 3GPP specifications, we have little hope of
> proper integration into their future evolved designs.

I fully agree with your point and am glad you initiated this discussion.
One of the reasons for its complicatedness is that the 3GPP architecture
has been incrementally built considering all the backward compatibility
and interoperability along with introducing new features and minimizing
the unhappiness of all. I respect this effort and achievement we all
enjoy today. On the other hand, the current mobile traffic is way too
much for this architecture to be able to handle. If IETF can contribute
to tackling this issue toward the future evolved design, it will be very
valuable. I don't know if DMM is the start point or we need a new WG,
but we still have a high mountain to climb.

Regards,
-- 
Hidetoshi

> Regards,
> Charlie P.
> 
> 
>