Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
RFC 7732

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

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2015-02-18)
No email
send info
One question: In this text:

4.1.  Legal multicast messages

   Multicast messages can be created within the node by an application
   or can arrive at an interface.

   A multicast message created at a source (MPL seed) is legal when it
   conforms to the properties described in section 9.1 of
   [I-D.ietf-roll-trickle-mcast].

   A multicast message received at a given interface is legal when:

   o  The message carries an MPL option (MPL message) and the incoming
      MPL interface is subscribed to the destination multicast address.

   o  The message does not carry an MPL option, the multicast address is
      unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the
      interface has expressed interest to receive messages with the
      specified multicast address via MLD [RFC3810] or via IGMP
      [RFC3376].  The message was sent on according to PIM-DM [RFC3973]
      or according to PIM-SM [RFC4601].

   Illegal multicast messages are discarded.

4.2.  Forwarding legal packets

   A legal multicast message received at a given interface is assigned
   the network identifier of the interface of the incoming link . A
   message that is created within the node is assigned the network
   identifier "any".

   Two types of legal multicast messages are considered: (1) MPL
   messages, and (2) multicast messages which do not carry the MPL
   option.
   
Is "legal/illegal" the right terminology for this?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-19)
No email
send info
Thank you for the additions in text that resulted from the SecDir review and subsequent discussion.  I found the discussion helpful to better understand the draft and security concerns.  The current text looks good, but I did get additional context from the discussion that is not in the draft.  The 4 possibilities listed int he security considerations look good and I don't have any recommendations as reading it again after the SecDir discussion made more sense.

https://www.ietf.org/mail-archive/web/secdir/current/msg05435.html

(Martin Stiemerling) No Objection