This is  a resend of my review.  I had incorrectly entered the alias for the authors and it got bounced. My apologies to everyone who receives this twice. I have reviewed this document as part of the security directorate's  ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the  security area directors.  Document editors and WG chairs should treat  these comments just like any other last call comments. This ID gives recommendations on the use of the RPL protocol in building and home environments, which are characterized as relatively small networks that integrate a number of different devices, many including computers, alarm systems, light switches, remote controls ,etc.  Many of the network components are resource and power-constrained.   The ID  characterizes the different types of networks that can arise in these environments, and gives recommendations such  as which versions of the protocol to use and how to set the parameters, depending on the type of home network. For the security considerations the authors mainly refer the reader to RFC6997,  RFC6550, and I-D.ietf-roll-trickle-mcast.  However, there is one issue that these documents do not cover.  RPL makes the assumption that all the members of the network share a key, but intentionally does not give any information as to how the key gets there.  Thus this document includes a section on Security Considerations for distribution of certificates required by RPL.  It explains that for RPL the credential is a shared key, and then goes on to say: Therefore, there MUST be a mechanism in place which allows secure distribution of a shared key and configuration of network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) delivered securely when a device is introduced into the network or (iii) delivered securely by a trusted neighboring device. The shared key MUST be stored in a secure fashion which makes it difficult to be read by an unauthorized party. An example of a method whereby this can be achieved is detailed in [SmartObj] I found the wording of this confusing.  I took the “this” in the last sentence to refer to the storage of a key in a secure fashion, and wondered why it there were no references to means of achieving secure key distribution.  It wasn’t until I looked at the SmartOb reference that I found that it actually was such a reference.  This should be made more clear, e.g. "An example of a method whereby this secure key distribution can be achieved in detailed in [SmatObj]." I notice also that the SmartObj  paper does not seem to be finished (there are several sections labeled TODO), and that it also appears to be intended as an Internet Draft.  What is the status of it?  Is it intended to be developed in tandem with this I-D? Also, it would be good to be more specific about what is meant by “securely” here.  For example, the key must be authenticated and kept secret between its intended users, and must not be repeated (replay protection).  It might also be helpful to include of a discussion as to when it is more advantageous to use link encryption or group keys. In the case that a network consists of both highly security-relevant and well-protected devices (such as alarm systems), and non-security relevant and not so well-protected devices (such as TV remotes), group keying means that either the remote must be as well-protected as the alarm system, or the entire network must be rekeyed if the remote is lost.  I don’t whether or not it would be necessary to give any MUST or SHOULD recommendations, but it would be helpful to give the reader an understanding of the issues involved when making decisions about link encryption versus group keys.  As far as I can see this subject is not addressed in any of the documents cited at the beginning of the security considerations. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email:  catherine.meadows at nrl.navy.mil