Change:
use of third-party content distribution networks for payload distribution. <del> 3.3. End-to-end security between the author and the device is shown in architecture. Authentication ensures that the device can cryptographically identify the author(s) creating firmware images and manifests.  Authenticated identities may be used as input to the authorization process. Integrity protection ensures that no third party can modify the manifest or the firmware image. For confidentiality protection of the firmware image, it must be done in such a way that every intended recipient can decrypt it.  The information that is encrypted individually for each device must maintain friendliness to Content Distribution Networks, bulk storage, and broadcast protocols. A manifest specification must support different cryptographic algorithms and algorithm extensibility.  Due of the nature of unchangeable code in ROM for use with bootloaders the use of post- quantum secure signature mechanisms, such as hash-based signatures RFC8778, are attractive.  These algorithms maintain security in presence of quantum computers. A mandatory-to-implement set of algorithms will be specified in the manifest specification I-D.ietf-suit-manifest}. 3.4. A device presented with an old, but valid manifest and firmware must not be tricked into installing such firmware since a vulnerability in the old firmware image may allow an attacker to gain control of the device. 3.5. A power failure at any time must not cause a failure of the device. Equally, adverse network conditions during an update must not cause the failure of the device.  A failure to validate any part of an update must not cause a failure of the device.  One way to achieve this functionality is to provide a minimum of two storage locations for firmware and one bootable location for firmware.  An alternative approach is to use a 2nd stage bootloader with build-in full featured firmware update functionality such that it is possible to return to the update process after power down. Note: This is an implementation requirement rather than a requirement on the manifest format. </del> <ins> Firmware images and manifests may be conveyed as a bundle or detached.  The manifest must support both approaches. </ins> <del> 3.6. Throughout this document we assume that the bootloader itself is distinct from the role of the firmware consumer and therefore does not manage the firmware update process.  This may give the impression that the bootloader itself is a completely separate component, which is mainly responsible for selecting a firmware image to boot. </del> <ins> For distribution as a bundle, the firmware image is embedded into the manifest.  This is a useful approach for deployments where devices are not connected to the Internet and cannot contact a dedicated firmware server for the firmware download.  It is also applicable when the firmware update happens via a USB sticks or short range radio technologies (such as Bluetooth Smart). </ins> <del> The overlap between the firmware update process and the bootloader functionality comes in two forms, namely First, a bootloader must verify the firmware image it boots as part of the secure boot process.  Doing so requires meta-data to be stored alongside the firmware image so that the bootloader can cryptographically verify the firmware image before booting it to ensure it has not been tampered with or replaced.  This meta-data used by the bootloader may well be the same manifest obtained with the firmware image during the update process (with the severable fields stripped off). Second, an IoT device needs a recovery strategy in case the firmware update / boot process fails.  The recovery strategy may include storing two or more firmware images on the device or offering the ability to have a second stage bootloader perform the firmware update process again using firmware updates over serial, USB or even wireless connectivity like a limited version of Bluetooth Smart.  In the latter case the firmware consumer functionality is contained in the second stage bootloader and requires the necessary functionality for executing the firmware update process, including manifest parsing. In general, it is assumed that the bootloader itself, or a minimal part of it, will not be updated since a failed update of the bootloader poses a risk in reliability. All information necessary for a device to make a decision about the installation of a firmware update must fit into the available RAM of a constrained IoT device.  This prevents flash write exhaustion. This is typically not a difficult requirement to accomplish because there are not other task/processing running while the bootloader is active (unlike it may be the case when running the application firmware). Note: This is an implementation requirement. 3.7. Since parsers are known sources of bugs, any parsers used to process the manifest must be minimal.  Additionally, it must be easy to parse only those fields that are required to validate at least one signature or MAC with minimal exposure. 3.8. The design of the firmware update mechanism must not require changes to existing firmware formats. 3.9. When a device obtains a monolithic firmware image from a single author without any additional approval steps then the authorization flow is relatively simple.  There are, however, other cases where more complex policy decisions need to be made before updating a device. In this architecture the authorization policy is separated from the underlying communication architecture.  This is accomplished by separating the entities from their permissions.  For example, an author may not have the authority to install a firmware image on a device in critical infrastructure without the authorization of a device operator.  In this case, the device may be programmed to reject firmware updates unless they are signed both by the firmware author and by the device operator. Alternatively, a device may trust precisely one entity, which does all permission management and coordination.  This entity allows the device to offload complex permissions calculations for the device. 3.10. 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 firmware consumer on a device proactively checking (polling) for new firmware images. 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 status tracker determines what devices qualify for a firmware update.  Once those devices have been selected the firmware server distributes updates to the firmware consumers. Note: This assumes that the status tracker is able to reach the device, which may require devices to keep reachability information at the status tracker 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 firmware consumer and the status tracker.  The status tracker pushes notifications of availability of an update to the firmware consumer, and it then downloads the image from a firmware server as soon as possible. While these broad classifications encompass the majority of operating modes, some may not be covered in these classifications.  By reinterpreting these modes as a set of operations performed by the system as a whole, all operating modes can be represented. The steps performed in the course of an update by the system containing an updatable device are: Notification Pre-authorisation Dependency resolution Download Installation This is a coarse-grained high level view of steps required to install a new firmware.  By considering where in the system each of these steps is performed, each operating mode can be represented.  Each of these steps is broken down into smaller constituent parts. architecture defines the steps taken from the perspective of the communication between actors in the system. bootloader describes some additional steps that a bootloader takes in addition to those described here. example shows an example of the steps undertaken by each party in the course of an update. The notification step consists of the status tracker informing the firmware consumer that an update is available.  This can be accomplished via polling (client-initiated), push notifications (server-initiated), or more complex mechanisms. </del> <ins> Alternatively, the manifest is distributed detached from the firmware image.  Using this approach, the firmware consumer is presented with the manifest first and then needs to obtain one or more firmware images as dictated in the manifest. </ins> The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update.  The

Discussion:
First chunk of changes.
This is a really great set of edits. I think that it really improves the document as a whole! I have suggested a couple of minor edits.Quick partial language review