Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
draft-ietf-mboned-lightweight-igmpv3-mldv2-06

[Ballot discuss]
First, I support those who stated that protocol modifications
should process as Exp/Inf/PS as opposed to a BCP. In addition,
I would like to talk on the call about:

1. What level of review this has gotten outside mboned (e.g., v6
community). In particular, I'm interested in what interop experience
we may have to support the statement from the document that this does
cause problems?

2. How does this fit the MBONED charter?

[Ballot discuss]
This should be PS instead of BCP.

This is slightly more than a simple profiling of the parameters of another protocol - there appears to be additional logic that an implementation will have to perform correctly. It also doesn't appear to be recommending "full and immediate instantiation". Rather, it seems to be a good candidate for the normal PS->DS->S progression.

[Ballot discuss]
Why is this a BCP and not PS?

Section 1., paragraph 5:
>    Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full
>    version of these protocols (i.e., the standard IGMPv3 and MLDv2),
>    hosts or routers that have implemented the full version do not need
>    to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
>    hosts or routers.

  DISCUSS: They may not need to implement anything, but if they send an
  EXCLUDE to a lightweight peer they better be prepared for it to be
  ignored. On the call, I'd like to discuss how that affects
  interoperability. Is this something that's permitted in the full version?

[Ballot comment]
The Gen-ART Review by Brian Carpenter on 2009-09-01 raises a question
  about this text:

  > 1.  Introduction
  ...
  >  Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full
  >  version of these protocols (i.e., the standard IGMPv3 and MLDv2),
  >  hosts or routers that have implemented the full version do not need
  >  to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
  >  hosts or routers.
 
  I assume this also means that LW-IGMPv3 and LW-MLDv2 are strict subsets
  of IGMPv3 and MLDv2. If so, it would be useful to say so explicitly.

[Ballot comment]
From the second para of the Introduction:

  INCLUDE and EXCLUDE filter-modes are introduced to support the source
  filtering function.

"are introduced" by IGMPv3 and/or MLDv2, or ???

[Ballot comment]
Technical Summary

    This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
    IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
    IGMPv3 and MLDv2.  The interoperability with the full versions and
    the previous versions of IGMP and MLD is also taken into account.

Working Group Summary

    This draft has received strong support within the working group and
    no major controversies were noted.

Document Quality

    Multiple implementations of this specification exist.  A number of
    other vendors have indicated interest/plans to support this
    specification.  Bharat Joshi provided the most extensive comments
    and questions for the document.  Authors addressed the questions and
    concerns in the document.  Otherwise, mailing list traffic regarding
    this specification has been minimal.  There has been extensive
    comments on this proposal during the working group meetings.

Personnel

    Lenny Giuliano is the Document Shepherd, Ron Bonica is the
    Responsible Area Director.