Skip to main content

Last Call Review of draft-ietf-suit-manifest-25

Request Review of draft-ietf-suit-manifest
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-02-21
Requested 2024-02-07
Authors Brendan Moran , Hannes Tschofenig , Henk Birkholz , Koen Zandberg , Øyvind Rønningstad
I-D last updated 2024-02-18
Completed reviews Genart Last Call review of -25 by Dan Romascanu (diff)
Opsdir Last Call review of -25 by Tianran Zhou (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-suit-manifest by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 25 (document currently at 26)
Result Ready w/nits
Completed 2024-02-18
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-suit-manifest-25
Reviewer: Dan Romascanu
Review Date: 2024-02-18
IETF LC End Date: 2024-02-21
IESG Telechat date: Not scheduled for a telechat


This standards track document describes the format of a manifest, i.e. a bundle
of metadata about code/data obtained by a recipient (chiefly the firmware for
an IoT device), where to find the code/data, the devices to which it applies,
and cryptographic information protecting the manifest. Understanding the SUIT
architecture and reading RFC 9019 and RFC 9124 are required.

This is a detailed, very clear and complete specification. It is READY.A few
editorial comments are mentioned below - no show-stoppers but good to consider
for more clarity.

Major issues:


Minor issues:


Nits/editorial comments:

1. Terms to add to Section 2. - Terminology:

- Bootloader
- Message Authentication Code (MAC)
- Access Control List (ACL)
- Concise Binary Object Representation (CBOR)
- CBOR Object Signing and Encryption (COSE)

2. Section 4.2:

Two instances of:

> Compatibility must be checked before any other operation is

What kind of compatibility? Should be more precise in each case.

3.Section 6.1

> These failure reasons MAY be combined with retry mechanisms prior to
   marking a manifest as invalid.

What kind of 'retry mechanisms' are considered here?

4. Section 7

>   NOTE: *A digest MUST always be set using Override Parameters.*

There is something odd about a MUST requirement being included in a NOTE.

5.It is not clear to me what is the intent and difference between leaving
entries undefined (as mentioned in Table 10, Table 11) and defining some
entries as Reserved (as in Table 12, Table 13)

6. Appendix A contains two capitalized MUST statements. This should be
mentioned some place, in order to make clear (if this is the case) that this
Appendix is part of the normative text of the document