Skip to main content

A Firmware Update Architecture for Internet of Things
draft-ietf-suit-architecture-16

Revision differences

Document history

Date Rev. By Action
2021-04-30
16 (System)
Received changes through RFC Editor sync (created alias RFC 9019, changed abstract to 'Vulnerabilities in Internet of Things (IoT) devices have raised the need …
Received changes through RFC Editor sync (created alias RFC 9019, changed abstract to 'Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.

In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.', changed pages to 25, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-04-30, changed IESG state to RFC Published)
2021-04-30
16 (System) RFC published
2021-04-27
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-03-24
16 (System) RFC Editor state changed to AUTH48
2021-03-01
16 Russ Housley Added to session: IETF-110: suit  Thu-1530
2021-02-25
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-02-11
16 Tero Kivinen Closed request for Telechat review by SECDIR with state 'Overtaken by Events'
2021-02-11
16 Tero Kivinen Assignment of request for Telechat review by SECDIR to Rich Salz was marked no-response
2021-01-28
16 (System) RFC Editor state changed to EDIT
2021-01-28
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-01-28
16 (System) Announcement was received by RFC Editor
2021-01-27
16 (System) IANA Action state changed to No IANA Actions from In Progress
2021-01-27
16 (System) IANA Action state changed to In Progress
2021-01-27
16 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-01-27
16 Cindy Morgan IESG has approved the document
2021-01-27
16 Cindy Morgan Closed "Approve" ballot
2021-01-27
16 Cindy Morgan Ballot approval text was generated
2021-01-27
16 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-01-27
16 Hannes Tschofenig New version available: draft-ietf-suit-architecture-16.txt
2021-01-27
16 (System) New version approved
2021-01-27
16 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , David Brown , Hannes Tschofenig , Milosch Meriac , suit-chairs@ietf.org
2021-01-27
16 Hannes Tschofenig Uploaded new revision
2021-01-17
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-01-17
15 Hannes Tschofenig New version available: draft-ietf-suit-architecture-15.txt
2021-01-17
15 (System) New version approved
2021-01-17
15 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , David Brown , Hannes Tschofenig , Milosch Meriac , suit-chairs@ietf.org
2021-01-17
15 Hannes Tschofenig Uploaded new revision
2020-11-05
14 Dave Thaler Added to session: IETF-109: suit  Fri-1430
2020-11-05
14 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2020-11-05
14 Robert Wilton
[Ballot comment]
Thank you for this document.  I found it informative and interesting.

One minor comment:

7.  Securing Firmware Updates

      The
  …
[Ballot comment]
Thank you for this document.  I found it informative and interesting.

One minor comment:

7.  Securing Firmware Updates

      The
      information that is encrypted individually for each device/
      recipient must maintain friendliness to Content Distribution
      Networks, bulk storage, and broadcast protocols.

Although I think that I understand the intent here, I'm not sure whether friendliness is the best choice of term here.  I presume that it means "must be done in a way that is usable with".

Regards,
Rob
2020-11-05
14 Robert Wilton Ballot comment text updated for Robert Wilton
2020-11-05
14 Robert Wilton
[Ballot comment]
Thank you for this document.  I found it informative and interesting.

I minor comment:

7.  Securing Firmware Updates

      The
  …
[Ballot comment]
Thank you for this document.  I found it informative and interesting.

I minor comment:

7.  Securing Firmware Updates

      The
      information that is encrypted individually for each device/
      recipient must maintain friendliness to Content Distribution
      Networks, bulk storage, and broadcast protocols.

Although I think that I understand the intent here, I'm not sure whether friendliness is the best choice of term here.  I presume that it means "must be done in a way that is usable with".

Regards,
Rob
2020-11-05
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-05
14 Benjamin Kaduk
[Ballot comment]
Does the XIP case mean that repeated firmware updates would have
potential to cause undue wear on the fixed flash cells that hold …
[Ballot comment]
Does the XIP case mean that repeated firmware updates would have
potential to cause undue wear on the fixed flash cells that hold the
firmware image?  If so, this might be noted in the security
considerations.

I am not sure that I have fully digested Bob Briscoe's detailed review
comments, but it seems like we may want to continue to reflect on which
portions of the architecture will be optional to implement, and how we
might indicate that in the document.

I also made a pull request for some editorial nits at
https://github.com/suit-wg/architecture/pull/15 .

Section 1

  otherwise difficult.  Firmware updates
  for IoT devices are expected to work automatically, i.e. without user
  involvement.  Conversely, IoT devices are expected to account for
  user preferences and consent when scheduling updates.  Automatic

I can't quite tell if the "Conversely" case is intending to refer to IoT
or non-IoT devices.

  The firmware update process has to ensure that

  -  The firmware image is authenticated and integrity protected.
      [...]

  -  The firmware image can be confidentiality protected so that
      attempts by an adversary to recover the plaintext binary can be
      [...]

Perhaps it's just because Bob Briscoe's comments are fresh in my mind,
but there seems to be something of a mismatch across these texts -- we
"have to ensure" that the firmware *is* authenticated and integrity
protected, but only that the image *can be* confidentiality protected.
Is it really the case that we can ensure that an update process *can be*
confidentiality protected, or is the confidentiality requirement more of
a requirement on the architecture than on actual deployment?

  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.  Devices also require a mechanism to
  discover the status tracker(s) and/or firmware servers, for example
  using pre-configured hostnames or [RFC6763] DNS-SD.  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.

We might put some forward references to things we do cover (like status
tracker(s)), and a reference for LwM2M as well.

Section 3

  Hence, the following components are necessary on a device for a
  firmware update solution:
  [...]
  -  a status tracker.

Earlier we said that having the status tracker on the device was fairly
uncommon.

Section 7

  time horizon for quantum-accelerated key extraction.  The worst-case
  estimate, at time of writing, for the time horizon to key extraction
  with quantum acceleration is approximately 2030, based on current
  research [quantum-factorization].

I'm not sure that I see how the reference suports the "approximately
2030" statement.
2020-11-05
14 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-11-05
14 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please add reference to LwM2M in Section 1.

Please also address all comments raised …
[Ballot comment]
Thank you for the work put into this document.

Please add reference to LwM2M in Section 1.

Please also address all comments raised by Mohit Sethi during the IoT directorate review (I saw that Brendan has already replied):
https://datatracker.ietf.org/doc/review-ietf-suit-architecture-13-iotdir-telechat-sethi-2020-10-20/

I hope that this helps to improve the document,

Regards,

-éric
2020-11-05
14 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-11-04
14 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-11-04
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
14 Alvaro Retana
[Ballot comment]
I was surprised to see that there no Normative references -- are there no other documents required to be read to understand the …
[Ballot comment]
I was surprised to see that there no Normative references -- are there no other documents required to be read to understand the architecture?

It seems to me that I-D.ietf-suit-information-model should be a Normative reference because it contains an "in-depth examination of the security considerations of the architecture" (this document).
2020-11-04
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-11-02
14 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-11-01
14 Barry Leiba
[Ballot comment]
Nice work on this; thanks.  I have a bunch of comments, but all minor.

— Section 1 —

  Firmware updates can help …
[Ballot comment]
Nice work on this; thanks.  I have a bunch of comments, but all minor.

— Section 1 —

  Firmware updates can help to fix security vulnerabilities and are
  considered to be an important building block in securing IoT devices.

Nit: “firmware updates” is plural, and “building block” is singular.  I think it’s actually *doing* the updates that’s the building block, not he updates themselves.  And you can just make the statement, without “are considered”.  How do you like this version?:

NEW
  Firmware updates can help to fix security vulnerabilities, and
  performing updates is an important building block in securing
  IoT devices.
END

  Due to rising concerns about insecure 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.

The details of when and where the workshop happened isn’t important here, and it’s rigt up front in 8240 anyway.  I suggest trimming that, because the important part is pointing people to the worshop report and saying what’s in the next sentence about the formation of the SUIT WG.

NEW
  Due to rising concerns about insecure IoT devices the Internet
  Architecture Board (IAB) organized a 'Workshop on Internet of Things
  (IoT) Software Update (IOTSU)' [RFC8240] to take a look at
  the bigger picture.  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.
END

  Firmware updates are not only done to fix bugs, but they can also add
  new functionality, and re-configure

Grammar nit: “Firmware updates are done not only to fix bugs, but also to add new functionality and to reconfigure”

  Unlike higher end devices, like laptops and desktop PCs, many
  IoT devices do not have user interfaces and support for unattended
  updates is, therefore, essential for the design of a practical

My first reading of this was that “many IoT devices do not have user interfaces and support for unattended updates.”  I had to read it again to correctly interpret the sentence.  If you replace “interfaces and” with “interfaces;” it fixes that problem easily.

  using pre-configured hostnames or [RFC6763] DNS-SD.

The citation should go after “DNS-SD”.

— Section 2.1 —

  -  Firmware Image: The firmware image, or image, is a binary

The “or image” seems odd there.  Maybe like this?:

NEW
  -  Firmware Image: The firmware image, or simply the “image”,
      is a binary
END

— Section 2.3 —

      The deployment of status trackers is flexible and may
      be found at
      cloud-based servers, on-premise servers, or may be embedded in
      edge computing devices.

(Odd line-break here...)
Nit: the list is not parallel, and the intro doesnt read right.  Try this?:

NEW
      The deployment of status trackers is flexible: they may
      be found at cloud-based servers or on-premise servers,
      or they may be embedded in edge computing devices.
END

— Section 3 —

  images to the firmware server and to initiate an update him- or
  herself.

Nit: I suggest avoiding the awkwardness by saying “and to initiate an update directly.”

  As a first step in the firmware update process, the status tracker
  client needs to be made aware of the availability of a new firmware
  update by the status tracker server.

Nit: passive voice makes this more awkward than it needs to be, especially as you have a clear subject already (the server).  Why not make it active?:

NEW
  As a first step in the firmware update process, the status tracker
  server needs to inform the status tracker client that a new firmware
  update is available.
END

  -  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.

As written, this is exactly the same as the server-initiated scenario.  In both cases, the server tells the client that an update is available, and the firmware consumer fetches the manifest and image.  What is the difference meant to be?  Do one or both of the descriptions need to be tweaked?  (I’m guessing that the server-initiated description should be changed to say that the server pushes the manifest and image, rather than waiting for the client to fetch it... yes?)

  If the firmware consumer has downloaded a new firmware image and is
  ready to install it, to initiate the installation, it may - either
  need to wait for a trigger from the status tracker, - or trigger the
  update automatically, - or go through a more complex decision making
  process to determine the appropriate timing for an update.

Are those dashes meant to be bullets in a list, and so is this a formatting glitch?

  Devices
  must not fail when a disruption occurs during the update process.
  For example, a power failure or network disruption during the update
  process must not cause the device to fail.

Nit: why not merge these two sentences?:

NEW
  Devices
  must not fail when a disruption, such as a power failure or network
  interruption, occurs during the update process.
END

— Section 4.1 —

  -  The bootloader needs to fetch the manifest (or manifest-alike
      headers) from nonvolatile storage

What are “manifest-alike headers”?

      This allows to share
      information about the current firmware version

“Allows to share” doesn’t work in English: you need a subject, “allows  to share ”.  If you don’t have a subject, you can say “allows the sharing of information...”.

— Section 6 —

  A manifest may not only be used to protect firmware images but also
  configuration data such as network credentials

Similar to a comment above, this has “not only” misplaced:

NEW
  A manifest may be used to protect not only firmware images but also
  configuration data such as network credentials
END
2020-11-01
14 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-10-29
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Rich Salz
2020-10-29
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Rich Salz
2020-10-28
14 Martin Duke
[Ballot comment]
Thank you for engaging with the TSVART review.

I think Bob's criticism still holds that certain aspects of what is critical, vs. nice-to-have …
[Ballot comment]
Thank you for engaging with the TSVART review.

I think Bob's criticism still holds that certain aspects of what is critical, vs. nice-to-have are ambiguous.

For example, in Section 1:

"The firmware update process has to ensure that

  -  The firmware image is authenticated and integrity protected.
      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.

  -  The firmware image can be confidentiality protected so that
      attempts by an adversary to recover the plaintext binary can be
      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 the software libraries used,
      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."

The construction of this excerpt suggests that confidentiality is mandatory, but I gather from the thread that it is not.

If it is mandatory, than please change the second bullet to read "The firmware image is confidentiality protected..."

If it is not mandatory, I would just combine the first bullet and the opening clause, and make the second bullet an independent paragraph.
2020-10-28
14 Martin Duke Ballot comment text updated for Martin Duke
2020-10-28
14 Martin Duke
[Ballot comment]
Thank you for engaging with the TSVART review.

I think Bob's criticism that certain aspects of what is critical, vs. nice-to-have are ambiguous. …
[Ballot comment]
Thank you for engaging with the TSVART review.

I think Bob's criticism that certain aspects of what is critical, vs. nice-to-have are ambiguous.

For example, in Section 1:

"The firmware update process has to ensure that

  -  The firmware image is authenticated and integrity protected.
      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.

  -  The firmware image can be confidentiality protected so that
      attempts by an adversary to recover the plaintext binary can be
      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 the software libraries used,
      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."

The construction of this excerpt suggests that confidentiality is mandatory, but I gather from the thread that it is not.

If it is mandatory, than please change the second bullet to read "The firmware image is confidentiality protected..."

If it is not mandatory, I would just combine the first bullet and the opening clause, and make the second bullet an independent paragraph.
2020-10-28
14 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-10-23
14 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-10-22
14 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2020-10-22
14 Cindy Morgan Placed on agenda for telechat - 2020-11-05
2020-10-22
14 Roman Danyliw Ballot has been issued
2020-10-22
14 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-10-22
14 Roman Danyliw Created "Approve" ballot
2020-10-22
14 Roman Danyliw Ballot writeup was changed
2020-10-21
14 Brendan Moran New version available: draft-ietf-suit-architecture-14.txt
2020-10-21
14 (System) New version approved
2020-10-21
14 (System) Request for posting confirmation emailed to previous authors: Milosch Meriac , suit-chairs@ietf.org, David Brown , Brendan Moran , Hannes Tschofenig
2020-10-21
14 Brendan Moran Uploaded new revision
2020-10-20
13 Mohit Sethi Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Mohit Sethi. Sent review to list.
2020-10-16
13 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Mohit Sethi
2020-10-16
13 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Mohit Sethi
2020-10-16
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-16
13 Brendan Moran New version available: draft-ietf-suit-architecture-13.txt
2020-10-16
13 (System) New version approved
2020-10-16
13 (System) Request for posting confirmation emailed to previous authors: Milosch Meriac , suit-chairs@ietf.org, Brendan Moran , David Brown , Hannes Tschofenig
2020-10-16
13 Brendan Moran Uploaded new revision
2020-10-16
12 Éric Vyncke Requested Telechat review by IOTDIR
2020-09-17
12 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2020-09-17
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-09-17
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-09-17
12 Brendan Moran New version available: draft-ietf-suit-architecture-12.txt
2020-09-17
12 (System) New version approved
2020-09-17
12 (System) Request for posting confirmation emailed to previous authors: David Brown , Hannes Tschofenig , suit-chairs@ietf.org, Milosch Meriac , Brendan Moran
2020-09-17
12 Brendan Moran Uploaded new revision
2020-08-27
11 Rich Salz Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rich Salz. Sent review to list.
2020-08-19
11 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-08-14
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-08-12
11 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-08-12
11 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-suit-architecture-11, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-suit-architecture-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-08-09
11 Bob Briscoe Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Bob Briscoe. Sent review to list.
2020-08-09
11 Reese Enghardt Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Theresa Enghardt. Sent review to list.
2020-08-06
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2020-08-06
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2020-08-04
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2020-08-04
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2020-07-31
11 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2020-07-31
11 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2020-07-31
11 David Waltermire Added to session: IETF-108: suit  Fri-1100
2020-07-27
11 Wesley Eddy Request for Last Call review by TSVART is assigned to Bob Briscoe
2020-07-27
11 Wesley Eddy Request for Last Call review by TSVART is assigned to Bob Briscoe
2020-07-24
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-07-24
11 Amy Vezza
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-suit-architecture@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, Russ …
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-suit-architecture@ietf.org, housley@vigilsec.com, rdd@cert.org, suit-chairs@ietf.org, Russ Housley , suit@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Firmware Update Architecture for Internet of Things) to Informational RFC


The IESG has received a request from the Software Updates for Internet of
Things WG (suit) to consider the following document: - 'A Firmware Update
Architecture for Internet of Things'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Incorporating such update
  mechanism to fix vulnerabilities, to update configuration settings as
  well as adding new functionality is recommended by security experts.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/



No IPR declarations have been submitted directly on this I-D.




2020-07-24
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-07-24
11 Amy Vezza Last call announcement was changed
2020-07-24
11 Roman Danyliw Last call was requested
2020-07-24
11 Roman Danyliw Last call announcement was generated
2020-07-24
11 Roman Danyliw Ballot approval text was generated
2020-07-24
11 Roman Danyliw Ballot writeup was generated
2020-07-24
11 Roman Danyliw IESG state changed to Last Call Requested from Publication Requested
2020-07-24
11 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/suit/C4Az0vxz32FfwcOfdD_tTgPVNwU/
2020-06-09
11 Russ Housley
Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Firmware updates are needed to fix
  vulnerabilities in previous releases, update configuration settings,
  and add new functionality.  This document lists requirements for a
  firmware update mechanism suitable for IoT devices, and it describes
  an architecture that is agnostic to the transport of the firmware
  images and associated metadata.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Projects at the IETF Hackathon have informed this document.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SUIT WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is an unused Reference to 'I-D.ietf-suit-manifest'.  This can
  get resolved along with any IETF Last Call comments.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.
2020-06-09
11 Russ Housley Responsible AD changed to Roman Danyliw
2020-06-09
11 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-06-09
11 Russ Housley IESG state changed to Publication Requested from I-D Exists
2020-06-09
11 Russ Housley IESG process started in state Publication Requested
2020-06-09
11 Russ Housley
Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-suit-architecture-11


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  Vulnerabilities with Internet of Things (IoT) devices have raised the
  need for a solid and secure firmware update mechanism that is also
  suitable for constrained devices.  Firmware updates are needed to fix
  vulnerabilities in previous releases, update configuration settings,
  and add new functionality.  This document lists requirements for a
  firmware update mechanism suitable for IoT devices, and it describes
  an architecture that is agnostic to the transport of the firmware
  images and associated metadata.

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Projects at the IETF Hackathon have informed this document.
   
  Personnel:

  Russ Housley is the document shepherd.
  Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SUIT WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  There is an unused Reference to 'I-D.ietf-suit-manifest'.  This can
  get resolved along with any IETF Last Call comments.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.
2020-05-27
11 Hannes Tschofenig New version available: draft-ietf-suit-architecture-11.txt
2020-05-27
11 (System) New version approved
2020-05-27
11 (System) Request for posting confirmation emailed to previous authors: David Brown , Hannes Tschofenig , suit-chairs@ietf.org, Brendan Moran , Milosch Meriac
2020-05-27
11 Hannes Tschofenig Uploaded new revision
2020-05-27
10 Russ Housley Intended Status changed to Informational from None
2020-05-27
10 Russ Housley Changed consensus to Yes from Unknown
2020-05-27
10 Hannes Tschofenig New version available: draft-ietf-suit-architecture-10.txt
2020-05-27
10 (System) New version approved
2020-05-27
10 (System) Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Milosch Meriac , David Brown , Brendan Moran , Hannes Tschofenig
2020-05-27
10 Hannes Tschofenig Uploaded new revision
2020-05-26
09 David Waltermire Notification list changed to Russ Housley <housley@vigilsec.com>
2020-05-26
09 David Waltermire Document shepherd changed to Russ Housley
2020-05-22
09 Brendan Moran New version available: draft-ietf-suit-architecture-09.txt
2020-05-22
09 (System) New version approved
2020-05-22
09 (System) Request for posting confirmation emailed to previous authors: David Brown , Brendan Moran , Hannes Tschofenig , suit-chairs@ietf.org, Milosch Meriac
2020-05-22
09 Brendan Moran Uploaded new revision
2020-05-22
08 (System) Document has expired
2020-02-19
08 Dave Thaler Added to session: interim-2020-suit-01
2019-12-04
08 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-11-19
08 Hannes Tschofenig New version available: draft-ietf-suit-architecture-08.txt
2019-11-19
08 (System) New version accepted (logged-in submitter: Hannes Tschofenig)
2019-11-19
08 Hannes Tschofenig Uploaded new revision
2019-11-17
07 David Waltermire Added to session: IETF-106: suit  Tue-1330
2019-10-21
07 Hannes Tschofenig New version available: draft-ietf-suit-architecture-07.txt
2019-10-21
07 (System) New version approved
2019-10-20
07 (System) Request for posting confirmation emailed to previous authors: Hannes Tschofenig , Milosch Meriac , David Brown , Brendan Moran
2019-10-20
07 Hannes Tschofenig Uploaded new revision
2019-09-13
06 Hannes Tschofenig New version available: draft-ietf-suit-architecture-06.txt
2019-09-13
06 (System) New version approved
2019-09-13
06 (System) Request for posting confirmation emailed to previous authors: Hannes Tschofenig , Milosch Meriac , David Brown , Brendan Moran
2019-09-13
06 Hannes Tschofenig Uploaded new revision
2019-07-12
05 Russ Housley Added to session: IETF-105: suit  Wed-1000
2019-04-09
05 Hannes Tschofenig New version available: draft-ietf-suit-architecture-05.txt
2019-04-09
05 (System) New version approved
2019-04-09
05 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , suit-chairs@ietf.org, Milosch Meriac , David Brown , Hannes Tschofenig
2019-04-09
05 Hannes Tschofenig Uploaded new revision
2019-03-27
04 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2019-03-27
04 Hannes Tschofenig New version available: draft-ietf-suit-architecture-04.txt
2019-03-27
04 (System) New version approved
2019-03-27
04 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , suit-chairs@ietf.org, Milosch Meriac , David Brown , Hannes Tschofenig
2019-03-27
04 Hannes Tschofenig Uploaded new revision
2019-03-11
03 Hannes Tschofenig New version available: draft-ietf-suit-architecture-03.txt
2019-03-11
03 (System) New version approved
2019-03-11
03 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , suit-chairs@ietf.org, Milosch Meriac , David Brown , Hannes Tschofenig
2019-03-11
03 Hannes Tschofenig Uploaded new revision
2019-03-04
02 Dave Thaler Added to session: IETF-104: suit  Wed-0900
2019-01-16
02 Hannes Tschofenig New version available: draft-ietf-suit-architecture-02.txt
2019-01-16
02 (System) New version approved
2019-01-16
02 (System) Request for posting confirmation emailed to previous authors: Brendan Moran , suit-chairs@ietf.org, Milosch Meriac , David Brown , Hannes Tschofenig
2019-01-16
02 Hannes Tschofenig Uploaded new revision
2019-01-03
01 (System) Document has expired
2018-11-04
01 Dave Thaler Added to session: IETF-103: suit  Thu-0900
2018-07-17
01 Dave Thaler Added to session: IETF-102: suit  Wed-0930
2018-07-02
01 Hannes Tschofenig New version available: draft-ietf-suit-architecture-01.txt
2018-07-02
01 (System) New version approved
2018-07-02
01 (System) Request for posting confirmation emailed to previous authors: suit-chairs@ietf.org, Milosch Meriac , Brendan Moran , Hannes Tschofenig
2018-07-02
01 Hannes Tschofenig Uploaded new revision
2018-06-15
00 Russ Housley Added to session: interim-2018-suit-03
2018-06-03
00 Dave Thaler This document now replaces draft-moran-suit-architecture instead of None
2018-06-03
00 Hannes Tschofenig New version available: draft-ietf-suit-architecture-00.txt
2018-06-03
00 (System) WG -00 approved
2018-06-03
00 Hannes Tschofenig Set submitter to "Hannes Tschofenig ", replaces to draft-moran-suit-architecture and sent approval email to group chairs: suit-chairs@ietf.org
2018-06-03
00 Hannes Tschofenig Uploaded new revision