Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
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 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)
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 . 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)
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.