Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6
RFC 7774

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

(Alia Atlas) (was Discuss) Yes

Comment (2015-09-29 for -06)
No email
send info
Thank you for addressing my Discuss so thoroughly!

Alvaro Retana Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-07-07 for -06)
No email
send info
-- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD NOT be updated more often
   than twice of Information Refresh Time"

The preposition "of" is incorrect. Normally I would say leave that for the RFC editor, but it's not clear to me if this means "twice the information refresh time" or "twice during an information refresh time (interval)". (I assume the former, but it could be more clear.)

(Benoît Claise) No Objection

Comment (2015-07-08 for -06)
No email
send info
From the OPS-DIR review done by Menachem:

The document is quite readable.

Section 2.1 could be improved if for each parameter defined a reference would be given to indicate where the parameter is defined. I found most of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for.

Section 4 discusses Security Considerations but I think that some phrases in the paragraph are too general.
Example:  "other methods for security should be applied" does not indicate what these methods are or where to look for them.
Another Example: "To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the
border router between the ROLL network and the Internet"  - what is meant by "unnecessary DHCPv6 packets"?


NITS 
====

Section 2.3 First Paragraph Second Sentence - Remove 'is'

OLD           ==> Note that there may be cases in which a node may fail is to join a domain
SUGGEST ==> Note that there may be cases in which a node may fail to join a domain

Section 2.3 Last Paragraph is not clear.

Perhaps the last sentence should read "In this case" (instead of "In the case").


Section 2.6 - First Sentence - Not Clear

Is the update rate not to be more than twice the Information Refresh Time? Not clear to me how many updates are allowed in an Information Refresh Time.

Should the word 'of' be replaced by 'the'.

"more often than twice the Information Refresh Time".

Suggest rephrasing this paragraph.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-07-08 for -06)
No email
send info
- I don't get the update model - if all MPL forwarders have
to use the same parameters but they don't all do DHCPv6 at
the same time, then won't new parameter settings take a
while to propagate to most of the network? And won't that
cause a problem? Don't you need a "start using this set of
parameters in N seconds" field in the dhcp option to handle
that? This is not a DISCUSS as I think it relats to Barry's
so please try address this when addressing that.

- please do not pretend rfc 3315 is a solution for anything
unless you mean it and I don't think you do. 3315 is I think
the canonical example for mythical security:-(

(Brian Haberman) (was Discuss) No Objection

Comment (2015-11-11)
No email
send info
Thanks for addressing these issues.

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2015-11-01)
No email
send info
Version -08 addresses my comments, and thanks very much!

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-07-08 for -06)
No email
send info
Thank you for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05835.html

I'll follow along with the discussion from Stephen and Barry's comments, but don't have any additional to add.

(Martin Stiemerling) No Objection