Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lwig-crypto-sensors-05.txt Reviewer: Emmanuel Baccelli Review Date: 20/02/2018 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The draft's content are solid and relevant, the readability is good. I have a few suggestions on how to further improve readability. Major Issues: No major issues found. Minor Issues: In section 8.3, concerning network layer security, it would be more complete to also mention specific routing security aspects, e.g. cases where multi-hop is needed in a LoWPAN, and mechanisms (such as topology authentication) should be used to mitigate sinkhole attacks etc. In the end summary, maybe it would also make sense to add something like: "If push comes to shove, strong security is also possible on 8-bit and 16-bit". I think it is important to send the message that even some "legacy" IoT hardware could be made secure. Nits: # Section 3: the "network configuration" bullet point is somewhat unclear, hinting at different issues. Would it not make sense to split it in 2 different bullet points? # Section 4.1: it would be clearer if the main principles used for provisionning are gathered and stated upfront in this section. I mean a short list like "only identities are provisionned", "identities are self-securing". # Section 4.1 in the part on group identity: at first sight it is not straightforward what is n and what is m, and why they might be differ. Some explicit mention would be useful. # Section 4.1 in the part on group identity: does the model require each device to be provided with the identities of all the other devices in the group at commissionning time? It is unclear in the text, an explicit mention would be useful here too. # Section 5: it is somewhat awkward to find an OS within a list of crypto libraries. However, I agree it is important to point to available operating systems in this space. I suggest a separate paragraph on operating systems and citing a survey such as: O. Hahm et al. "Operating Systems for Low-end Devices in the Internet of Things: a Survey." IEEE Internet of Things Journal 3.5 (2016): 720-734. As a side note, it would be great to have an equivalent survey to point to for available light-weight crypto libraries... # Section 6: in the beginning of the section, it is not clear that the measurements are on Arduino Uno (right?). I suggest stating this explicitly. # Section 6: "The Arduino board only provides ... the random() function call." I think this sentence is somewhat misleading. The main point here is what there is (or what there isn't) behind this function call. I suggest rephrasing the bullet point with something like: "some boards (e.g. Arduino Uno) do not provide a hardware random number generator. On such boards, obtaining crypto-quality randomness is an issue." # Spotted typos: in Section 6 "results for for all the 128" in Section 7 "enough power to be stay on"