Re: [Suit] Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Fri, 20 November 2020 06:57 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4233A1971; Thu, 19 Nov 2020 22:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyiQCGPVTy8U; Thu, 19 Nov 2020 22:57:39 -0800 (PST)
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97153A196D; Thu, 19 Nov 2020 22:57:38 -0800 (PST)
Received: by mail-vs1-f50.google.com with SMTP id h185so4498031vsc.3; Thu, 19 Nov 2020 22:57:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WHlg1VFPvlCtN+ZrQM8SHTkoFWkYe3kn966Ydmgl3d8=; b=j+4oP+r3MK+CMpiQ30MINa7KjzfKsAIQKASXiavzIvSQrYSkSlGBAXnZi0/bW10K7m UpZzNUiWplWGBbIIXTq7KH5U59Vubnau6WRyoL4iJbN5Vj/ni1lxQOLk0wWNoN61z4H6 R75LC5av2Ii5s4StZEXLsDVrBnf2SY5+Odt77rFUf9ZJ1ea4Tczl+bufuJgYA9MOLQ61 7xPtYoRlYwykZ5BgM/SWXrF7uP/tHasSP253jT8w83Ae1HuRwa6qsWTGbbnvu0fCfi4r RUYqOzXxjMnln4k8vHdWNOzF2Mcsfefc3OJqq2lTn1D4wLGMKZuXJHkerboijdnAhCqy Gswg==
X-Gm-Message-State: AOAM532oZckWddLNykthXd1XTq4gKhdx+NtoehkKhZgODwnvHfKo1mzC l0fDxcsZzTb22yHd/xS+MEvu5OWhf3yvG9HUI7w=
X-Google-Smtp-Source: ABdhPJw1S+c5NxTm5dmOfIUJLwfF3Cy7KZ2Y0LgzuXqt/Or+7YHKKOqs5V1bNIfArlJ3OtyN8RsNmnF6jmx2nr/P148=
X-Received: by 2002:a67:f05:: with SMTP id 5mr11017804vsp.39.1605855457667; Thu, 19 Nov 2020 22:57:37 -0800 (PST)
MIME-Version: 1.0
References: <160425219933.2164.12165140117377106860@ietfa.amsl.com> <AM0PR08MB3716F062435F30ED93F2D574FAFF0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB3716F062435F30ED93F2D574FAFF0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 20 Nov 2020 01:57:25 -0500
Message-ID: <CALaySJK-JcoUY9VrXgg8LxH6JuKNmz5yYSM06v+iSSk_Jycyew@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-suit-architecture@ietf.org" <draft-ietf-suit-architecture@ietf.org>, "suit-chairs@ietf.org" <suit-chairs@ietf.org>, "suit@ietf.org" <suit@ietf.org>, Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/CmHiRoeyhXntT1Di1K0yIH3WPes>
Subject: Re: [Suit] Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 06:57:41 -0000

Thanks, Hannes!

Barry

