Skip to main content

Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
draft-ietf-roll-applicability-home-building-12

Yes

(Alvaro Retana)

No Objection

(Alia Atlas)
(Ben Campbell)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

No Record

(Adrian Farrel)

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

Alvaro Retana Former IESG member
Yes
Yes (for -09) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-04-07 for -09) Unknown
I like this document a lot; thanks for the work on it.
Ben Campbell Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

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

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

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-04-06 for -09) Unknown
The draft looks good, thank you for your work on it.  I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office.  I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft.

The SecDir review had some requests for clarification in the text.  In my read, I understood what was intended, but in seeing her questions, I think it would be good to consider rewording the text she points out so it is clear to all readers.  This is non-blocking and just something to consider as I understood the intent of the current text, but that doesn't mean it can't be improved :-)

http://www.ietf.org/mail-archive/web/secdir/current/msg05589.html
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

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

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-07-25) Unknown
Thanks for the discussion about security. I didn't check
if the comments below were handled in -12, happy to
chat about that if you want.

First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must be used? I think you do.

- 4.1.8: "MUST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?


OLD COMMENTS FOR -10 below, I didn't check if you'd made
any related changes.

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/ 

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security] 
is necessarily going to proceed via the DICE WG. Depending 
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Adrian Farrel Former IESG member
(was Yes) No Record
No Record (for -09) Unknown