[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
- [netext] Review of draft-ietf-netext-bulk-re-regi… Carlos Jesús Bernardos Cano
- Re: [netext] Review of draft-ietf-netext-bulk-re-… Sri Gundavelli
- Re: [netext] Review of draft-ietf-netext-bulk-re-… Carlos Jesús Bernardos Cano