Subject: [Suit] SUIT Architecture -- Operating modes

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jun 2018 09:27:28 +0000

Hi all,

at the virtual interim meeting earlier this year Dave suggested terminology, which was based on
ITU-T work for firmware updates:

- Device Core: stores/uses software/firmware,
i.e., the IoT device itself

- Communicator: checks software/firmware
status of device and initiates update as needed
May or may not be on the device itself

- Status Tracker: tracks update status of
devices under its administration

- Firmware Server: distributes
software/firmware packages to devices
May or may not be combined with Status Tracker

At IETF#101 we talked about the following three categories for firmware update interactions:

- Client-initiated: IoT device polls for updates and downloads image when it wants
- Server-initiated: Server pushes update to a device
- Hybrid: Server pushes notification of availability of an update to a device, and the client then
  downloads the image when it wants.

In https://tools.ietf.org/html/draft-ietf-suit-architecture-00 Brendan and I made a proposal for
a new terminology. Here is the relevant text:

-----

3.10.  Operating modes

   There are three broad classifications of update operating modes.

   * Self initiated
   * Third-party initiated
   * Hybrid

   Self initiated updates take the form of a proactive IoT device that
   checks for updates.  Third-party initiated updates are triggered by
   an actor other than the IoT device, be it a server, a peer, or a
   user.  Hybrid updates are those that require agreement from both the
   target IoT device and another actor.

   Third-party initiated updates are important to consider because
   timing of updates may need to be tightly controlled in some high-
   reliability environments.

   An IoT device goes through several steps in the course of an update,
   each of which can be self-initiated or third-party initiated, or
   hybrid.  An IoT device may go through the following steps, though
   this is not a comprehensive list.

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

   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.

   A dependency resolution phase is needed when more than one component
   can be updated or when a differential update is used.  The necessary
   dependencies must be available prior to installation.

   The download step is the process of acquiring a local copy of the
   payload.  When the download is self-initiated, this means that the
   IoT device chooses when a download occurs and initiates the download
   process.  When a download is third-party initiated, this means that
   either the remote service tells the IoT device when to download or
   that it initiates the transfer directly to the IoT device.  For
   example, a download from an HTTP server is initiated locally.  A
   transfer to a LwM2M Firmware Update resource [LwM2M] is initiated
   remotely.

   Installation is the act of processing the payload into a format that
   the IoT device can recognise.

   Each of these steps may require different permissions expressed in
   claims and may be implemented in a variety of ways.

----

Offline feedback from Dave indicates that it did not help improve clarify.
Hence, I am going it a new try. Let me know what you think.

-----

3.10.  Operating modes

   There are three broad classifications of update operating modes.

  * Client-initiated Update
  * Server-initiated Update
  * Hybrid Update

  Client-initiated updates take the form of a Communicator on a Device Core
  proactively checking for new firmware imagines provided by Firmware Servers.

  Server-initiated updates are important to consider because
  timing of updates may need to be tightly controlled in some high-
  reliability environments. In this case the Communicator, potentially in
  coordination with the Status Tracker, determines what IoT devices need
  qualify for a firmware update. Once those devices have been selected the
  Firmware Server distributes updates to those Device Cores.

  Note: This assumes that the Firmware Server is able to reach the Device Cores,
  which may require Device Cores to keep reachability information at the Communicator
  and / or at the Firmware Server up-to-date. This may also require keeping state at
  NATs and stateful packet filtering firewalls alive.

  Hybrid updates are those that require an interaction between the Device Core
  and the Firmware Server / Communicator. The Communicator pushes notifications
  of availability of an update to the Device Core, and the Device Core then
  downloads the image from the Firmware Server when it wants.

   An alternative approach is to consider the steps an IoT device has to go through
   in the course of an update:

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

   The notification step consists of the Communicator informing the Device Core
   that an update is available. This can be accomplished via polling (client-initiated),
   push notifications (server-initiated), or more complex
   mechanisms.

   The pre-authorisation step involves verifying whether the entity signing
   the manifest is indeed authorized to perform an update. The Device Core
   must also determine whether it should fetching and processing of the
   firmware image (unless it has been attached already to the manifest itself).

   A dependency resolution phase is needed when more than one component
   can be updated or when a differential update is used.  The necessary
   dependencies must be available prior to installation.

   The download step is the process of acquiring a local copy of the
   firmware image.  When the download is client-initiated, this means that the
   IoT device chooses when a download occurs and initiates the download
   process.  When a download is server-party initiated, this means that
   either the Communicator / Firmware Server tells the IoT device when
   to download or that it initiates the transfer directly to the IoT device.
   For example, a download from an HTTP-based Firmware Server is client-initiated.
   A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiated.

   If the Device Core has downloaded a new firmware image and is ready to
   install it it may need to wait for a trigger from a Communicator to
   install the firmware update, may trigger the update automatically, or
   may go through a more complex decision making process to determine
   the appropriate timing for an update (such as delaying the update
   process to a later time when end users are less impacted by the update process).

   Installation is the act of processing the payload into a format that
   the IoT device can recognise and the bootloader is responsible for then
   booting from the newly installed firmware image.

   Each of these steps may require different permissions.

----

Is this any better?

Writing the text above I noticed that the Communicator and the
Status Tracker have some overlapping functionality. Both entities
need to know about the status of the device. Also it would be
good to know what "initiates update" for the communicator
actually needs.

