Re: [Gen-art] Genart last call review of draft-ietf-lwig-crypto-sensors-05

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 <dromasca@gmail.com> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art