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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Thu, 18 August 2011 02:45 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 BBC505E8001 for <netext@ietfa.amsl.com>; Wed, 17 Aug 2011 19:45:29 -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 KkSTNFG+12MX for <netext@ietfa.amsl.com>; Wed, 17 Aug 2011 19:45:28 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2A21F8802 for <netext@ietf.org>; Wed, 17 Aug 2011 19:45:26 -0700 (PDT)
X-uc3m-safe: yes
Received: from [10.0.2.4] (modemcable093.1-80-70.mc.videotron.ca [70.80.1.93]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 1D8BFBA5899; Thu, 18 Aug 2011 04:46:16 +0200 (CEST)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: netext@ietf.org
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-y9fgQL81EmrE1bE3tk1T"
Organization: Universidad Carlos III de Madrid
Date: Thu, 18 Aug 2011 04:46:13 +0200
Message-ID: <1313635573.19516.111.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18330.003
Cc: draft-ietf-netext-bulk-re-registration@tools.ietf.org
Subject: [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: Thu, 18 Aug 2011 02:45:29 -0000

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.

- 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.

- 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"?

- Editorial. Section 3.2.3, second paragraph: "mobile access gateway
MUST" --> "The mobile access gateway MUST".

- Section 3.2.3: In the last paragraph, I'd add some normative text
there.

- 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.

- 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)".

- 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?

- 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.

- Editorial, Section 5.1.1: "to assigned" --> "to assign"

- Editorial, Section 5.1.1, second bullet. I'd consider rewriting it a
bit, it's a bit hard to read 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...

- Editorial, Section 5.2.2, second bullet: "local mobility anchor must
reject" --> "local mobility anchor MUST reject".

- 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.

- Editorial, Section 5.2.2, fourth bullet: "revocation request, expect
making the scope" --> I think "expect" should be replaced with "except"

- 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".

- 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)".

- Reference to RFC3775 should be changed to the brand new and shinny
RFC6275 :D

- I'm not sure, so I leave this to native English speakers, but to me it
sounds better "an MN" that "a MN".

- Curiosity: where does the factor 4 come from in the expression of
transactions/sec?

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