Change:
the architecture that restricts its use to only these constrained IoT devices.  Moreover, this architecture is not limited to managing software updates, but can also be applied to managing the delivery of <del> arbitrary data, such as configuration information and keys. More details about the security goals are discussed in architecture and requirements are described in requirements. </del> <ins> arbitrary data, such as configuration information and keys.  Unlike higher end devices, like laptops and desktop PCs, many IoT devices do not have user interfaces and support for unattended updates are therefore essential for the design of a practical solution. Constrained IoT devices often use a software engineering model where a developer is responsible for creating and compiling all software running on the device into a single, monolithic firmware image.  On higher end devices application software is, on the other hand, often downloaded separately and even obtained from developers different to the developers of the lower level software.  The details for how to obtain those application layer software binaries then depends heavily on the platform, programming language uses and the sandbox the software is executed in. While the IETF standardization work has been focused on the manifest format, a fully interoperable solution needs more than a standardized manifest.  For example, protocols for transferring firmware images and manifests to the device need to be available as well as the status tracker functionality.  These building blocks have been developed by various organizations under the umbrella of an IoT device management solution.  The LwM2M protocol is one IoT device management protocol. There are, however, several areas that (partially) fall outside the scope of the IETF and other standards organizations but need to be considered by firmware authors, as well as device and network operators.  Here are some of them, as highlighted during the IOTSU workshop: Installing firmware updates in a robust fashion so that the update does not break the device functionality of the environment this device operates in.  This requires proper testing and offering recovery strategies when a firmware update is unsuccessful. Making firmware updates available in a timely fashion considering the complexity of the decision making process for updating devices, potential re-certification requirements, the length of a supply chain an update needs to go through before it reaches the end customer, and the need for user consent to install updates. Ensuring an energy efficient design of a battery-powered IoT devices because a firmware update, particularly writing the firmware image to flash, is a heavy task for a device. Creating incentives for device operators to use a firmware update mechanism and to demand the integration of it from IoT device vendors. This document starts with a terminology followed by the description of the architecture.  We then explain the bootloader and how it integrates with the firmware update mechanism.  Subsequently, we offer a categorization of IoT devices in terms of their hardware capabilities relevant for firmware updates.  Next, we talk about the manifest structure and how to use it to secure firmware updates.  We conclude with a more detailed example. </ins> 2. <ins> 2.1. </ins> This document uses the following terms: Manifest: The manifest contains meta-data about the firmware

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