Re: [Suit] Call for adoption on manifest draft

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 19 June 2019 00:25 UTC

Return-Path: <mcr@sandelman.ca>
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 0A7F31200D5 for <suit@ietfa.amsl.com>; Tue, 18 Jun 2019 17:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level:
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, 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 WRLgl-_b1iyY for <suit@ietfa.amsl.com>; Tue, 18 Jun 2019 17:25:57 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDAE1200B5 for <suit@ietf.org>; Tue, 18 Jun 2019 17:25:56 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 307731F450 for <suit@ietf.org>; Wed, 19 Jun 2019 00:25:54 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 727D81328; Tue, 18 Jun 2019 20:26:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: "suit\@ietf.org" <suit@ietf.org>
In-reply-to: <30900.1560890785@dooku.sandelman.ca>
References: <SN6PR09MB32643D17285ACEEED3D23FC4F0EB0@SN6PR09MB3264.namprd09.prod.outlook.com> <12354.1560790046@dooku.sandelman.ca> <9314229C-01E8-4CCC-8EFD-4F5715072C30@arm.com> <30900.1560890785@dooku.sandelman.ca>
Comments: In-reply-to Michael Richardson <mcr+ietf@sandelman.ca> message dated "Tue, 18 Jun 2019 16:46:25 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 18 Jun 2019 20:26:03 -0400
Message-ID: <12665.1560903963@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/GTuCFDlGquIdr5iwpRRB3o-qihg>
Subject: Re: [Suit] Call for adoption on manifest draft
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: Wed, 19 Jun 2019 00:25:59 -0000

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > Are the problems we are trying to solve so complex, varied and unknown
    > that we need this?

The most complicated situation that I see is one where there are multiple
firmwares images and they need to be upgraded in a particular order, or
things stop working.  The Android case of KERNEL image vs RADIO/BASEBAND
image is perhaps the simplest example of this.  (On some phones, you'll
not just lose LTE if they are mis-matched, but maybe WIFI too, and often
you'll get a kernel panic.)

{At this point, I wandered through the document and then into the
architecture document looking for the terminology for where a firmware image
goes into.  The best I came up was that it was a component.  Above, in my
android case, there were RADIO and KERNEL as slots for firmware}

I can readily imagine Industrial applications where it could even take
multiple passes:
    1) upgrade component A to version 1.99 (which tolerates B being at 2.00)
    2) upgrade component B to version 2.00
    3) upgrade component A to version 2.00

It should, I think be possible to express this process in a single master
manifest (with dependancies, I think) rather than staging it somehow via an operator
action.  It might be that each step takes mulitple hours to days to transfer
the image, and the device needs to be operational the rest of the time
(double-buffering).

I think that the current document can accomplish the above rather simply, but
it seems to go a lot further.  (To infinity... and beyond!... so good work!)

I think that the directives tries to assume some kind of universal firmware
updating system that is identical everywhere, rather than assuming a
universal firmware package format, with firmware updaters in specific to each
device.  Perhaps this comes from being a SoC vendor that is trying to support
customers with a large variability in uses, but wanting to provide them all
with an identical baked-in-internal-flash firmware system.

I would be interested in David Brown's view on this.

ps: I think it's only the directives which are the problem. I think the
SUIT_Conditions are perfect, btw.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-