Skip to main content

Last Call Review of draft-ietf-suit-manifest-25
review-ietf-suit-manifest-25-genart-lc-romascanu-2024-02-18-00

Request Review of draft-ietf-suit-manifest
Requested revision No specific revision (document currently at 25)
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
Opsdir Last Call review of -25 by Tianran Zhou
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 https://mailarchive.ietf.org/arch/msg/gen-art/grxiGvlgNCbtIJUTQ3Zx1p-Bp7M
Reviewed revision 25
Result Ready w/nits
Completed 2024-02-18
review-ietf-suit-manifest-25-genart-lc-romascanu-2024-02-18-00
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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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

Summary:

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:

None

Minor issues:

None

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)
- CDDL

2. Section 4.2:

Two instances of:

> Compatibility must be checked before any other operation is
      performed.

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