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 >
- [Suit] Question about SUIT WG deliverable Basavaraj Patil
- Re: [Suit] Question about SUIT WG deliverable Henk Birkholz
- Re: [Suit] Question about SUIT WG deliverable Basavaraj Patil