Secure Reporting of SUIT Update Status
draft-ietf-suit-report-20

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.

** Section 9.2
  *  Specifications are required for the standards track range of point
      assignment.  Specifications should exist for all other ranges, but
      early assignment before a specification is available is considered
      to be permissible.  When specifications are not provided, the
      description provided needs to have sufficient information to
      identify what the point is being used for.
  *  Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      standards track documents does not mean that a standards track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, the size of device it will be
      used on, and the number of code points left that encode to that
      size.

There are three ranges with different allocation policies, but this technically only applies to one of the (the specification required range)
  *  -256 to 255: Standards Action
  *  -65536 to 257, 256 to 65535: Specification Required
  *  -4294967296 to -65537, 65536 to 4294967295: First Come, First
      Served

-- standards action doesn’t require review by the designated expert

-- FCFS does not involve any substantive review of the request (and doesn’t involve an expert)

** Section 9.5 
-- What is the role of the 5th column in the registry? It is unlabeled and only value 99 has a value?

-- what does “suit-reference” as the Reference for value 99 mean?

** Section 9.5, 9.6, 9.7 and 9.8.  Should the reference value noted for the Reference column in these registries be more than a section number? Shouldn’t it be a section number and the future RFC?  How will reference to just a section without no RFC be easily discoverable?

[Ballot comment]
Hi Brendan and Henk,

Thank you for the changes made in -16 [1]. These address my DISCUSS/COMMENT points [2].

One very minor comment, it seems this one didn't make it to the published version per [3]:

----
>
> # Consistent patterns for reason code:
>
> CURRENT:
>    *  suit-report-reason-component-unauthorised: The manifest declared a
>      component that is not accessible by the signer.
>
>    *  suit-report-reason-parameter-unsupported: The manifest used a
>      parameter that does not exist.
>
>    *  suit-report-severing-unsupported: The manifest uses severable
>      fields but the Manifest Processor doesn't support them.
>
> Any reason the code=9/suit-report-severing-unsupported does not have the same
> pattern as other reasons?

Fixed.
---------------

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-suit-report-15&url2=draft-ietf-suit-report-16&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/suit/1OO8p0hH5hS_gokAvGCpu64lqmk/

[3] https://mailarchive.ietf.org/arch/msg/suit/7b3JyoLek7B8BM6SVWbLiVsk6to/

[Ballot comment]
Hi Brendan and Henk,

Thank you for the changes made in -16 [1]. These address my DISCUSS/COMMENT points [2].

One very minor comment, it seems this was one didn't make it to the published version per [3]:

----
>
> # Consistent patterns for reason code:
>
> CURRENT:
>    *  suit-report-reason-component-unauthorised: The manifest declared a
>      component that is not accessible by the signer.
>
>    *  suit-report-reason-parameter-unsupported: The manifest used a
>      parameter that does not exist.
>
>    *  suit-report-severing-unsupported: The manifest uses severable
>      fields but the Manifest Processor doesn't support them.
>
> Any reason the code=9/suit-report-severing-unsupported does not have the same
> pattern as other reasons?

Fixed.
---------------

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-suit-report-15&url2=draft-ietf-suit-report-16&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/suit/1OO8p0hH5hS_gokAvGCpu64lqmk/

[3] https://mailarchive.ietf.org/arch/msg/suit/7b3JyoLek7B8BM6SVWbLiVsk6to/

[Ballot comment]
I agree with the missing normative references Med pointed out, and would also like to see the discussion on Informational vs Proposed Standard that Ketan raised.

[Ballot comment]
Overall, the document seems in good shape. I think some rearrangement of the IANA Considerations would make them easier to parse -- add links to the registries that already exist, move the request to create new registries into the sections with their definitions, etc. The top-level discussion in Section 9 should be either instructions that apply to many of the registries listed (e.g. creation of a group) or a preview of what is done in detail in the subsections (ideally with forward-references).

I support the DISCUSS about intended status, but that seems like a simple fix.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-suit-report-15
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Jacqueline McCall for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status (it also uses the old template but this is not critical).

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3

