Change:
cryptographic information, such as digital signatures or message authentication codes (MACs). <del> The manifest information model is described in SUIT-IM. </del> <ins> The manifest information model is described in I-D.ietf-suit- information-model. </ins> 7. <ins> Although these documents attempt to define a firmware update architecture that is applicable to both existing systems, as well as yet-to-be-conceived systems; it is still helpful to consider existing architectures. 7.1. The simplest, and currently most common, architecture consists of a single MCU along with its own peripherals.  These SoCs generally contain some amount of flash memory for code and fixed data, as well as RAM for working storage.  These systems either have a single firmware image, or an immutable bootloader that runs a single image. A notable characteristic of these SoCs is that the primary code is generally execute in place (XIP).  Combined with the non-relocatable nature of the code, firmware updates need to be done in place. 7.2. Another configuration consists of a similar architecture to the previous, with a single CPU.  However, this CPU supports a security partitioning scheme that allows memory (in addition to other things) to be divided into secure and normal mode.  There will generally be two images, one for secure mode, and one for normal mode.  In this configuration, firmware upgrades will generally be done by the CPU in secure mode, which is able to write to both areas of the flash device.  In addition, there are requirements to be able to update either image independently, as well as to update them together atomically, as specified in the associated manifests. 7.3. This configuration has two or more CPUs in a single SoC that share memory (flash and RAM).  Generally, they will be a protection mechanism to prevent one CPU from accessing the other's memory. Upgrades in this case will typically be done by one of the CPUs, and is similar to the single CPU with secure mode. 7.4. This configuration has two or more CPUs, each having their own memory.  There will be a communication channel between them, but it will be used as a peripheral, not via shared memory.  In this case, each CPU will have to be responsible for its own firmware upgrade. It is likely that one of the CPUs will be considered a master, and will direct the other CPU to do the upgrade.  This configuration is commonly used to offload specific work to other CPUs.  Firmware dependencies are similar to the other solutions above, sometimes allowing only one image to be upgraded, other times requiring several to be upgraded atomically.  Because the updates are happening on multiple CPUs, upgrading the two images atomically is challenging. 8. </ins> The following example message flow illustrates the interaction for distributing a firmware image to a device starting with an author <del> uploading the new firmware to untrusted storage and creating a manifest.  The firmware and manifest are stored on the same untrusted storage. </del> <ins> uploading the new firmware to Firmware Server and creating a manifest.  The firmware and manifest are stored on the same Firmware Server. </ins> <del> 8. </del> <ins> 9. </ins> This document does not require any actions by IANA. <del> 9. </del> <ins> 10. </ins> Firmware updates fix security vulnerabilities and are considered to be an important building block in securing IoT devices.  Due to the

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)