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

Note: This ballot was opened for revision 11 and is now closed.

(Adrian Farrel) Yes

Comment (2015-02-01 for -11)
No email
send info
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)

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2015-02-03 for -11)
No email
send info
Christer Holmberg's Gen-ART review had some minor editorial suggestions. Please treat these as comments that you may take into account in your editing process.

Section 1:
------------
 
Q_1_1:
 
I assume "LLN" stands for "Low power and Lossy Networks", but there is no extension anywhere. Please insert "Low power and Lossy Networks (LLN)" on first occurance.
 
 
Section 3:
------------
 
Q_3_1:
 
In a few places the text says "this protocol". I would suggest to replace that with "MPL".
 
 
Section 4:
-----------
  
Q_4_2:
 
I would suggest to add something in front of "Overview" in the subject of section 4.3. Overview of what? :)

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-06-29)
No email
send info
Thanks for adding the new text saying that this shouldn't be used
if those authorised to access the n/w can be a source of attacks.

I think you could improve the way you say that though, it'd be
better to s/attack vector/threat model/ in both the intro and 
in the security considerations. But that's really a nit and is ok to
fix (or not) at AUTH-48 IMO.

(Brian Haberman) (was Discuss) No Objection

Comment (2015-06-12)
No email
send info
Thank you for the updated text on the multicast addresses in section 4.1.  I will leave it up to you and your AD as to whether the text in section 5.1 needs to be updated in a similar fashion.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-01-26 for -11)
No email
send info
Adrian comments: "Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs."

"Mipple", then?  Oy.  Ripple trickle mipple.  But don't tipple.

Dig.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-04 for -11)
No email
send info
Thank you for responding to the SecDir review addressing Tero's questions.
https://www.ietf.org/mail-archive/web/secdir/current/msg04411.html

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection