Skip to main content

Last Call Review of draft-ietf-suit-architecture-11

Request Review of draft-ietf-suit-architecture
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-08-14
Requested 2020-07-24
Authors Brendan Moran , Hannes Tschofenig , David Brown , Milosch Meriac
Draft last updated 2020-08-09
Completed reviews Tsvart Last Call review of -11 by Bob Briscoe (diff)
Genart Last Call review of -11 by Reese Enghardt (diff)
Secdir Last Call review of -11 by Rich Salz (diff)
Iotdir Telechat review of -13 by Mohit Sethi (diff)
Assignment Reviewer Reese Enghardt
State Completed
Review review-ietf-suit-architecture-11-genart-lc-enghardt-2020-08-09
Posted at
Reviewed revision 11 (document currently at 16)
Result Almost Ready
Completed 2020-08-09
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


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


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

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

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

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"