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

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".

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.

No objection provisional on nothing bad being uncovered in IETF LC