Please add a normative reference to the syntax used in the "code" describing the data structure *before* the first code, CDDL is only cited (and no reference given) at the 3rd 'code'.

[Ballot comment]

## COMMENTS (non-blocking)

### Wrong intended status in the I-D

I second Ketan's DISCUSS on this point.

### Abstract & Section 1

Suggest adding a reference to the RFC about SUIT manifest.

Depending on the intended publication status, `This specification describes` should rather be 'This document specifies' or 'This document describes'.

### Section 1

Please expand SUIT again (the abstract expansion is just for the abstract).

Should the term 'developper' be defined in this context ?

### Section 4

Suggest appending SUIT_Reference below SUIT_Report as the text in between breaks the flow.

The paragraph about suit-report-nonce  is also out of flow, it should appear earlier.

Suggest that this section contains forward reference to where suit-report-records (and possibly other fields) are specified.

### Section 9

Is it just a rename operation or a registry creation request in `IANA is requested to name the overall SUIT registry group` ?

Strongly suggest to add reference (URI) to all existing IANA registries.

Suggest adding forward reference to subsections in the list following `IANA is also requested to add the following registries to the SUIT registry group`.

### Section 9.2

Missing text to request IANA to add this media type.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I have an important point to DISCUSS. The data-tracker identifies this document as being on Standards Track. The content (to my understanding) also seems to warrant a PS. However, the document itself carries the informational as the intended status.

Workgroup:SUIT
Internet-Draft:draft-ietf-suit-report-15
Published:8 September 2025
Intended Status:Informational
Expires:12 March 2026
Authors:
B. Moran
Arm Limited
H. Birkholz
Fraunhofer SIT

I'll note that the IETF LC did call this out as PS but I haven't looked to see if the WG considered it as a PS. I will leave this to the responsible AD - it might just be as simple as fixing the status within the document to PS.

[Ballot comment]
I support many of the DISCUSS points from Med about normative references and text as I got the same impression (disclaimer: not a expert in this area).

[Ballot discuss]
Hi Brendan and Henk,

Thank you for the effort put into this specification.

Please find below some DISCUSS points (most are easy-to-fix).

# URI spec is normative

CURRENT:
  The URI MUST be the canonical URI that is provided in the
  manifest. 

Consider adding a normative reference to RFC3986

# CDDL is normative

CURRENT:
  The following CDDL describes a SUIT_Reference.

CDDL is normative please cite 8610.

# SUIT_Report_Records

Failed to find where this is defined (here, draft-ietf-suit-manifest, draft-ietf-suit-mti, etc.).

# SUIT_Manifest_Envelope

CURRENT:
  Remote attestation is done by using the
  SUIT_Manifest_Envelope along with the SUIT_Report in Evidence to
  reconstruct the state of the device at boot time. 

I failed to find where this is defined (here, draft-ietf-suit-manifest, draft-ietf-suit-mti, etc.). Can we please check this?

# Dependency on CoRIM

CURRENT:
  When a Concise Reference Integrity Manifest (CoRIM, see
  [I-D.birkholz-rats-corim]) is delivered in a SUIT_Manifest_Envelope,
  this codifies the delivery of appraisal information to the Verifier:

The verification process indicated in the text and description right after requires digesting CoRIM. This text and following one semes to define a normative behavior.

# Unfoldding the normative CDDL requires 8792

CURRENT:
  To be valid, the following CDDL MUST have the COSE CDDL appended to
  it.  The COSE CDDL can be obtained by following the directions in
  [RFC9052], Section 1.4.  It must also have the CDDL from
  [I-D.ietf-suit-mti] appended to it.

  =============== NOTE: '\' line wrapping per RFC 8792 ================

  SUIT_Report_Tool_Tweak /= SUIT_start
  SUIT_Report_Tool_Tweak /= SUIT_Report_Protected
  SUIT_Report_Protected /= SUIT_COSE_tool_tweak

Please add a normative reference to RFC 8792.

[Ballot comment]
# Confusion about indicated Intended Status

The Datatracker metadata has the status right, but the document itself needs to be fixed

