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 32) | |
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 | https://mailarchive.ietf.org/arch/msg/gen-art/grxiGvlgNCbtIJUTQ3Zx1p-Bp7M | |
Reviewed revision | 25 (document currently at 32) | |
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