Skip to main content

Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6
draft-ietf-roll-mpl-parameter-configuration-08

Yes

(Alvaro Retana)

No Objection

(Alissa Cooper)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

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

Alia Atlas Former IESG member
(was Discuss) Yes
Yes (2015-09-29 for -06) Unknown
Thank you for addressing my Discuss so thoroughly!
Alvaro Retana Former IESG member
Yes
Yes (for -04) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2015-11-01) Unknown
Version -08 addresses my comments, and thanks very much!
Ben Campbell Former IESG member
No Objection
No Objection (2015-07-07 for -06) Unknown
-- 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 Former IESG member
No Objection
No Objection (2015-07-08 for -06) Unknown
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.
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2015-11-11) Unknown
Thanks for addressing these issues.
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-07-08 for -06) Unknown
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 Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-07-08 for -06) Unknown
- 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:-(
Terry Manderson Former IESG member
No Objection
No Objection (for -06) Unknown