Skip to main content

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

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.

Alvaro Retana Yes

(Alia Atlas; former steering group member) (was Discuss) Yes

Yes (2015-09-29 for -06)
Thank you for addressing my Discuss so thoroughly!

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2015-11-01)
Version -08 addresses my comments, and thanks very much!

(Ben Campbell; former steering group member) No Objection

No Objection (2015-07-07 for -06)
-- 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 steering group member) No Objection

No Objection (2015-07-08 for -06)
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 steering group member) (was Discuss) No Objection

No Objection (2015-11-11)
Thanks for addressing these issues.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -06)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -06)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -06)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-07-08 for -06)
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 steering group member) No Objection

No Objection (for -06)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -06)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-07-08 for -06)
- 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 steering group member) No Objection

No Objection (for -06)