Change:
A Firmware Update Architecture for Internet of Things <del> draft-ietf-suit-architecture-12 </del> <ins> draft-ietf-suit-architecture-13 </ins> Abstract Vulnerabilities with Internet of Things (IoT) devices have raised the <del> need for a solid and secure firmware update mechanism that is also suitable for constrained devices.  Incorporating such update </del> <ins> need for a reliable and secure firmware update mechanism suitable for devices with resource constraints.  Incorporating such update </ins> mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. <del> This document lists requirements and describes an architecture for a firmware update mechanism suitable for IoT devices.  The architecture is agnostic to the transport of the firmware images and associated meta-data. </del> <ins> In addition to the definition of terminology and an architecture this document motivates the standardization of a manifest format as transport-agnostic means for describing and protecting firmware updates. </ins> 1. <del> When developing Internet of Things (IoT) devices, one of the most difficult problems to solve is how to update firmware on the device. Once the device is deployed, firmware updates play a critical part in its lifetime, particularly when devices have a long lifetime, are deployed in remote or inaccessible areas where manual intervention is cost prohibitive or otherwise difficult.  Updates to the firmware of an IoT device are done to fix bugs in software, to add new functionality, and to re-configure the device to work in new </del> <ins> Firmware updates can help to fix security vulnerabilities and are considered to be an important building block in securing IoT devices. Due to rising concerns about insecurre IoT devices the Internet Architecture Board (IAB) organized a 'Workshop on Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at the bigger picture.  A report about this workshop can be found at RFC8240.  The workshop revealed a number of challenges for developers and led to the formation of the IETF Software Updates for Internet of Things (SUIT) working group. Developing secure Internet of Things (IoT) devices is not an easy task and supporting a firmware update solution requires skillful engineers.  Once devices are deployed, firmware updates play a critical part in their lifecycle management, particularly when devices have a long lifetime, are deployed in remote or inaccessible areas where manual intervention is cost prohibitive or otherwise difficult.  Firmware updates for IoT devices are expected to work automatic, i.e. without user involvement.  Automatic updates that do not require human intervention are key to a scalable solution for fixing software vulnerabilities. Firmware updates are not only done to fix bugs, but they can also add new functionality, and to re-configure the device to work in new </ins> environments or to behave differently in an already deployed context. <del> The firmware update process, among other goals, has to ensure that </del> <ins> The firmware update process has to ensure that </ins> The firmware image is authenticated and integrity protected. <del> Attempts to flash a modified firmware image or an image from an unknown source are prevented. </del> <ins> Attempts to flash a maliciously modified firmware image or an image from an unknown, untrusted source must be prevented.  In examples this document uses asymmetric cryptography because it is the preferred approach by many IoT deployments.  The use of symmetric credentials is also supported and can be used by very constrained IoT devices. </ins> The firmware image can be confidentiality protected so that attempts by an adversary to recover the plaintext binary can be <del> prevented.  Obtaining the firmware is often one of the first steps to mount an attack since it gives the adversary valuable insights into used software libraries, configuration settings and generic functionality (even though reverse engineering the binary can be a tedious process). This version of the document assumes asymmetric cryptography and a public key infrastructure.  Future versions may also describe a symmetric key approach for very constrained devices. </del> <ins> mitigated or at least made more difficult.  Obtaining the firmware is often one of the first steps to mount an attack since it gives the adversary valuable insights into used software libraries, configuration settings and generic functionality.  Even though reverse engineering the binary can be a tedious process modern reverse engineering frameworks have made this task a lot easier. </ins> While the standardization work has been informed by and optimised for firmware update use cases of Class 1 devices (according to the device

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