Re: [netext] Review of draft-ietf-netext-bulk-re-registration-04.txt

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 26 September 2011 08:19 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38921F8B45 for <netext@ietfa.amsl.com>; Mon, 26 Sep 2011 01:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 2MKxW75zwOmC for <netext@ietfa.amsl.com>; Mon, 26 Sep 2011 01:19:32 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8561F21F8B3C for <netext@ietf.org>; Mon, 26 Sep 2011 01:19:31 -0700 (PDT)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B2879BF085D; Mon, 26 Sep 2011 10:22:12 +0200 (CEST)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Sri Gundavelli <sgundave@cisco.com>
Date: Mon, 26 Sep 2011 10:22:12 +0200
In-Reply-To: <CA9B88D7.290A9%sgundave@cisco.com>
References: <CA9B88D7.290A9%sgundave@cisco.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-602fpLnOaayO8sbF+jyM"
X-Mailer: Evolution 3.0.3-
Message-ID: <1317025332.4050.8.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18408.003
Cc: netext@ietf.org, draft-ietf-netext-bulk-re-registration@tools.ietf.org
Subject: Re: [netext] Review of draft-ietf-netext-bulk-re-registration-04.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2011 08:19:33 -0000

Hi Sri,

I think I forgot to reply to this. Thanks for considering the comments.
I'm fine with your replies.

Carlos