Finally, the term "Device Core" sounds a bit strange. Would it
be better to call it 'update service' or just refer to IoT device?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Jun 2018 09:36:27 +0000

A short version of my feedback can be summarized as:
> When a download is third-party initiated, this means that
> that it initiates the transfer directly to the IoT device.  

I find it very confusing to convolute these different concepts into the same term "third-party initiated",
and especially to have the step be "download" even when it is transferred directly rather than initiated by the device.
That's why I liked the taxonomy presented at IETF 101 which I found to be far more clear.

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

I find the text in the document now confusing and doesn't match the IETF 101 discussion.

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 6, 2018 5:27 PM
To: [email-masked]
Subject: [Suit] SUIT Architecture -- Operating modes

Hi all,

at the virtual interim meeting earlier this year Dave suggested terminology, which was based on ITU-T work for firmware updates:

- Device Core: stores/uses software/firmware, i.e., the IoT device itself

- Communicator: checks software/firmware status of device and initiates update as needed May or may not be on the device itself

- Status Tracker: tracks update status of devices under its administration

In https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata=Z8JJlDZINiolbZmqINLWCMEaWT1%2BcUkAGQpBqfhjvCw%3D&reserved=0 Brendan and I made a proposal for a new terminology. Here is the relevant text:

-----

3.10.  Operating modes

   * Self initiated
   * Third-party initiated
   * Hybrid

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

-----

3.10.  Operating modes

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

Is this any better?

Writing the text above I noticed that the Communicator and the Status Tracker have some overlapping functionality. Both entities need to know about the status of the device. Also it would be good to know what "initiates update" for the communicator actually needs.

Finally, the term "Device Core" sounds a bit strange. Would it be better to call it 'update service' or just refer to IoT device?

Ciao
Hannes

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata=W0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbqow8%3D&reserved=0

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 6 Jun 2018 11:58:13 +0200

Hi Dave

> 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.
Or are we implicitly mixing "notification" with "pre-authorization" aspects?

Emmanuel

> at the virtual interim meeting earlier this year Dave suggested
> terminology, which was based on ITU-T work for firmware updates:
>
> - Communicator: checks software/firmware status of device and initiates
> update as needed May or may not be on the device itself
>
> In
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata=Z8JJlDZINiolbZmqINLWCMEaWT1%2BcUkAGQpBqfhjvCw%3D&reserved=0
> Brendan and I made a proposal for a new terminology. Here is the relevant
> text:
>
> -----
>
> 3.10.  Operating modes
>
> Writing the text above I noticed that the Communicator and the Status
> Tracker have some overlapping functionality. Both entities need to know
> about the status of the device. Also it would be good to know what
> "initiates update" for the communicator actually needs.
>
> Finally, the term "Device Core" sounds a bit strange. Would it be better
> to call it 'update service' or just refer to IoT device?
>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jun 2018 10:20:19 +0000

Hi Dave,

In my new text proposal I did not use the term "third party initiated" anymore.
I used the terminology suggested at the IETF meeting.

Are you sure you looked at the correct text?

Ciao
Hannes

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: 06 June 2018 11:36
To: Hannes Tschofenig; [email-masked]
Subject: RE: SUIT Architecture -- Operating modes

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 6, 2018 5:27 PM
To: [email-masked]
Subject: [Suit] SUIT Architecture -- Operating modes

Hi all,

-----

3.10.  Operating modes

   * Self initiated
   * Third-party initiated
   * Hybrid

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

-----

3.10.  Operating modes

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

Is this any better?

Ciao
Hannes

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 6 Jun 2018 12:26:53 +0200

> The transfer of the actual image can also be device initiated (pull) or remotely initiated (push).
  in general I agree with this classification but just wondering about 
"initiated". How would you map a remotely initiated pull, e.g., someone 
logs in to the IoT device to trigger the update?

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Jun 2018 13:14:43 +0000

It is an improvement, yes.  It still uses the word "download" though even for transfers
where a server pushes the image to the device.   I think a more direction-agnostic term like
"file transfer" would be better.

Dave

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Wednesday, June 6, 2018 6:20 PM
To: Dave Thaler <[email-masked]>; [email-masked]
Subject: RE: SUIT Architecture -- Operating modes

Hi Dave,

Ciao
Hannes

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: 06 June 2018 11:36
To: Hannes Tschofenig; [email-masked]
Subject: RE: SUIT Architecture -- Operating modes

A short version of my feedback can be summarized as:
> When a download is third-party initiated, this means that either the 
> remote service tells the IoT device when to download or that it 
> initiates the transfer directly to the IoT device.

I find it very confusing to convolute these different concepts into the same term "third-party initiated", and especially to have the step be "download" even when it is transferred directly rather than initiated by the device.
That's why I liked the taxonomy presented at IETF 101 which I found to be far more clear.

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 6, 2018 5:27 PM
To: [email-masked]
Subject: [Suit] SUIT Architecture -- Operating modes

Hi all,

-----

3.10.  Operating modes

   * Self initiated
   * Third-party initiated
   * Hybrid

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

-----

3.10.  Operating modes

   * Notification
   * Pre-authorisation
   * Dependency resolution
   * Download
   * Installation

----

Is this any better?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2018 13:51:56 -0400

> If the image is pushed anyways, there is arguably no need for prior

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.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [