Dan, thanks for your review. I entered a No Objection ballot and look forward to responses from the authors/shepherd.
Alissa > On Feb 13, 2018, at 2:44 AM, Dan Romascanu <[email protected]> wrote: > > Reviewer: Dan Romascanu > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lwig-crypto-sensors-05 > Reviewer: Dan Romascanu > Review Date: 2018-02-13 > IETF LC End Date: 2018-02-19 > IESG Telechat date: 2018-02-22 > > Summary: > > This is a well-written clear informational memo, documenting methods to secure > networks built of resource-constrained devices. It describes a deployment > model > based on exchanges of signed objects, and documents available cryptographic > libraries that may be suited to the targets. The conclusions include analysis > of trade-offs and recommendations for future development and deployments. > > The document is READY from Gen-ART perspective. There are a couple of > non-blocking issues that I would be glad to have them clarified before > approval. I have also pointed to a couple of nits. > > Major issues: > > Minor issues: > > 1. In Section 7: > > 'The location of the resource directory was configured into > the smart object sensor by hardcoding the IP address' > > Is this reasonable? I understand that the goal of the exercise was to > demonstrate that it is possible to implement the entire architecture with > public-key cryptography on an 8-bit micro-controller, but hard-coding the IP > address seems to be below the threshold of a functional system. IMO there is a > need to be able for the sensor to acquire this address (DHCP stack, or a > simple > UI to stream in one address, etc.) > > 2. In section 8.1 - I would expect some discussion about the extra-power > needed > to run the cryptography. There is a statement about these being less than > device wake-up and sending messages, but some quantitative evaluation (in > percentage) of the impact would be useful, taking into account that battery > capacity is one of the most important constrained resources. > > Nits/editorial comments: > > 1. The document uses the alternate term of 'small devices' for > 'resource-constraint devices'. I view this as kind of an inaccurate verbal > automatism in the world of IoT, as 'small' is a relative term, > resource-constrained devices are not necessarily small (like in reduced > physical footprint), and small devices can be rich in resources. I would > suggest to either avoid the term, or explain what it means in the context > (e.g. > ''Smart objects', 'small devices' and 'resource-constrained devices are used > interchangeably in this document and mean ...') > > 2. Please expand ECDSA at first occurrence > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
