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

[Sri Gundavelli <[e-mail]>]

Hi Carlos,

Thanks for the careful review. Please see inline. Thanks !



On 8/17/11 7:46 PM, "Carlos Jesús Bernardos Cano" <[e-mail]> 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