Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard

Behcet Sarikaya <behcetsarikaya@yahoo.com> Mon, 13 September 2010 15:55 UTC

Return-Path: <behcetsarikaya@yahoo.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7B13A6A11 for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 08:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level:
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFU9EweXYEIq for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 08:55:37 -0700 (PDT)
Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id E5B0A3A69F8 for <ietf@ietf.org>; Mon, 13 Sep 2010 08:55:36 -0700 (PDT)
Received: (qmail 11271 invoked by uid 60001); 13 Sep 2010 15:56:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1284393360; bh=axGkkiYoIvekUw84riqdLXR/0wsKq+JKlQbQWkuYT80=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FOMFbnzpovXdekjYtgUomadnNODT8djz8NDLyktAIWScBPoF2XuTfYjAggFDL8YD7XwsYU7k1RDOzEXBpIp2b33NAN1YB27rp7EEwMdt//ig9Qs2MhwddB0DTcCRX14EV92FtnJ0fKZ0L/cE+X8M6BqBpRmJ2Jho7yEiBCUJ4XU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r11XV9VNdWPpw/I6GgU2csdi01mBkUhvrxREgy3VVkWX08o1+Hm4yV0Cztaea2zPFGlq54WYoPwd9WNyN+LlwySHpkFC9uEZ0QN6TlhHPHocsKaeoVgPnyDsGEwkAgOszn7pjy1zY8zquf7MEGrgbKyfChDlZ5c1jRufA5y8uXA=;
Message-ID: <165516.11213.qm@web111411.mail.gq1.yahoo.com>
X-YMail-OSG: BAfuHqQVM1n.Uv_8HuIb9G2GWfCcxsjKI2aLSp_QN6VSdi9 nbVUbVvxoPBc_d2073Zz93iaHSlBilT50ugtOGOK0v9SD9YJGPCn60fVOl7B OfCo8ntU7Jw4NiX3MPgXPpiKECyp37_VpXQeyPQg2xCBnyHbdOg3FZDlCM6c 9H7.cMO2p6m2U38YerxjbHCefl2bS_pn7sFO_tXgtVSrw1_jYZneAPZ1_4tF Um111TH91DMLHdwxzD9yPhm6Zg8ZJaCaAlDHKVxavJ.KWIk_SBtfwLPci.2i SimUkmjV30TDJJY42B_pbmYluj5eaQzZ.WKu9AoYd7ETjLmXdjHBJaum_9s2 QJrVGPJA694PRnMsDVc74avzPRQ--
Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Mon, 13 Sep 2010 08:55:59 PDT
X-Mailer: YahooMailRC/470 YahooMailWebService/0.8.105.279950
References: <C8B03E68.14FA4%hesham@elevatemobile.com> <4C8A1DEF.9050403@gmail.com> <BF345F63074F8040B58C00A186FCA57F1F6826E30A@NALASEXMB04.na.qualcomm.com>
Date: Mon, 13 Sep 2010 08:55:59 -0700
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix Delegation for NEMO) to Proposed Standard
To: "Laganier, Julien" <julienl@qualcomm.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>, Hesham Soliman <hesham@elevatemobile.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F6826E30A@NALASEXMB04.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IETF Discussion <ietf@ietf.org>, mext <mext@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 15:55:38 -0000


----- Original Message ----
> From: "Laganier, Julien" <julienl@qualcomm.com>
> To: Alexandru Petrescu <alexandru.petrescu@gmail.com>; Hesham Soliman 
><hesham@elevatemobile.com>
> Cc: IETF Discussion <ietf@ietf.org>; mext <mext@ietf.org>
> Sent: Fri, September 10, 2010 11:57:36 AM
> Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix 
>Delegation for NEMO) to Proposed Standard
> 
> Alexandru Petrescu wrote:
> > 
> > Le 10/09/2010 11:58, Hesham Soliman a  écrit :
> > >
> > > On 10/09/10 7:55 PM, "Alexandru
> > >  Petrescu"<alexandru.petrescu@gmail.com>  wrote:
> > >
> > >> Le 10/09/2010 11:48, Hesham Soliman a écrit  :
> > >>>>>
> > >>>>> =>     Who cares, specify it in your product description. The
> >  >>>>>       IETF doesn't specify how to build  products.
> > >>>>
> > >>>> Hmm... to me it is a  very IETF sensitive issue the Router vs
> > >>>> Host. For  example, an ND spec says distinctively what a Host
> > >>>> and  what a Router does, e.g. a Host does not respond to Router
> >  >>>>  Solicitation.
> > >>>
> > >>>  =>   Yes and it does so on a per-interface basis, not on a
> >  >>> per-machine basis.
> > >>
> > >> Yes, and the  Mobile Router is a Router on its egress interface
> > >> when  connected at home, as per spec.  It is that interface that
> > >>  needs a default route automatically configured.
> > >
> > >  =>  Ok, so you're happy with it being half host half router when  it's
> > > away from home?
> > 
> > When it is away from home it  is fully a Host on the egress interface.
> > When at home fully Router on  same.  I am happy with it this way.
> > 
> > > If so then let it  do the same at home. Otherwise, I don't know how
> > > you want to fix  this in this WG.
> > 
> > It would mean to specify it to be a at home,  be first a Host (get
> > default route) then change and become a Router, but  still at home.
> >
> > This behaviour could be set in the DHCPv6-PD-NEMO  draft, being under
> > discussion now.
> 
> This is a non issue for this  draft. This is not specific to NEMO but generic 
>to any DHCPv6 Prefix Delegation  setup where the requesting router needs to 
>configures an address on its north  side. It can do so as per the deployment 
>specifics, including, but not limited  to, acting as a host on the north 
>interface and as a router on south interfaces  -- please remember that Neighbor 
>Discovery is specified on a per-interface  basis.
> 
> [ I also note that this draft has been more than 2 years in the  MEXT working 
>group in which you are participating, which gave you ample time to  comment on 
>this and other things...  ]
> 

Julien: Alex, myself, possibly others have been raising issues with this draft 
since long time.

It is not new.

Regards,

behcet