[Fud] (quick) review of draft-moran-fud-architecture-00

[Emmanuel Baccelli <[e-mail]>]

Hi everyone,

thanks for the draft.

to prepare tomorrow's meeting, I read the drafts as fast as I could ( I
hope note too fast ;)

It reads well already, and it is actually pretty close to what
we are doing in RIOT.

See below some comments, questions and suggestions.

=====
General comments:
=====

1. In the proposed architecture some trust is required in the storage
element, which is assumed to correctly:
- serve the latest manifest/firmware (if the device pulls)
- pushe/signal newer manifests to the device (if the author pushes)

2. What is specific to firmware in the document so far?
It seems to me that this could apply to any software module on an IoT
device, not necessarily a firmware.
For instance it could be "application" logic (We have use cases where we
are updating some software, but not the firmware).
Why not generalize somehow the terminology to something more generic like
"software update" or something similar?


=====
Some more detailed comments:
=====

# in Section 3:
why/how/what small bootloader?

why/how friendly to broadcast => no TLS, Object security
but: are we really going to broadcast a (relatively large) firmware?


# in Section 3.4:

"the device is required to provide a minimum of two storage locations for
firmware and one bootable location for firmware."

Is reliability possible only with this approach?
This seems out of scope of the generic architecture.


# in Section 3.5:
How about rephrasing like:
"The approach must not require a large bootloader"


# in Section 3.6
Here I think the draft should reference examples of what "existing firmware
formats" are alluded to.
In my opinion, this section could be removed for two reasons:
1. because the metadata is anyways separate from the actual firmware,
2. the software might not be firmware, but just a software module (as per
my comment above)


# in Section 3.7
I would suggest to have this document focus primarily on single MCU devices.
Ideally: extensions to cover multi-firmware devices would either be in a
later part of the document or in a separate document.

At this point in the document it is obscure what the distinctions are
between:
Author, Store, Apply, Approve, Qualify

# in Section 4:
How about being more assertive here, such as:

The firmware image MAY be encrypted and MUST be integrity protected AS WELL
AS AUTHENTICATED/AUTHORIZED.
The meta-data MUST integrity protected and AUTHENTICATED.


# in Section 5:

   -  When should the device apply the update?
   out of scope?

   -  How should the device apply the update?
   out of scope?

   -  What kind of firmware binary is it?
   is this different from the question "should it apply the firmware"?

   -  Where should the update be obtained?
   if we are not making the assumption that metadata and firmware are
stored in difference places, is this redundant?

   -  Where should the firmware be stored?
   out of scope?


# in Section 6:
"information about when the firmware update has to be applied".
I guess the default should be "as soon as possible".
However, in cases when the time is no synchronized, I'm wondering how the
device
could interpret this "when" indication.



# in Section 7:

Typically the author will produce/transfer a new firmware and its
(manifest) metadata in one go.
In practice, firmware and manifest might even be bundled in a single file
(?).
Hence I would suggest to invert the order of the steps "Upload Firmware"
 and "Create Manifest".