[Iot-directorate] Iotdir telechat review of draft-ietf-suit-architecture-13

Mohit Sethi via Datatracker <noreply@ietf.org> Tue, 20 October 2020 19:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB23A14EF; Tue, 20 Oct 2020 12:00:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mohit Sethi via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-ietf-suit-architecture.all@ietf.org, suit@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160322042890.10508.3396812732418590187@ietfa.amsl.com>
Reply-To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Date: Tue, 20 Oct 2020 12:00:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/RnpCfZrvzPneN-99GJcwaMyuDO4>
Subject: [Iot-directorate] Iotdir telechat review of draft-ietf-suit-architecture-13
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 19:00:32 -0000

Reviewer: Mohit Sethi
Review result: Ready with Nits

Thanks for the well written document.

I wonder if you want to state the difference between software and firmware
update. Are they the same thing for this document? The text in the draft at
some point says "Moreover, this architecture is not limited to managing
software updates". But most of the other text talks about "firmware updates".

Abstract: "Vulnerabilities with Internet of Things (IoT) devices" ->
"Vulnerabilities in Internet of Things (IoT) devices"

How about rephrasing the text: "are expected to work automatically, i.e.
without user involvement. Automatic updates that do not require human
intervention are key to a scalable solution for fixing software
vulnerabilities." to "are o a large extent expected to work automatically, i.e.
with minimal human interaction. Automatic updates that require minimal or no
interaction are key to a ....". The reason for requesting this change is
simple: in many scenarios you would want user approval before the actual
update. For example, updating lights at night during dinner is perhaps not
ideal. The draft does discuss the importance of device operator approval in
some circumstances so updating the text would make sense.

"programming language uses and the sandbox the software is executed in."->
"programming language used...".

"Ensuring an energy efficient design of a battery-powered IoT devices because a
firmware update -> "...of a battery-powered IoT device because..."

I think most readers will be more familiar with the term Original Equipment
Manufacture (OEM) rather than Original Design Manufacturer (ODM). I understand
that ARM has a slightly complicated ecosystem and business model. So perhaps
the text could say "in some cases, the OEM or the ODM act as a TPA and may
decide to remain in full control...."

"edge computing device" -> "edge computing devices"

"Updating updates over the Internet" -> "Sending updates over the Internet"
sounds a bit better

"the status tracker client need to be made aware of the availability of a" ->
"...the status tracker client needs to be informed about the availability of
a....."

"what devices qualify for a firmware update" -> "which devices qualify for a
firmware update"

"are only two approaches recovering from an invalid firmware" -> " are only two
approaches for recovering from an invalid firmware"

I am not familiar with non-relocatable code. I think this is somewhat explained
later on as "execute in place" but perhaps adding a few sentences here
explaining non-relocatable code wouldn't hurt.

Perhaps replace "keyed message digests" with more standard "HMAC" and add a
reference to RFC 2104

stray closing parenthesis -> "protection was applied)"

"Hence, then the firmware image is updated" -> "Hence, when the firmware image
is updated"

Not sure how to interpret "mutually-distrustful delivery". I guess I understand
that the firmware author and user both want to prevent revealing some
information to the other party. But can we not use "mutually-distrustful
delivery"?

The draft uses TAs for trusted applications (TAs). But RFC 6024 referenced by
this document uses TAs for Trust anchors. Can we avoid using TA abbreviations
for trusted applications for ?