On Sun, 2011-09-18 at 11:39 -0700, Sri Gundavelli wrote:
> Hi Carlos,
> 
> Thanks for the careful review. Please see inline. Thanks !
> 
> 
> 
> On 8/17/11 7:46 PM, "Carlos Jesús Bernardos Cano" <cjbc@it.uc3m.es> wrote:
> 
> > Hi all,
> > 
> > As agreed during the last IETF meeting, I've performed a review of the
> > draft.
> > 
> > Overall, I think the document is in good shape and well written. I have
> > some comments/question, and it might be that some of them have been
> > already discussed on the ML (apologies if I missed that discussion).
> > 
> > - Section 3.1: I think that the paragraph starting with "A mobile access
> > gateway requests a bulk-registration..." should not appear there, as
> > Section 3.2 deals specifically with that, so now it is a bit
> > misleading/repetitive. It may lead the reader to believe that the MAG,
> > after requesting to add an MN into a bulk re-registration set, it has to
> > immediately send another PBU to set the binding. It becomes clear later
> > in the doc that this is not the case, when I was reading that part it
> > was not that clear to me.
> >
> 
> Will fix this.
> 
>  
> > - Section 3.2.2: when the LMA decide to remove a single MN from its
> > current bulk registration set, the LMA sends what is called
> > "non-solicited regular PBAck message". Is that message used in any other
> > spec? I think it is not a good idea to add unsolicited PBAcks, as it
> > makes more complex the state machine of the implementation of the MAG. I
> > think in the rest of the PMIPv6 extensions that are being developed in
> > NETEXT, new messages have been preferred over overloading too much
> > PBU/PBA or change its way operation significantly. It may be better to
> > use instead a new message, like it is done in RFC 5846 with the BRI/BRA
> > signaling.
> >
> 
> Agree. This is a remnant from the previous fix. Will fix it.
> 
> 
>  
> > - Editorial. Section 3.2.3: "the bulk registration (B) flag set" -->
> > "the bulk registration (B) flag set to 1".
> > 
> > - Section 3.2.3: "Such PBU message lacks any options that identify" -->
> > should we use some normative text there, like "Such PBU message MUST NOT
> > include any options that identify"?
> > 
> 
> We will fix this as part of the rewrite of this paragraph
> 
> 
> > - Editorial. Section 3.2.3, second paragraph: "mobile access gateway
> > MUST" --> "The mobile access gateway MUST".
> >
> 
> Ok
>  
> > - Section 3.2.3: In the last paragraph, I'd add some normative text
> > there.
> >
> 
> Ok
>  
> > - Editorial, Section 3.2.4, first paragraph: I think some rewriting is
> > needed, because the "(a) in the expiration..." and "(b) on the
> > termination..." does not seem completely right to me.
> >
> 
> Ok
> 
>  
> > - Editorial, Section 4.2: "The value of flag MUST NOT be set to the
> > value of (1)" --> "The value of the flag MUST NOT be set to (1)".
> > 
> 
> Sure
> 
> 
> > - Section 4.2: "All other fields in the Proxy Binding Acknowledgment
> > message and the mobility options..." --> is that true? are not some
> > additional restrictions on what options can go on the PBA, such any that
> > refers to an individual MN?
> > 
> 
> The specific options for inclusion/exclusions are identified in the
> processing section. Any other options are guided by the respective specs.
> Its better to be loose on this, as its a moving train.
> 
> 
> > - Section 5.1: I think some non-normative text providing hints on what
> > are the extensions/changes required to the BUL would help developers of
> > the spec. It is true that it is not necessary to keep all the individual
> > information of the bindings, but still some needs to be kept (for
> > example the one that relates to the HNP(s) assigned to each MN).
> > analogous comment for Section 5.2 for the LMA and the BC.
> >
> 
> I normally ensure we identify the BCE extensions (which most specs did not
> do), but more than that will be debatable, given the OS variants and vendor
> preferences.
> 
> 
>  
> > - Editorial, Section 5.1.1: "to assigned" --> "to assign"
> > 
> 
> Ok
> 
> > - Editorial, Section 5.1.1, second bullet. I'd consider rewriting it a
> > bit, it's a bit hard to read it.
> >
> 
> Ok. Will work on it.
> 
>  
> > - Section 5,1.2: are the options listed there the only ones that cannot
> > be included in the PBU? I think there are others that cannot either,
> > such as the Mobile Node Link-layer Identifier Option, and I'm not sure
> > about Handoff Indicator Option and Access Technology Type Option...
> >
> 
> We never identify if other options should or should not be included. If not
> explicitly mentioned, they can be included, based on the considerations. In
> any one spec, we cannot always identify all the options.
> 
>  
> > - Editorial, Section 5.2.2, second bullet: "local mobility anchor must
> > reject" --> "local mobility anchor MUST reject".
> >
> 
> Ok
>  
> > - Editorial, Section 5.2.2, second bullet: I'd consider moving the last
> > sentence ("The local mobility anchor MUST consider..." at the beginning
> > of the bullet.
> >
> 
> Ok
>  
> > - Editorial, Section 5.2.2, fourth bullet: "revocation request, expect
> > making the scope" --> I think "expect" should be replaced with "except"
> >
> 
> Sure
> 
>  
> > - Section 6.2: does the RequestBulkReg..." config option force the MAG
> > to add ALL MNs in a bulk registration set? I guess there might be cases
> > in which that is not desired. Therefore, I'd consider changing the first
> > "MUST" there to "MAY".
> >
> 
> 
> One can surely turn off the flag and apply this selectively.
> 
>  
> > - Section 6.2: "If the flag is set to a value of (0), the mobile access
> > gateway MUST set the bulk registration flag (B) in the Proxy Binding
> > Update request to a value of (1)" --> "If the flag is set to a value of
> > (0), the mobile access gateway MUST set the bulk registration flag (B)
> > in the Proxy Binding Update request to a value of (0)".
> >
> 
> Thanks !
> 
>  
> > - Reference to RFC3775 should be changed to the brand new and shinny
> > RFC6275 :D
> > 
> 
> Yep
> 
> 
> > - I'm not sure, so I leave this to native English speakers, but to me it
> > sounds better "an MN" that "a MN".
> 
> So, here is the story:
> 
> So convinced was the Brazilian guy with my thick accent, sounding the
> acronym "MN" as "mmmmmmm ennnnn", that his criteria for article selection
> reflected my accent,. But, now I worked on the accent a bit and it sounds
> like, "eh mmm enn", so we will put a "A MN" :). On a serious note, I never
> payed attention to this ..., I assume what you say is right. Thanks !
> 
> 
> 
> > 
> > - Curiosity: where does the factor 4 come from in the expression of
> > transactions/sec?
> > 
> 
> Faud must have considered the 4-sec unit parameter in the PBU. Any case,
> this needs to be reworded.
> 
> 
> 
> 
> > Hope this helps,
> > 
> > Carlos
> 

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67