On Fri, Nov 20, 2020 at 1:13 AM Hannes Tschofenig
<Hannes.Tschofenig@arm.com> wrote:
>
> Hi Barry,
>
> Thanks for your review. I have incorporated the suggested changes in this PR: https://github.com/suit-wg/architecture/pull/18
>
> Ciao
> Hannes
>
>
> -----Original Message-----
> From: Barry Leiba via Datatracker <noreply@ietf.org>
> Sent: Sunday, November 1, 2020 6:37 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-suit-architecture@ietf.org; suit-chairs@ietf.org; suit@ietf.org; Russ Housley <housley@vigilsec.com>; housley@vigilsec.com
> Subject: Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT)
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-suit-architecture-14: No Objection
>
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Nice work on this; thanks.  I have a bunch of comments, but all minor.
>
> — Section 1 —
>
>    Firmware updates can help to fix security vulnerabilities and are
>    considered to be an important building block in securing IoT devices.
>
> Nit: “firmware updates” is plural, and “building block” is singular.  I think it’s actually *doing* the updates that’s the building block, not he updates themselves.  And you can just make the statement, without “are considered”.
> How do you like this version?:
>
> NEW
>    Firmware updates can help to fix security vulnerabilities, and
>    performing updates is an important building block in securing
>    IoT devices.
> END
>
>    Due to rising concerns about insecure IoT devices the Internet
>    Architecture Board (IAB) organized a 'Workshop on Internet of Things
>    (IoT) Software Update (IOTSU)', which took place at Trinity College
>    Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at
>    the bigger picture.  A report about this workshop can be found at
>    [RFC8240].  The workshop revealed a number of challenges for
>    developers and led to the formation of the IETF Software Updates for
>    Internet of Things (SUIT) working group.
>
> The details of when and where the workshop happened isn’t important here, and it’s rigt up front in 8240 anyway.  I suggest trimming that, because the important part is pointing people to the worshop report and saying what’s in the next sentence about the formation of the SUIT WG.
>
> NEW
>    Due to rising concerns about insecure IoT devices the Internet
>    Architecture Board (IAB) organized a 'Workshop on Internet of Things
>    (IoT) Software Update (IOTSU)' [RFC8240] to take a look at
>    the bigger picture.  The workshop revealed a number of challenges for
>    developers and led to the formation of the IETF Software Updates for
>    Internet of Things (SUIT) working group.
> END
>
>    Firmware updates are not only done to fix bugs, but they can also add
>    new functionality, and re-configure
>
> Grammar nit: “Firmware updates are done not only to fix bugs, but also to add new functionality and to reconfigure”
>
>    Unlike higher end devices, like laptops and desktop PCs, many
>    IoT devices do not have user interfaces and support for unattended
>    updates is, therefore, essential for the design of a practical
>
> My first reading of this was that “many IoT devices do not have user interfaces and support for unattended updates.”  I had to read it again to correctly interpret the sentence.  If you replace “interfaces and” with “interfaces;” it fixes that problem easily.
>
>    using pre-configured hostnames or [RFC6763] DNS-SD.
>
> The citation should go after “DNS-SD”.
>
> — Section 2.1 —
>
>    -  Firmware Image: The firmware image, or image, is a binary
>
> The “or image” seems odd there.  Maybe like this?:
>
> NEW
>    -  Firmware Image: The firmware image, or simply the “image”,
>        is a binary
> END
>
> — Section 2.3 —
>
>       The deployment of status trackers is flexible and may
>       be found at
>       cloud-based servers, on-premise servers, or may be embedded in
>       edge computing devices.
>
> (Odd line-break here...)
> Nit: the list is not parallel, and the intro doesnt read right.  Try this?:
>
> NEW
>       The deployment of status trackers is flexible: they may
>       be found at cloud-based servers or on-premise servers,
>       or they may be embedded in edge computing devices.
> END
>
> — Section 3 —
>
>    images to the firmware server and to initiate an update him- or
>    herself.
>
> Nit: I suggest avoiding the awkwardness by saying “and to initiate an update directly.”
>
>    As a first step in the firmware update process, the status tracker
>    client needs to be made aware of the availability of a new firmware
>    update by the status tracker server.
>
> Nit: passive voice makes this more awkward than it needs to be, especially as you have a clear subject already (the server).  Why not make it active?:
>
> NEW
>    As a first step in the firmware update process, the status tracker
>    server needs to inform the status tracker client that a new firmware
>    update is available.
> END
>
>    -  Using a hybrid approach the server-side of the status tracker
>       pushes notifications of availability of an update to the client
>       side and requests the firmware consumer to pull the manifest and
>       the firmware image from the firmware server.
>
> As written, this is exactly the same as the server-initiated scenario.  In both cases, the server tells the client that an update is available, and the firmware consumer fetches the manifest and image.  What is the difference meant to be?  Do one or both of the descriptions need to be tweaked?  (I’m guessing that the server-initiated description should be changed to say that the server pushes the manifest and image, rather than waiting for the client to fetch it... yes?)
>
>    If the firmware consumer has downloaded a new firmware image and is
>    ready to install it, to initiate the installation, it may - either
>    need to wait for a trigger from the status tracker, - or trigger the
>    update automatically, - or go through a more complex decision making
>    process to determine the appropriate timing for an update.
>
> Are those dashes meant to be bullets in a list, and so is this a formatting glitch?
>
>    Devices
>    must not fail when a disruption occurs during the update process.
>    For example, a power failure or network disruption during the update
>    process must not cause the device to fail.
>
> Nit: why not merge these two sentences?:
>
> NEW
>    Devices
>    must not fail when a disruption, such as a power failure or network
>    interruption, occurs during the update process.
> END
>
> — Section 4.1 —
>
>    -  The bootloader needs to fetch the manifest (or manifest-alike
>       headers) from nonvolatile storage
>
> What are “manifest-alike headers”?
>
>       This allows to share
>       information about the current firmware version
>
> “Allows to share” doesn’t work in English: you need a subject, “allows <subject> to share <object>”.  If you don’t have a subject, you can say “allows the sharing of information...”.
>
> — Section 6 —
>
>    A manifest may not only be used to protect firmware images but also
>    configuration data such as network credentials
>
> Similar to a comment above, this has “not only” misplaced:
>
> NEW
>    A manifest may be used to protect not only firmware images but also
>    configuration data such as network credentials END
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.