Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals

Julien Laganier <julien.laganier.ietf@googlemail.com> Tue, 12 May 2009 12:32 UTC

Return-Path: <julien.laganier.ietf@googlemail.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038D83A694A for <mext@core3.amsl.com>; Tue, 12 May 2009 05:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599]
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 0U3+X1WL5iDe for <mext@core3.amsl.com>; Tue, 12 May 2009 05:32:10 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 6FD0F3A691B for <mext@ietf.org>; Tue, 12 May 2009 05:32:10 -0700 (PDT)
Received: by fxm2 with SMTP id 2so3291983fxm.37 for <mext@ietf.org>; Tue, 12 May 2009 05:33:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=J1Z1QkXPutOwKZvsR84mFbNcObUbJAH5pJB3e0q+eEM=; b=ZwV1IdBxGpfxhG5JHaKOL6z5cbaAzvtjLmsqJ6vCARHq9ReGzEyveFNFhfBVdTWgm9 06M5io8xvl1pLEAGiPsbcdVOIswBsqEWrgo/ocNqGPe6trWq0bowvb3MfUcWPSSgHasX pqhKGCg9Y2pmzvKawz5T9R81YWpg2qlhgKSC8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=tVsbh85s7HRs2JpHi+5qBArzXIwsY0W6U8ubjnIo3YIl7s5fXj9KJGRGazbiwdjUDK wBlCCpiVm8IAeO805fu0eucmLFXQbJzjMYYEvG6B7R8/LoSzm8FDbWqjJdh1LUo65sYG 7imJc07F1rUiQxAaAUQYXY+u3TiEwwBp/HsQU=
Received: by 10.204.50.195 with SMTP id a3mr8028820bkg.94.1242131618404; Tue, 12 May 2009 05:33:38 -0700 (PDT)
Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id 12sm9584776fks.7.2009.05.12.05.33.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 May 2009 05:33:37 -0700 (PDT)
From: Julien Laganier <julien.laganier.ietf@googlemail.com>
To: mext@ietf.org
Date: Tue, 12 May 2009 14:33:38 +0200
User-Agent: KMail/1.9.10
References: <878wl95jpk.fsf@small.ssi.corp> <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com>
In-Reply-To: <3DEFD3B0-507E-482E-8219-9FA831008412@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200905121433.38751.julien.laganier.IETF@googlemail.com>
Subject: Re: [MEXT] Review of draft-ietf-monami6-multiplecoa-13 + Proposals
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 12 May 2009 12:32:12 -0000

Hello Ryuji, 

Cutting thru quite a bit:

On Monday 11 May 2009, Ryuji Wakikawa wrote:
> 
> [...]
> >>   Binding ID (BID)
> >>
> >>      The BID which is assigned to the binding indicated by the
> >> care- of
> >>      address in the Binding Update or the Binding Identifier
> >> mobility option.  The BID is a 16-bit unsigned integer.  The value
> >> of zero
> >>      is reserved and MUST NOT be used.
> >
> > The value MUST NOT be used. 2 questions:
> >  - maybe the rationale for that decision could be provided
> >  - what if a peer receives a BID with that value. What behavior is
> >    specified in that case and what will it allow if at some point
> > that reserved value needs to be used?
>
> This is actually SHOULD NOT.
> This is error when I updated the document.
>
> In section 5.1, we've had the update texts.
>     "A mobile node assigns a BID to each care-of address when it
> wants to
>     register them simultaneously with its home address.  The BID MUST
> be unique for a given home address.  The value is an integer between
> 1 and 65535.  Zero value SHOULD NOT be used as BIDs.  If a mobile
> node has only one care-of address, the assignment of a BID is not
> needed until it has multiple care-of addresses to register with, at
> which time all of the care-of addresses MUST be mapped to BIDs."
>
> Any future document can overwrite this spec.
> As for MCoA, we don't use zero value.
>
> There is background story here. The flow binding document needs
> default binding.
> We had used zero value to specify the default binding in MCoA.
>
> After the long discussion in WG, we agreed not to have this value in
> MCoA.
> The default binding should be defined in the flow binding.

Sorry to jump in the discussion, but IMHO what you want to achieve would 
actually be better reflected with the following than by a "value zero 
SHOULD not be used":

In 4.3.
-------

   Binding ID (BID)

      The BID which is assigned to the binding indicated by the care-of
      address in the Binding Update or the Binding Identifier mobility
      option.  The BID is a 16-bit unsigned integer.  The value of zero
      is reserved and MUST NOT be set by the sender and MUST be treated
      as an error by the receiver (MCOA MALFORMED).


In 5.1.
-------

   A mobile node assigns a BID to each care-of address when it
   wants to register them simultaneously with its home address. For a
   given home address, the assigned BID MUST be a unique integer between
   1 and 65535. The BID value zero MUST NOT be assigned, MUST NOT be
   sent in a Binding Identifier Mobility Option, and MUST be treated as
   an error (MCOA MALFORMED) by the receiver of a Binding Identifier
   Mobility Option. If a mobile node has only one care-of address, the
   assignment of a BID is not needed until it has multiple care-of
   addresses to register with, at which time all of the care-of
   addresses MUST be mapped to BIDstoo.

What do you think?

--julien