Ballot for draft-ietf-roll-mpl-parameter-configuration
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Thank you for addressing my Discuss so thoroughly!
Version -08 addresses my comments, and thanks very much!
-- 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.)
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.
Thanks for addressing these issues.
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.
- 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:-(