From an IoT perspective, this document is on the right track.

Some notes below.

# Examples

Examples and CDDL need some attention - mostly on syntax and alignment with SUIT grammar.

Earlier this month, Ken and I have been exchanging messages on the topic.  IIRC, he has fixed the identified issues in his local copy.

Example 0 references a dependent manifest, but this reader couldn't find it. For completeness, I suggest adding it.

# Scope

It'd be good to clarify what kinds of devices this spec targets. 

Most likely these are relatively sophisticated gizmos, requiring firmware images for multiple subsystems and separate applications, thus relying on a complex supply chain.

So, the mention of class[0-2] devices in Section 2:
```
Firmware: Software that is typically changed infrequently, stored
      in nonvolatile memory, and small enough to apply to [RFC7228]
      Class 0-2 devices.
```
got me thinking, as the functionality seems more naturally applicable to Class2+?

So, you could add a few lines in the intro to better define the intended device "audience."

Besides, I suggest looking at I-D.ietf-iotops-7228bis, which contains an updated (10 years later) view of the IoT world, with more meaningful categorisation.

# Mechanics

The mechanics of dependency handling are quite clearly explained.  My initial difficulty was continuous jumping back and forth between this document and the SUIT manifest draft, but after memory mapping a few relevant bits of SUIT, one can follow the logic.  Again, it's been a slightly tricky journey for a SUIT neophyte like me, but I guess it's reasonable to assume an implementer has sound knowledge of SUIT before embarking on this spec.

Since there are a few new commands and some tweaks to existing ones, I guess eventually you'll need to explicitly tag it with "Updates: RFC-SUIT" (or the newer "Extends" tag).