Re: [Suit] SUIT Architecture -- Operating modes
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 06 June 2018 17:52 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 94B43130F85 for <suit@ietfa.amsl.com>; Wed, 6 Jun 2018 10:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 n228FMUylZ-0 for <suit@ietfa.amsl.com>; Wed, 6 Jun 2018 10:52:33 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C35130F89 for <suit@ietf.org>; Wed, 6 Jun 2018 10:52:32 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68AE320090 for <suit@ietf.org>; Wed, 6 Jun 2018 14:05:59 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id CF2BD74; Wed, 6 Jun 2018 13:51:56 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CCB7B3F for <suit@ietf.org>; Wed, 6 Jun 2018 13:51:56 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: suit@ietf.org
In-Reply-To: <CANK0pbZgLnYRJ3Hhu8tgEpL2K4192GeXH0ivPsc+7dykR7_FCQ@mail.gmail.com>
References: <VI1PR0801MB211259B72731F37766C0227CFA650@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CY4PR21MB07746C16253D71D61702C90DA3650@CY4PR21MB0774.namprd21.prod.outlook.com> <CANK0pbZgLnYRJ3Hhu8tgEpL2K4192GeXH0ivPsc+7dykR7_FCQ@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha1"; protocol="application/pgp-signature"
Date: Wed, 06 Jun 2018 13:51:56 -0400
Message-ID: <25609.1528307516@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/zGHrNU8ark0T5A5i8-232k_o1QE>
Subject: Re: [Suit] SUIT Architecture -- Operating modes
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: Wed, 06 Jun 2018 17:52:38 -0000
Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> wrote:
>> The notification of an update can be device initiated (pull) or remotely
>> initiated (push).
>> The transfer of the actual image can also be device initiated (pull) or
>> remotely initiated (push).
>> The three cases are (I think the other combination doesn't make sense):
>> 1) Push notification, push image
>> 2) Push notification, pull image
>> 3) Pull notification, pull image
> In my opinion, this is also potentially clearer.
> One comment though: does case 1 really make sense?
> If the image is pushed anyways, there is arguably no need for prior
> notification.
If the push notification allows the device to respond with, "thanks, but no thanks, I'm
already there", or "thanks, but it does not apply to me", then it makes sense.
> Or are we implicitly mixing "notification" with "pre-authorization" aspects?
tell me more about pre-authorization...
I didn't understand why there was a "pre-" part.
In my example above, I think it fell into notification.
>> The notification step consists informing an IoT device that an update
>> is available. This can be accomplished via polling (self-initiated),
>> push notifications (third-party initiated), or more complex
>> mechanisms.
>>
>> The pre-authorisation step involves verifying the update authority
>> and making a determination that the device is prepared to initiate
>> the fetching and processing of updates. If the device has all
>> information that is necessary to make this determination, then the
>> pre-authorisation may be self-initiated. However, the device can
>> wait for instruction to begin (third-party initiated). Hybrid
>> approaches are possible as well.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
- [Suit] SUIT Architecture -- Operating modes Hannes Tschofenig
- Re: [Suit] SUIT Architecture -- Operating modes Dave Thaler
- Re: [Suit] SUIT Architecture -- Operating modes Emmanuel Baccelli
- Re: [Suit] SUIT Architecture -- Operating modes Michael Richardson
- Re: [Suit] SUIT Architecture -- Operating modes Hannes Tschofenig
- Re: [Suit] SUIT Architecture -- Operating modes Dave Thaler
- Re: [Suit] SUIT Architecture -- Operating modes Matthias Waehlisch