Multicast Protocol for Low-Power and Lossy Networks (MPL)
RFC 7731

Updated after additional review...

While balloting "Yes" on this document I have a number of small editorials that I believe should be made to improve the document. These are presented roughly in order of appearance in the document, you can fix them now or after the rest of the IESG ballots are in (5th February).

===

Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.

---

I think the Abstract could be a bit clearer to note the two modes of operation.

Something like

   This document specifies the Multicast Protocol for Low power and
   Lossy Networks (MPL) that provides IPv6 multicast forwarding in
   constrained networks.  MPL avoids the need to construct or maintain
   any multicast forwarding topology, disseminating messages to all MPL
   Forwarders in an MPL Domain.  

   MPL has two modes of operation. One mode uses the Trickle
   algorithm to manage control- and data-plane message transmissions,
   and is applicable for deployments with few multicast sources. The
   other mode uses classic flooding. By providing both modes and 
   parameterization of the Trickle algorithm, a MPL implementation
   can be used in a variety of multicast deployments and can trade
   between dissemination latency and transmission efficiency.

---

Section 2 : MPL Forwarder

Please add...

   The term "node" is used within this document to refer to a MPL Forwarder.

---

Section 3
OLD
   MPL is parameterized to support different dissemination techniques.
   In one parameterization, MPL may utilize the classic flooding method
   that involves having each device receiving a message rebroadcast the
   message.  In another parameterization, MPL may utilize Trickle's
   [RFC6206] "polite gossip" method that involves transmission
   suppression and adaptive timing techniques.  By supporting both
   simple flooding and Trickle methods, MPL can be configured to operate
   well in a variety of situations [Clausen2013].
NEW
   MPL is parameterized to support different dissemination techniques.
   In one parameterization, MPL may utilize the classic flooding method
   that involves having each device receiving a message rebroadcast the
   message.  In another parameterization, MPL may utilize Trickle's
   [RFC6206] "polite gossip" method that involves transmission
   suppression and adaptive timing techniques. [Clausen2013] questions 
   the efficiency of Trickle's "polite gossip" mechanism in some
   multicast scenarios, so by also including a classic flooding mode of 
   operation MPL  aims to be able to perform satisfactorily in a variety
   of situations
END

---

4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.

Ditto 5.1

---

In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:

   All MPL interfaces on the same link SHOULD be configured with the same 
   value of PROACTIVE_FORWARDING.

I thought about asking for "MUST", but I think that is too strong. However, if using
"SHOULD" it would also be good to have something like...

   An implementation MAY choose to vary the value of PROACTIVE_FORWARDING
   across interfaces on the same link if <supply text here>.

---

Section 6.3

   The Option Data (in particular the M flag) of the MPL Option is
   updated by MPL Forwarders as the MPL Data Message is forwarded.

s/in particular/specifically/

---

Section 13.

Please add a short paragraph on the comparative security implications of classic flooding mode.

---

Please update the reference to read as follows:

   [Clausen2013]
             Clausen, T., Colin de Verdiere, A., and J. Yi,
             "Performance Analysis of Trickle as a Flooding Mechanism",
             November 2013. The 5th IEEE International Conference on 
             Communication Technology (ICCT2013)