CURRENT:
  SUIT                                                            B. Moran
  Internet-Draft                                              Arm Limited
  Intended status: Informational                              H. Birkholz
  Expires: 12 March 2026                                    Fraunhofer SIT
                                                        8 September 2025
# Please consider updating the title to include SUIT.

The current title is too generic.

# Terminology

## Please consider adding

NEW:
  The terms "Author", "Recipient", and "Manifest" are defined in Section 2 of [I-D.ietf-suit-manifest].

## nit: only one term is listed

CURRENT: Terms used in this specification include:

Unless you add other terms, please fix that to align with the listed terms.

## Consider adding a definition for “manifest section” or at least point to where this defined.

# Need for consent?

CURRENT:
  Since it is possible that a non-condition command (directive) may
  fail in an exceptional circumstance, a failure code for a non
  condition command must be communicated to the developer. 

Should there be a need to gate this with some user consent?

# manifest-id?

CURRENT:
  A manifest-id of [1,0] would indicate that the current command was
  contained within Dependency BA.  Similarly, a manifest-id of [2,1]
  would indicate Dependency CB

Shouldn’t this be “suit-record-manifest-id”?

# Help readers find where to look at

OLD:
  This is encoded in a
  SUIT_Parameters block as defined in [I-D.ietf-suit-manifest].

NEW:
  This is encoded in a
  SUIT_Parameters block as defined in Section 8.4.8 of [I-D.ietf-suit-manifest].

Please consider a similar change for other similar constructs in the spec.

# Consistent patterns for reason code:

CURRENT:
  *  suit-report-reason-component-unauthorised: The manifest declared a
      component that is not accessible by the signer.

  *  suit-report-reason-parameter-unsupported: The manifest used a
      parameter that does not exist.

  *  suit-report-severing-unsupported: The manifest uses severable
      fields but the Manifest Processor doesn't support them.

Any reason the code=9/suit-report-severing-unsupported does not have the same pattern as other reasons?

# SUIT Information Model

CURRENT:
  The SUIT_Report MUST be transported using one of the following
  methods:

How that is related to the reporting requirement in RFC9124? Can that be clarified in the document?

# IANA entries and CDDL

It would be helfpul if the CDDL label is also included in the tables for each registered entry.

Cheers,
Med

Issues with the CoAP Content-Formats registration: The proposed registration in Section 9.3 can't be approved in current form: it would need some updates.

My proposed updates are:

1. change "sub-registry" -> "registry" (to use correct terminology - the registry is part of the CoRE Parameters registry group)
2. ""IETF Review or IESG Approval" space (256..999) -> change to ""IETF Review with Expert Review or IESG Approval with Expert Review" range (256..9999)"
3. Column headers/values of Table 1 corrected as below:

  Content Type : application/suit-report+cose
  Content Coding: (empty field)

  (FYI: the Content Coding field is usually empty, expect when an HTTP Content Coding like "gzip" or "deflate" is applied.)

4. And in Section 9:  "a CoAP content-type" -> "a CoAP content-format"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-suit-report-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are seven actions which we must complete.

First, in the CBOR Tags registry in the Concise Binary Object Representation (CBOR) Tags registry group located at:

https://www.iana.org/assignments/cbor-tags/

three new registrations will be made in the Specification Required range as follows:

Tag: [ TBD-at-Registration ]
Data Item: array
Semantics: SUIT_Report_Protected
Reference: [ RFC-to-be ]
Template:

Tag: [ TBD-at-Registration ]
Data Item: map
Semantics: SUIT_Reference
Reference: [ RFC-to-be ]
Template:

Tag: [ TBD-at-Registration ]
Data Item: map
Semantics: SUIT_Capability_Report
Reference: [ RFC-to-be ]
Template:

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new registration will be made as follows:

Name: suit-report+cose
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Third, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Content Type: CoSWID
Content Coding: cbor+cose
Media Type: application/suit-report+cose
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, a new registry is to be created called the SUIT_Report Elements registry. The new registry will be located in the Software Update for the Internet of Things (SUIT) registry group located at:

https://www.iana.org/assignments/suit/

