Re: [nemo] WG Last Call on draft-ietf-nemo-terminology

Romain KUNTZ <kuntz@sfc.wide.ad.jp> Fri, 25 November 2005 10:34 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efauo-0004cj-L1; Fri, 25 Nov 2005 05:34:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efaun-0004cV-1F for nemo@megatron.ietf.org; Fri, 25 Nov 2005 05:34:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08189 for <nemo@ietf.org>; Fri, 25 Nov 2005 05:34:07 -0500 (EST)
Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbE2-0000QR-6B for nemo@ietf.org; Fri, 25 Nov 2005 05:54:42 -0500
Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5C4654DFD7 for <nemo@ietf.org>; Fri, 25 Nov 2005 19:34:39 +0900 (JST)
Message-ID: <4386E94E.7090305@sfc.wide.ad.jp>
Date: Fri, 25 Nov 2005 19:37:02 +0900
From: Romain KUNTZ <kuntz@sfc.wide.ad.jp>
Organization: Keio University
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF NEMO WG <nemo@ietf.org>
Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology
References: <E1EV94s-0000Iv-L1@newodin.ietf.org> <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost> <43813545.9070804@sfc.wide.ad.jp> <1132542991.31961.14.camel@localhost> <43829840.4090501@sfc.wide.ad.jp> <1132640913.31961.67.camel@localhost> <4386C241.2030204@sfc.wide.ad.jp> <1132908361.11586.126.camel@localhost>
In-Reply-To: <1132908361.11586.126.camel@localhost>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

Chan-Wah Ng wrote:
>>>May I offer an entirely different definition:
>>>
>>>   Split-NEMO refers to the case where a mobile network becomes
>>>   two or more independent mobile networks due to the separation
>>>   of Mobile Routers which are handling the same MNP (or MNPs)
>>>   in the original mobile network before separation.
>>
>>Actually, I wonder if Split-NEMO should only refer to the case where
>>split is a problem, or to any kind of split. draft-ietf-nemo-terminology
>>is a terminology document and thus should be silent on the problems or
>>specific scenario. Other documents such as
>>draft-ietf-nemo-multihoming-issues-02 can then refer to Split-NEMO and
>>describe the problems that may occur when a split occurs (and actually
>>it already has a section about that).
>>
>>What is your opinion?
>>
> 
> Ah, which was why I first asked what is the purpose of having the
> split-NEMO terminology.  IMHO, its only useful for the case where there
> is problem.  Where else would such a terminology be useful?  I mean when
> two mobile routers previously on the same link go separate way, you
> simply say "they go separate way" or "they got separated" or "they
> separated".  There is no need to create a special term for that.

Thinking about that, a split-NEMO is basically a problem because MNNs 
may also suffer from that, even if 2 different MNPs are advertised by 
the 2 different MR that have splitted. So defining split-NEMO to any 
kind of split might be useful for people who want to use a generic term 
in their documents.

> To me split-NEMO means that a logically single entity got separated.  It
> warrants some configurations changes.  Like MNP needs to be broken into
> two parts etc, etc, which is what my latest proposal is trying to
> convey.
> 
> I agree with you that the terminology (and definition) itself should not
> contains hints of a problem.  That is the job of a problem statement.
> But the terminology is created so that we can refer to the scenario
> where the problem occurs.
> 
> "Split-NEMO" as a term is pretty much like "pinball route" to me in
> nature.  It is created to help describe a problem.

Not necessarily. IMHO if we define a term, then it's better than 
everyone (people who wants to describe a problem, or people who just 
want to refer to a separation) use the same term.

Regards,

Romain