Section 1:
- This section has the title "Introduction" yet it is normative. It may be better to have a short intro section which is not normative and then a separate section that provides the introductory requirements. Or aLternatively, make it explicit that the section is normative.
- "SUIT will define five choices of Mandatory To Implement (MTI) profile [sic] specifically for constrained node software update. These profiles are:
One Symmetric MTI profile
Two "Current" Constrained Asymmetric MTI profiles
Two "Current" AEAD Asymmetric MTI profiles
One "Future" Constrained Asymmetric MTI profile"

- This seems to be six profiles, not five?
- Would be good to clarify here or elsewhere what "Current" and "Future" means

"At least one MTI algorithm in each category MUST be FIPS qualified"

-  What does "qualified" mean? Not defined.

"Recipients MAY choose which MTI profile they wish to implement...Recipients MAY implement any number of other profiles"

- Given the second statement, the first statement seems to incorrectly imply they can only implement one.
- As written, a recipient would be compliant not implement any profile. Therefore, it may be good to modify this to:
"Recipients MUST implement at least one MTI profile." - This makes it clear they have to, but it also allows them to choose, and the second sentence above can be removed.

"This specification makes use of AES-CTR with a digest algorithm in COSE as specified in ([RFC9459]). AES-CTR is used because it enables out-of-order reception and decryption of blocks, which is necessary for some constrained node use cases. Out-of-order reception with on-the-fly decryption is not available in the preferred encryption algorithms.

- What is COSE? Acronym introduced w/o explanation.
- "on-the-fly" decryption is not defined
- "preferred" crypto algorithms is not defined.

Section 2.

"Key Exchange Algorithms (OPTIONAL)
 Encryption Algorithms (OPTIONAL)"

- Why does a draft with the title "Mandatory to Implement Algorithms" care to introduce OPTIONAL algorithms? Also does this mean that the statement in Section 1 about not implementing encryption algorithms (see below as well) extends to key exchange algorithms?

Section 3.

- What does "recognized" mean? Not defined.

Section 3.6

"deep trees are RECOMMENDED" 

- "deep" is not defined. If defined elsewhere, please provide references.

Section 4.

- "Manifest Recipients Response" is not defined. Please provide reference.
- "closest equivalent" is ambiguous. Needs a definition.

Section 5 and Section 5.1

"payload encryption of firmware or software updates of a commodity device is not a cybersecurity defense against targetted [sic] attacks on that device"

- Section 5.1 does talk about how attackers may find bugs by code inspection. If the payload of a firmware update is not encrypted, they could use that to find bugs in the updated code. Thus, encryption of firmware updates may also serve as a security defense, contradicting the quote above.

Section 5.2

"Out-of-order decryption must be supported"

- Supported by whom? Does this not contradict both the statement in Section 1 that "Recipients MAY choose not to implement an encryption algorithm if encrypted payloads will never be used"? (BTW, how would a recipient know that encrypted payloads never will be used?)
- Why is this "must" non-normative?

"the payloads are typically constructed in a relatively secure environment--the developer's computer"

- Please remove the latter part of this statement. There are an enormous number of incidents that have occurred due to attackers being able to access a developer's computer ...

"In short, the plaintext is authenticated prior to encryption"

- Also incorrect, it is not authenticated. It may be trusted, but not authenticated.

"Content Encryption Keys must be used to encrypt only once."

- Is this a new requirement? If so, why the non-normative "must"?

Thanks,
M

"AES-CTR is an acceptable cipher"

Was this meant to say "AES-CTR without AEAD is an acceptable cipher mode"?