The new registry will be managed via the registration policy below:

-256 to 255: Standards Action
-65536 to 257, 256 to 65535: Specification Required
-4294967296 to -65537, 65536 to 4294967295: First Come, First Served

There are initial registrations in the new registry as follows:

Label Name Reference
-----+-----+-----------
2 Nonce [ RFC-to-be; Section 4 ]
3 Records [ RFC-to-be; Section 4 ]
4 Result [ RFC-to-be; Section 4 ]
5 Result Code [ RFC-to-be; Section 4 ]
6 Result Record [ RFC-to-be; Section 4 ]
7 Result Reason [ RFC-to-be; Section 4 ]
8 Capability Report [ RFC-to-be; Section 4 ]
99 Reference [ RFC-to-be; Section 4 ]

Fifth, a new registry is to be created called the SUIT_Record Elements registry. The new registry will be located in the Software Update for the Internet of Things (SUIT) registry group located at:

https://www.iana.org/assignments/suit/

The new registry will be managed via the registration policy below:

-256 to 255: Standards Action
-65536 to 257, 256 to 65535: Specification Required
-4294967296 to -65537, 65536 to 4294967295: First Come, First Served

There are initial registrations in the new registry as follows:

Label Name Reference
-----+-----+-----------
0 Manifest ID [ RFC-to-be; Section 3 ]
1 Manifest Section [ RFC-to-be; Section 3 ]
2 Section Offset [ RFC-to-be; Section 3 ]
3 Component Index [ RFC-to-be; Section 3 ]
4 Dependency Index [ RFC-to-be; Section 3 ]
5 Record Properties [ RFC-to-be; Section 3 ]

Sixth, a new registry is to be created called the SUIT_Report Reasons registry. The new registry will be located in the Software Update for the Internet of Things (SUIT) registry group located at:

https://www.iana.org/assignments/suit/

The new registry will be managed via the registration policy below:

-256 to 255: Standards Action
-65536 to 257, 256 to 65535: Specification Required
-4294967296 to -65537, 65536 to 4294967295: First Come, First Served

There are initial registrations in the new registry as follows:

Label Name Reference
-----+-----+-----------
0 Result OK [ RFC-to-be; Section 4.2 ]
1 CBOR Parse Failure [ RFC-to-be; Section 4.2 ]
2 Unsupported COSE Structure or Header [ RFC-to-be; Section 4.2 ]
3 Unsupported COSE Algorithm [ RFC-to-be; Section 4.2 ]
4 Signature / MAC verification failed [ RFC-to-be; Section 4.2 ]
5 Unsupported SUIT Command [ RFC-to-be; Section 4.2 ]
6 Unsupported SUIT Component [ RFC-to-be; Section 4.2 ]
7 Unauthorized SUIT Component [ RFC-to-be; Section 4.2 ]
8 Unsupported SUIT Parameter [ RFC-to-be; Section 4.2 ]
9 Severing Unsupported [ RFC-to-be; Section 4.2 ]
10 Condition Failed [ RFC-to-be; Section 4.2 ]
11 Operation Failed [ RFC-to-be; Section 4.2 ]

Seventh, a new registry is to be created called the SUIT Capability Report Elements registry. The new registry will be located in the Software Update for the Internet of Things (SUIT) registry group located at:

https://www.iana.org/assignments/suit/

The new registry will be managed via the registration policy below:

-256 to 255: Standards Action
-65536 to 257, 256 to 65535: Specification Required
-4294967296 to -65537, 65536 to 4294967295: First Come, First Served

There are initial registrations in the new registry as follows:

Label Name Reference
-----+-----+-----------
1 Components [ RFC-to-be; Section 6 ]
2 Commands [ RFC-to-be; Section 6 ]
3 Parameters [ RFC-to-be; Section 6 ]
4 Cryptographic Algorithms [ RFC-to-be; Section 6 ]
5 Envelope Elements [ RFC-to-be; Section 6 ]
6 Manifest Elements [ RFC-to-be; Section 6 ]
7 Common Elements [ RFC-to-be; Section 6 ]
8 Text Elements [ RFC-to-be; Section 6 ]
9 Component Text Elements [ RFC-to-be; Section 6 ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-08-11):

