Reviewer: Tim Chown Review result: Ready Hi, This Informational draft describes the challenges in securing resource-constrained smart object / IoT devices, documenting the associated tradeoffs, and discussing the availability of appropriate cryptographic libraries for such devices. I have reviewed this document, and overall find it generally ready for publication, though I have some minor nits / comments for consideration below; these are just suggested changes / improvements, and I would not object strongly if all were ignored. General comments: The document is very easy and enjoyable to read, and the quality of the writing is very good. The authors have clear expertise in the field. It may be worth considering teasing apart the evaluation and the architectural aspects of the document; these are somewhat interwoven as currently written. Related, there are some rather nice recommendations made throughout the document; these could perhaps be summarised either at the start or perhaps better the close of the document, e.g. on page 4 regarding selecting the hardware after determining the security requirements for a device, and not necessarily simply picking the most lightweight algorithm, or on page 7 regarding appropriate layers for tasks, or on page 9 regarding elliptic curve vs RSA, or on page 11 on real deployments using 32-bit microcontrollers, or the recommendation to the IETF community on page 14, or on planning for firmware updates on page 16, etc. Comments by page: On page 5, in the first paragraph on provisioning, there is no hint of any bootstrap process for identities; this follows later on page 6, but a hint here, or just adding "as discussed on page 6 or in section x.y" might be nice. Also on page 5, I'd be interested in seeing some brief text added on the "remaining vulnerabilities" that are mentioned near the foot of the page. On page 6, is it worth adding a little text on privacy somewhere? We've been doing some work through Christian Huitema and Daniel Kaiser on anonymous device pairing in the DNSSD WG, and a similar requirement might be desirable in some scenarios here? On page 7, having said earlier you should pick the hardware after determining requirements, you then decide to pick an Arduino platform and see what you can manage to run on it. I fully understand why (and I'd be equally curious), but you should probably clarify the "conflict" further. On page 12, would a little more detail on RNG requirements, esp. for devices of this type, be worthwhile? On page 16, you're hardcoding the IP address? Is it not possible to use RD? We've been comparing that and looking at interoperability with classic DNSSD in the DNSSD WG. On page 16, section 10 seems to have no content? Or should sections 11 onwards be subsections of section 10? On page 17, at the end of section 11, should there also be some 'spin up' costs for the radio? Best wishes, Tim