[Gen-art] Genart last call review of draft-ietf-suit-architecture-11

Theresa Enghardt via Datatracker <noreply@ietf.org> Sun, 09 August 2020 17:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E90433A07AB; Sun, 9 Aug 2020 10:49:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Theresa Enghardt via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: suit@ietf.org, draft-ietf-suit-architecture.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159699537789.3865.13936841170357877070@ietfa.amsl.com>
Reply-To: Theresa Enghardt <ietf@tenghardt.net>
Date: Sun, 09 Aug 2020 10:49:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/uhhRHnR1QnSEJkV796Kj0MiBlMo>
Subject: [Gen-art] Genart last call review of draft-ietf-suit-architecture-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 17:49:38 -0000

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


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"