From: The IESG
To: IETF-Announce
CC: akira.tsukamoto@gmail.com, debcooley1@gmail.com, draft-ietf-suit-report@ietf.org, jacqui.ietf@gmail.com, suit-chairs@ietf.org, suit@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Secure Reporting of Update Status) to Proposed Standard


The IESG has received a request from the Software Updates for Internet of
Things WG (suit) to consider the following document: - 'Secure Reporting of
Update Status'
  as Proposed Standard

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 2025-08-11. 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


  The Software Update for the Internet of Things (SUIT) manifest
  provides a way for many different update and boot workflows to be
  described by a common format.  This specification describes a
  lightweight feedback mechanism that allows a developer in possession
  of a manifest to reconstruct the decisions made and actions performed
  by a manifest processor.




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



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

# Document Shepherd Write-Up for Group Documents

## Document History

Shepherd Write-up for draft-ietf-suit-report-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?

  Proposed Standard as indicated on datatracker. The header calls for standards track.


(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:

  The Software Update for the Internet of Things (SUIT) manifest
  provides a way for many different update and boot workflows to be
  described by a common format. This specification describes a lightweight feedback mechanism that
  allows a developer in possession of a manifest to reconstruct the
  decisions made and actions performed by a manifest processor. 

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Interest has been shown in implementing this specification.
   
  Personnel:

  Jacqui McCall is the document shepherd.
  Deb Cooley 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 review of the document, as well as checked to make sure all issues raised were actioned.

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


(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?

No IPR disclosures


(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 have been filed.

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

 
  The shepherd is unaware of any issues.

(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 are 11 instances of too long lines in the document, the longest
one being 9 characters in excess of 72.

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

  No formal reviews 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.

  No

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

  Section 9 describes a new registry to be created by IANA


(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 Expert Review registries are talked about in this document.

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

  Not needed.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

Shepherd Write-up for draft-ietf-suit-report-10


(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?

  Proposed Standard as indicated on datatracker. This document is informational in nature.


(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:

  The Software Update for the Internet of Things (SUIT) manifest
  provides a way for many different update and boot workflows to be
  described by a common format. This specification describes a lightweight feedback mechanism that
  allows a developer in possession of a manifest to reconstruct the
  decisions made and actions performed by a manifest processor. 

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Interest has been shown in implementing this specification.
   
  Personnel:

  Jacqui McCall is the document shepherd.
  Deb Cooley 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 review of the document, as well as checked to make sure all issues raised were actioned.

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


(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?

No IPR disclosures


(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 have been filed.

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

 
  The shepherd is unaware of any issues.

(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 are 11 instances of too long lines in the document, the longest
one being 9 characters in excess of 72.

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

  No formal reviews 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.

  No

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

  Section 9 describes a new registry to be created by IANA


(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 Expert Review registries are talked about in this document.

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

  Not needed.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

Shepherd Write-up for draft-ietf-suit-report-10


(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?

  Proposed Standard as indicated on datatracker. This document is informational in nature.


(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:

  The Software Update for the Internet of Things (SUIT) manifest
  provides a way for many different update and boot workflows to be
  described by a common format. This specification describes a lightweight feedback mechanism that
  allows a developer in possession of a manifest to reconstruct the
  decisions made and actions performed by a manifest processor. 

  Working Group Summary:

  There is consensus for this document in the SUIT WG.

  Document Quality:

  Interest has been shown in implementing this specification.
   
  Personnel:

  Jacqui McCall is the document shepherd.
  Deb Cooley 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 review of the document, as well as checked to make sure all issues raised were actioned.

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


(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?

No IPR disclosures


(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 have been filed.

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

 
  The shepherd is unaware of any issues.

(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 are 11 instances of too long lines in the document, the longest
one being 9 characters in excess of 72.

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

  No formal reviews 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.

  No

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

  Section 9 describes a new registry to be created by IANA


(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 Expert Review registries are talked about in this document.

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

  Not needed.