Re: [Suit] Question about SUIT WG deliverable

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Thu, 07 June 2018 18:32 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 9B991131176 for <suit@ietfa.amsl.com>; Thu, 7 Jun 2018 11:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bz3n-HsKjrAD for <suit@ietfa.amsl.com>; Thu, 7 Jun 2018 11:32:37 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A063A130FC1 for <suit@ietf.org>; Thu, 7 Jun 2018 11:32:36 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w57IWWo3030325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <suit@ietf.org>; Thu, 7 Jun 2018 20:32:33 +0200
Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 7 Jun 2018 20:32:27 +0200
To: suit@ietf.org
References: <CAA5F1T00mMZB6NQ55F33HcqxwHptB10K4_0M1ptR1UoTuUXWpA@mail.gmail.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <e62af098-4e72-3544-e9af-af693161fadd@sit.fraunhofer.de>
Date: Thu, 07 Jun 2018 20:28:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAA5F1T00mMZB6NQ55F33HcqxwHptB10K4_0M1ptR1UoTuUXWpA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.43.163]
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/XTd89LUJrMh5uX-5Uz1k5THTOro>
Subject: Re: [Suit] Question about SUIT WG deliverable
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.26
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 Jun 2018 18:32:54 -0000

Hello Basavaraj,

to establish a basis, I will quote the 2nd last paragraph of the charter.

> This group does not aim to create a standard for a generic application software
> update mechanism, but instead this group will focus on firmware development
> practices in the embedded industry. Software update solutions that target
> updating software other than the firmware binaries (e.g., applications) are
> also out of scope.

This might seem to imply that conveyance seems to be mostly out of 
scope. The interaction model in the architecture seems most certainly to 
indicate otherwise.

And I think there is a very good reason for this. The content of the 
manifest depends on its applications. If it is declarative guidance to 
be consumed by the target only, it can be minimal and very specific. If 
it is created in work-flows and distributed by entities that discover, 
validate, trust, pull/poll (or some hybrid of it) it in a way that is is 
a container for the actual firmware, it might require different 
conveyance procedures (and manifest content) than if it would "just" be 
pointing to the correct firmware (e.g. via URI) and acts as a type of 
imperative guidance to where to discover which payload that fits your 
"to-be-updated" thing appropriately at a given time.

In a nutshell, SUIT might not mandate or even create specific protocols 
to achieve successful update campaigns. But depending on the application 
of the manifest, there might be multiple work-flows / interaction models 
and trust relationships defined by the SUIT WG in order to get that done 
reliably and trustworthy.

This is an answer of a single individual. Dear WG, please comment about 
anything that might be wrong about what I just wrote :)

Viele Grüße.

Henk



On 06/07/2018 07:44 PM, Basavaraj Patil wrote:
> 
> Sec 7 of I-D: draft-ietf-suit-architecture-00 shows an example flow 
> depicting the end-2-end process of firmware updates of an IoT device.
> 
> Will the SUIT WG develop the protocol/signaling that is depicted in Fig 
> 4 of the I-D?
> 
> -- 
> Basavaraj Patil
> 
> 
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit
>