Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)
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
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
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