Bulk Binding Update Support for Proxy Mobile IPv6

Note: This ballot was opened for revision 09 and is now closed.

Jari Arkko Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Stephen Farrell No Objection

(Russ Housley) No Objection

(Pete Resnick) No Objection

Comment (2012-01-18 for -)
There are several uses of 2119 language in section 5 and 6 that are inappropriate:

5.1: I have no idea why "The following considerations MUST be applied by the mobile access gateway when supporting this specification" is at all useful. The entire sentence should be deleted.

5.1.1: This is worded oddly. It's not that the data structure "MUST be extended", it's that the new fields MUST be included. I think what you probably mean is, "The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to include the following REQUIRED additional fields." Of course I assume that they are now "required for interoperation" [2119] or that not having them "has potential for causing harm". [2119] If not, then there shouldn't be 2119 language at all.

5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the following considerations" adds. The requirements are in the paragraphs below. If you don't want to strike the sentence, sufficient would be, "The following are considerations for the mobile access gateway for requesting bulk binding update support for a mobility session."

I think the "MAY" in the first bullet should be "can".

In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise, what you're saying is "You MUST do everything in section 6.9.1 that says MUST", which seems silly and redundant.

5.1.3: In the first and second bullet, s/MAY/can

Also, the last sentence of the first and second bullets have the same problem as the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps instead, say something like "The requirement of section 5.3.3 of [RFC5213] is amended to allow a Mobile Node Group Identifier in place of the individual session identifiers."

In the third bullet, the MUST seems useless. How could the gateway not "consider the request as a bulk revocation request"?

5.2: Similar to 5.1.

5.2.1: First sentence similar to 5.1.1.

5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet up into that first sentence so it says:

   5.2.2. Enabling Bulk Binding Update Support for a Mobility Session

      The local mobility anchor will process a received Proxy Binding
      Update message as specified in [RFC5213]. However if the (B)
      flag in the received Proxy Binding Update message is set to a
      value of (1) and if it includes a Mobile Node Group Identifier
      option with sub-type value of (1) (bulk binding update group), the
      following processing takes place:

In sections 6.1 and 6.2, I am concerned about the statements containing "MUST allow the following variables to be configured by the system management" since that seems to go against 2119 where it says that the terms "must not be used to try to impose a particular method on implementors where the method is not required for interoperability." Is there an interoperability reason that these variables MUST be configurable?

Also, the SHOULD and MUSTs in the definition of the variables doesn't seem right. These are not protocol requirements; they are descriptions of the meaning of the variables.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

Comment (2012-01-17 for -)
Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request is rejected. One place to do this is 5.2.3 bullet 4, where you could say "for any reason (including administrative)" instead of "for any administrative reason".

(spt) No Objection