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
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Jari Arkko; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
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; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
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.
(Ron Bonica; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
No objection provisional on nothing bad being uncovered in IETF LC
(Wesley Eddy; former steering group member) No Objection