This is an early review of draft-ietf-lwig-crypto-sensors-04 on behalf of the Security Directorate. The document is almost ready, but would benefit from a bit more further work. This draft examines a series of risks and challenges posed by securing small devices, proposes solutions for provisioning, and an architecture for securing the devices. The implementation experience section (section 8) provides measurements for the memory and CPU costs of various cryptographic operations using the Arduino platform. It will be good to see these results published and become a useful reference in further debates. In fact, I like this document a lot. My only concern is that it misses an opportunity to discuss identifiers and privacy. I like the discussion of platform constraints in section 3, and the statement that "at the end of the day, if strong cryptographic security is needed, the implementations have to support that." I think it is an important message, and it it might be good to reinfore it with examples. For example, we do ship medecine in child-proof containers. It would be cheaper to use ordinary containers, but we pay the cost because as a society we want to mitigate the risk of children mistaking pills for candy. Similarly, it is cheaper to build devices with no security, but we may want society to mandate that risks should be mitigated. The challenge section, and the document in general, would be even better if it included a discussion of identifiers and privacy. The general concern is that because small devices have limited resource, they end up using just one identity, maybe just one public key. This makes them easy to track when they move, and by extension track the movements of their owners for wearable devices, or associated objects such as cars for general devices. There are certainly mitigations, such as provisioning new identities at appropriate times, or using temporary identities in communication protocols, but these mitigations certainly require the kind of trade-offs discussed in the draft. It would thus be very nice to introduce the privacy challenges in the "challenge" section, and to discuss the privacy mitigations in the other sections, e.g., architecture and provisioning.