Title. 
- Some algorithms (profiles) are intended to be mandatory. Why not just remove "recommendations"?

1. Introduction
-	"This document defines algorithm profiles for SUIT manifest parsers and authors to promote interoperability in constrained node software update scenarios. These profiles specify sets of mandatory-to-implement (MTI) algorithms tailored to the evolving security landscape, acknowledging that cryptographic requirements may change over time. To accommodate this, algorithms are grouped into profiles, which may be updated or deprecated as needed."
a)	Why "parsers and authors" and not "authors and recipients" or only "parsers"? Why are not recipients mentioned here when they are elsewhere in the doc? Also, AFAICT, this is the only mention of the term “parsers.”
b)	Not all profiles are MTI.
c)	It is odd to only in the last sentence describe the profiles' purpose. Instead, I suggest something like:
"To promote interoperability in constrained node software update scenarios, this document defines cryptographic algorithms for SUIT manifest authors and recipients. To accommodate an evolving security landscape where cryptographic requirements may change over time, algorithms are grouped into profiles, which may be updated or deprecated as needed.”

-	Since not all profiles are MTI – in fact, no single profile is MTI since recipients can choose (Section 3: “Recipients MAY choose…”), it seems better not to call them MTI profiles and instead just call them profiles, e.g. “One symmetric profile.”
-	See comment below on the use of “Current” and “Future.”
-	I still don’t understand what “FIPS validated” means. Did you intend to say that the implementation of the algorithm must be FIPS certified in accordance with FIPS 140-3? Or something else?

3. Profiles
-	My comment on the use of the “MTI profile” term is as above. Suggest removing “MTI.”
-	“Recipients MAY choose not to implement encryption and the corresponding key exchange algorithms if they do not intend to support encrypted payloads. … Authors MUST implement all MTI profiles.” - I still fail to understand how interoperability will be achieved if recipients only support a single profile. Are authors able to learn, through some other mechanism, what profile a given recipient support? It seems easier if the requirements were the other way around, i.e., recipients support all profiles since then, regardless of what profile an author uses, the recipient will be able to validate (and possibly decrypt) the message. 

-	I suggest removing “Current” as a prefix for those profiles that use it and replace “Future” with “Post-quantum” for those profiles that use that term since:
a)	What is considered “current” and “future” varies over time
b)	Post-quantum is what it appears that you refer to with the use of “future.”
This would also suggest updating the corresponding sentence in Section 1.

5. Security Considerations
-	“The primary function of payload in SUIT is to act as a defense against passive IP and PII snooping. By encrypting payloads, confidential IP and PII can be protected during distribution. However, payload encryption of firmware or software updates of a commodity device is not a cybersecurity defense against targetted attacks on that device.”
a)	The acronyms “IP” and “PII” have not been explained
b)	(nit) “targetted” -> “targeted”
c)	Please explain why encryption of a payload cannot be a cybersecurity defense. If the payload is a security patch for a vulnerability not publicly known, sending the payload in plan text discloses to the world the existence of that vulnerability. Contrary to what is stated in Section 5.1, this does not require the ability to “extract code from physical devices” – you get the code just by intercepting the unencrypted payload.