Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
draft-ietf-multimob-igmp-mld-tuning-06

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

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-03-08 for -05)
No email
send info
No objection provisional on nothing bad being uncovered in IETF LC

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Stephen Farrell) No Objection

(Pete Resnick) (was Discuss) No Objection

Comment (2012-03-28 for -05)
No email
send info
I very much agree with Adrian's DISCUSS related to asking authors about IPR. Please do.

Both the ballot writeup and the shepherd report are really inadequate. "Nothing worth noting outside ordinary WG process" is not helpful at all to the rest of the IESG to understand the history of this document. The answers in the shepherd report really give little information. The one answer of any substance was where it says, "There is a strong consensus behind this solution." Again, that sounds like a reason for Standards Track.

I agree that the Appendix should probably be in the main body.

The RFC Editor note removes the 2119 language. Note however:

4.4.  Tuning Startup Query Interval

   The [Startup Query Interval] is the interval between General Queries
   sent by a Querier on startup.  The default value is 1/4 of [Query
   Interval]; however, in this document it is RECOMMENDED that the use
   of its shortened value such as 1 second since the shorter value would
   contribute to shortening handover delay for mobile hosts in, e.g.,
   the base solution with PMIPv6 [10].  Note that the [Startup Query
   Interval] is a static value and cannot be changed by any external
   signal.  Therefore operators who maintain routers and wireless links
   MUST properly configure this value.

The MUST here isn't specifying a protocol behavior. You probably mean "need to". But do you really mean that the value MUST be 1 second?

4.6

   Thus the effects of the
   IGMP/MLD message transmission through a tunnel link SHOULD be
   considered during the parameter setting.

What interoperability problem occurs if they are not considered? Instead of SHOULD, "ought to".

6.

   This document assumes that both multicast routers and mobile hosts
   MUST be IGMPv3/MLDv2 capable

That MUST isn't a directive for this document. Instead of "MUST be", "are".

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

Comment (2012-03-13 for -05)
No email
send info
Did you consider PS for this document? Operational/interop experience might suggest changed values.

Small thing: Consider pointing out that as you start talking about Max Resp Code values larger than 12.8 seconds,
the exponential representation in 4.1.1 of RFC3376 kicks in so the granularity of changes you can indicate
becomes coarser.

(Sean Turner) No Objection