Reviewer: Theresa Enghardt Review result: Almost Ready 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-suit-architecture-11 Reviewer: Theresa Enghardt Review Date: 2020-08-09 IETF LC End Date: 2020-08-14 IESG Telechat date: Not scheduled for a telechat Summary: Thank you for this work. This document is clear in the problem that it addresses and in specifying its approach. I just have a few minor clarification questions. Major issues: None. Minor issues: Section 1 I find the following paragraph a bit confusing: "While the standardization work has been informed by and optimised for firmware update use cases of Class 1 devices (according to the device class definitions in RFC 7228 [RFC7228]), there is nothing in the architecture that restricts its use to only these constrained IoT devices. Software update and delivery of arbitrary data, such as configuration information and keys, can equally be managed by manifests." The paragraph is about generalizing the work presented in this draft, but the first sentence suggests that it's about generalizing it to more devices, and the second sentence talks about different use cases, but indirectly: At this point, the reader does not yet know that this work is based on manifests, as this is the first occurence of the word "manifest" in the text. Therefore, it is not clear that "can be equally managed by manifests" refers to applying the architecture presented in this draft to other use cases. I suggest to change the second sentence to something like: "Moreover, this architecture is not limited to managing software updates, but can also be applied to managing the delivery of arbitrary data, such as configuration information and keys." Section 2 Status Tracker: Why does the IoT device itself "most likely not run a status tracker itself", even as the draft defines client-initiated updates? This sentence seems unnecessarily restrictive to me. This section introduces Trusted Execution Environments (TEEs) and points to draft-ietf-teep-architecture, but is not explicit about the relationship between SUIT and TEEP. I think it's worth adding one or two sentences explaining this relationship, i.e., does SUIT require TEEP, does TEEP require SUIT, do both complement each other but can be implemented independently, ...? Section 3.5. High reliability Here maybe it's worth adding another case to protect against, i.e., if the download is interrupted due to loss of network connectivity or if there's packet loss. It's not obvious to me where this case is included, as the "broadcast-friendly" requirement implies that these devices are not necessarily running TCP or another protocol that provides reliable in-order data delivery. Section 3.7. Small Parsers I think it's worth adding that this is about the parser of the manifest (if this is in fact the case), as this is not obvious from the context. Section 3.10. Operating modes This section presents steps a devices has to go through in the course of an update, while section 5 and section 9 also talk about different steps, and section 8 has additional steps, e.g., the bootloader has to check the integrity of a firmware image again before booting it. I think it's worth adding at least some cross-references, e.g., in Section 3.10, highlight that this is not an exhaustive list of steps, and that Section 9 has a more complete example including the the necessary checks. Section 4. Claims Why is this its own section? Isn't this just another term for Section 2, and/or just just another requirement for Section 3? Section 8. Bootloader I do not understand the following paragraph: "If the application image contains the firmware consumer functionality, as described above, then it is necessary that a working image is left on the device. This allows the bootloader to roll back to a working firmware image to execute a firmware download if the bootloader itself does not have enough functionality to fetch a firmware image plus manifest from a firmware server over the Internet." What is an application image? Is it different from a firmware image? And why does the firmware download have to be carried out from the bootloader here (with rollback to a previous image)? Hasn't the firmware already been downloaded at this point? There's probably some condition under which this needs to be done - please add it to the text. Nits/editorial comments: Section 7.4. Dual CPU, other bus "It is likely that one of the CPUs will be considered a master" s/master/primary/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
