[Suit] draft-ietf-suit-update-management-10 ietf last call Artart review

Russ Housley via Datatracker <noreply@ietf.org> Thu, 18 December 2025 18:04 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley via Datatracker <noreply@ietf.org>
To: art@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176608107385.1115878.2297151190399470038@dt-datatracker-5bd94c585b-pvtsm>
Date: Thu, 18 Dec 2025 10:04:33 -0800
Message-ID-Hash: HEI335XSOHJIMPR7FGGAE23YWUSSWRRR
CC: draft-ietf-suit-update-management.all@ietf.org, last-call@ietf.org, suit@ietf.org
Reply-To: Russ Housley <housley@vigilsec.com>
Subject: [Suit] draft-ietf-suit-update-management-10 ietf last call Artart review
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/iKT6Qlw5Ww2LPK99Okg5aiOgAB4>

Document: draft-ietf-suit-update-management
Title: Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests
Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ART-ART reviewer for this draft. Please treat these
comments just like any other last call comments.


Document: draft-ietf-suit-update-management-10
Reviewer: Russ Housley
Review Date: 2025-12-18
IETF LC End Date: 2026-01-02
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 4.4.1: Versions numbers follow [sember], but this sections
imposes an additional requirement that the release version be a
sequence of 1 to 3 positive integers.  [semver] allows zero for the
major, minor, and patch numbers:

   <version core> ::= <major> "." <minor> "." <patch>

   <major> ::= <numeric identifier>

   <minor> ::= <numeric identifier>

   <patch> ::= <numeric identifier>

   <numeric identifier> ::= "0"
                       | <positive digit>
                       | <positive digit> <digits>

Sections 4.6 and 5.1: These use "must" in statements about a parameter
already being set. I think these statement ought to use MUST.


Minor Concerns:

Section 3.2 says:

   However, Recipients MUST NOT fail if a suit-coswid is present.

This statement contradicts the requirements in Section 1, where it states
that all of the extensions in this specification are OPTIONAL, and that a
Recipient that encounters a command or parameter it does not implement
MUST reject the manifest. This MUST statement requires all implementations
to recognize suit-coswid, so it is not OPTIONAL.


Nits:

Section 1:
s/Software Bill of Materials/Software Bill of Materials (SBOM)/

Section 1:
s/[I-D.ietf-suit-manifest] Section 8.4.2/Section 8.4.2 of [I-D.ietf-suit-manifest]/

Section 3.2:
s/Software Bill of Materials/Software Bill of Materials (SBOM)/

Section 4.6:
s/sections 8.4.10.4, 8.4.10.5, 8.4.10.6/Sections 8.4.10.4, 8.4.10.5, and 8.4.10.6/

[Suit] draft-ietf-suit-update-management-10 ietf … Russ Housley via Datatracker