Re: [Suit] On device resets during manifest processing

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 July 2022 15:09 UTC

Return-Path: <mcr+ietf@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 4069AC15A731 for <suit@ietfa.amsl.com>; Thu, 7 Jul 2022 08:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.706
X-Spam-Level:
X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_Fdzhe0eb61 for <suit@ietfa.amsl.com>; Thu, 7 Jul 2022 08:09:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1728EC15A733 for <suit@ietf.org>; Thu, 7 Jul 2022 08:09:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 20F6738B13; Thu, 7 Jul 2022 11:26:51 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dbXotNGnHVNW; Thu, 7 Jul 2022 11:26:50 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6BCC8389F5; Thu, 7 Jul 2022 11:26:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1657207610; bh=wPWULE57m79fHzYB/yehLlIIxlSPoeFDW5TIeUiZw/s=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=gFnl38RfKiUB8ObR2tPp5tfmlSGDw7wozo2uTTL5wBV+zJImxNEUS5XBFjrTisECZ AIfJM/9zQn2sDSFf75QAQ7DzEd8EuTI/l2JhJbY9JXDtxMR5RDi/5YRFvlAnlHHQNf IBlLQZ3EtNSg9jfNZDkzYd4EwN9AuiBjutxWD5uZ/FKVMJxD7kub1spzwyGLjc1XVW n9o8OcXQxgIeXI+bFpA1sME3Otw0oSIQA7Yv7/Bj6xF2taSBVxUfMmydaVUfg4HbHb 9ekgiz4Ng3ROkqWeVgMIByGUVYmg5Dm5g00uQLm+CJ6HfgsUw3oLpkhdnfWOe3Z7zb laXhbTtQ5E+Xg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B5D70558; Thu, 7 Jul 2022 11:09:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind ?= <Oyvind.Ronningstad=40nordicsemi.no@dmarc.ietf.org>
cc: Brendan Moran <Brendan.Moran@arm.com>, "suit@ietf.org" <suit@ietf.org>
In-Reply-To: <AM9PR05MB766849CF85C47B8C6B1A26C688839@AM9PR05MB7668.eurprd05.prod.outlook.com>
References: <AM9PR05MB766851037AC1FA6D542713A588809@AM9PR05MB7668.eurprd05.prod.outlook.com> <AM9PR05MB766827642091BA812BAC891188809@AM9PR05MB7668.eurprd05.prod.outlook.com> <1EBCBBDE-3CED-476B-BE26-3A6D096A69BF@arm.com> <0B50DD7D-9AEA-42D2-9EAD-B63DEBF6920F@arm.com> <AM9PR05MB766849CF85C47B8C6B1A26C688839@AM9PR05MB7668.eurprd05.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 07 Jul 2022 11:09:43 -0400
Message-ID: <32298.1657206583@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Cp-HcB2JNJt342KwfM5drnK_X68>
Subject: Re: [Suit] On device resets during manifest processing
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 07 Jul 2022 15:09:58 -0000

Rønningstad, Øyvind wrote:
    > 1.  "try again" could be expanded upon a bit, which actions are to be
    > tried again?

I don't think that it can/should be further specified in a way that won't be
specific to a particular implemention.  Maybe
    so that a a distrupted system is sufficiently intact to be able to
    apply the SUIT Manifest again.


> "Fallback/recovery image" is not defined in the document
> (AFAICT).

I believe that this is sufficiently system specific that we can't really
define it, and it's generall a well known industry term.

    > 2.  Maybe specify that this applies to both update and boot
    > sequences. Also "repeated invocation" could be something like
    > "(possibly incomplete) repeated invocation".

Idempotent is the key word here.

My belief is that recovery from failed updates is the most important
problem.  All other problems can be solved if you can recover if there is no
foot canon.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide