Change:
firmware image.  The firmware consumer plays the role of the update component on the IoT device typically running in the application firmware.  It interacts with the firmware server and <del> with the status tracker, if present. (IoT) Device: A device refers to the entire IoT product, which consists of one or many MCUs, sensors and/or actuators.  Many IoT devices sold today contain multiple MCUs and therefore a single device may need to obtain more than one firmware image and manifest to succesfully perform an update.  The terms device and firmware consumer are used interchangably since the firmware consumer is one software component running on an MCU on the device. Status Tracker: The status tracker offers device management functionality to retrieve information about the installed firmware on a device and other device characteristics (including free memory and hardware components), to obtain the state of the firmware update cycle the device is currently in, and to trigger the update process.  The deployment of status trackers is flexible and they may be used as cloud-based servers, on-premise servers, embedded in edge computing device (such as Internet access gateways or protocol translation gateways), or even in smart phones and tablets.  IoT devices that self-initiate updates may run a status tracker.  Similarly, IoT devices that act as a proxy for other IoT devices in a protocol translation or edge computing device node may also run a status tracker.  However, if the device contains multiple MCUs, the main MCU may act as a limited status tracker towards the other MCUs if updates are to be synchronized across MCUs.  How much functionality a status tracker includes depends on the selected configuration of the device management functionality and the communication environment it is used in.  In a generic networking environment the protocol used between the client and the server-side of the status tracker need to deal with Internet communication challenges involving firewall and NAT traversal.  In other cases, the communication interaction may be rather simple.  This architecture document does not impose requirements on the status tracker. </del> <ins> with the status tracker client (locally). </ins> Firmware Server: The firmware server stores firmware images and manifests and distributes them to IoT devices.  Some deployments may require a store-and-forward concept, which requires storing the firmware images/manifests on more than one entity before they reach the device.  There is typically some interaction <del> between the firmware server and the status tracker but those </del> <ins> between the firmware server and the status tracker and these two </ins> entities are often physically separated on different devices for scalability reasons. <del> Device Operator: The actor responsible for the day-to-day operation of a fleet of IoT devices. Network Operator: The actor responsible for the operation of a network to which IoT devices connect. Claim: A piece of information asserted about a recipient or payload. In addition to the entities in the list above there is an orthogonal infrastructure with a Trust Provisioning Authority (TPA) distributing trust anchors and authorization permissions to various entities in the system.  The TPA may also delegate rights to install, update, enhance, or delete trust anchors and authorization permissions to other parties in the system.  This infrastructure overlaps the communication architecture and different deployments may empower certain entities while other deployments may not.  For example, in some cases, the Original Design Manufacturer (ODM), which is a company that designs and manufactures a product, may act as a TPA and may decide to remain in full control over the firmware update process of their products. The terms 'trust anchor' and 'trust anchor store' are defined in RFC6024: "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." "A trust anchor store is a set of one or more trust anchors stored in a device.  A device may have more than one trust anchor store, each of which may be used by one or more applications."  A trust anchor store must resist modification against unauthorized insertion, deletion, and modification. </del> <ins> Bootloader: A bootloader is a piece of software that is executed once a microcontroller has been reset.  It is responsible for deciding what code to execute. </ins> 3. <del> The firmware update mechanism described in this specification was designed with the following requirements in mind: Agnostic to how firmware images are distributed Friendly to broadcast delivery Use state-of-the-art security mechanisms Rollback attacks must be prevented High reliability Operate with a small bootloader Small Parsers Minimal impact on existing firmware formats Robust permissions </del> <ins> More devices today than ever before are connected to the Internet, which drives the need for firmware updates to be provided over the Internet rather than through traditional interfaces, such as USB or RS-232.  Updating updates over the Internet requires the device to fetch the new firmware image as well as the manifest. </ins> <del> Diverse modes of operation </del> <ins> Hence, the following components are necessary on a device for a firmware update solution: </ins> <del> Suitability to software and personalization data </del> <ins> the Internet protocol stack for firmware downloads.  Because firmware images are often multiple kilobytes, sometimes exceeding one hundred kilobytes, in size for low end IoT devices and even several megabytes large for IoT devices running full-fledged operating systems like Linux, the protocol mechanism for retrieving these images needs to offer features like congestion control, flow control, fragmentation and reassembly, and mechanisms to resume interrupted or corrupted transfers. </ins> <del> 3.1. </del> <ins> the capability to write the received firmware image to persistent storage (most likely flash memory). a manifest parser with code to verify a digital signature or a message authentication code. the ability to unpack, to decompress and/or to decrypt the received firmware image. (optionally) a status tracker. The features listed above are most likely offered by code in the application firmware image running on the device rather than by the bootloader itself.  Note that cryptographic algorithms will likely run in a trusted execution environment, on a separate MCU, in a hardware security module, or in a secure element rather than in the same context with the application code. arch-figure shows the architecture where a firmware image is created by an author, and made available to a firmware server.  For security reasons, the author will not have the permissions to upload firmware images to the firmware server and to initiate an update him- or herself.  Instead, authors will make firmware images available to the device operators.  Note that there may be a longer supply chain involved to pass software updates from the author all the way to the party that can then finally make a decision to deploy it with IoT devices. As a first step in the firmware update process, the the status tracker client need to be made aware of the availability of a new firmware update by the status tracker server.  This can be accomplished via polling (client-initiated), push notifications (server-initiated), or more complex mechanisms (such as a hybrid approach): Client-initiated updates take the form of a status tracker client proactively checking (polling) for updates. With Server-initiated updates the server-side component of the status tracker learns about a new firmware version and determines what devices qualify for a firmware update.  Once the relevant devices have been selected, the status tracker informs these devices and the firmware consumers obtain those images and manifests.  Server-initiated updates are important because they allow a quick response time.  Note that the client-side status tracker needs to be reachable by the server-side component.  This may require devices to keep reachability information on the server-side up-to-date and state at NATs and stateful packet filtering firewalls alive. Using a hybrid approach the server-side of the status tracker pushes notifications of availability of an update to the client side and requests the firmware consumer to pull the manifest and the firmware image from the firmware server. Once the device operator triggers update via the status tracker, it will keep track of the update process on the device.  This allows the device operator to know what devices have received an update and which of them are still pending an update. </ins> Firmware images can be conveyed to devices in a variety of ways, <del> including USB, UART, WiFi, BLE, low-power WAN technologies, etc.  and use different protocols (e.g., CoAP, HTTP).  The specified mechanism needs to be agnostic to the distribution of the firmware images and manifests. 3.2. This architecture does not specify any specific broadcast protocol. However, given that broadcast may be desirable for some networks, updates must cause the least disruption possible both in metadata and firmware transmission. </del> <ins> including USB, UART, WiFi, BLE, low-power WAN technologies, mesh networks and many more.  At the application layer a variety of protocols are also available: MQTT, CoAP, and HTTP are the most popular application layer protocols used by IoT devices.  This architecture does not make assumptions about how the firmware images are distributed to the devices and therefore aims to support all these technologies. In some cases it may be desireable to distribute firmware images using a multicast or broadcast protocol.  This architecture does not make recommendations for any such protocol.  However, given that broadcast may be desirable for some networks, updates must cause the least disruption possible both in metadata and firmware transmission. </ins> For an update to be broadcast friendly, it cannot rely on link layer, network layer, or transport layer security.  A solution has to rely on security protection applied to the manifest and firmware image

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