Overall comment: 
Qualifications: I am not an expert on SUIT implementations or an operator of networks using SUIT. 
Therefore, my issues may be covered by some general security considerations in a document I am not aware of. 

General comments to authors:  This feature is clearly described in this document. 
Brendan and Hannes did an excellent job of writing the document.  

Security/Operational Issues: 

The security of MUD URLs may move the attacks from individual devices to the MUD Manager.
(Instead of a single lemming going over the cliff, a MUD manager may send many lemmings over the cliff).  
This document does not seem to consider the operational issues in the MUD Manager or provide 
mechanisms on how to check for these attacks (e.g. Yang modules with operational state). 

1. An Attack on the MUD Manager can shut down or subvert the entire network.

It is not clear how the operator knows an attack on the MUD Manager is happening 
or occurred. If the MUD Manager pulls in broken SUIT manifests and 
then pulls in broken software/firmware based on the SUIT manifests 
how does the operator know?  In other words what device watches
that the MUD Manager is not subverted via a management protocol? 

I do not see any operational state in the MUD Yang module [RFC8620 section 2.1] 
It would seem natural to have some operational state in the MUD Manager reports manifest state. 
Yang's notif protocols could report any manifest state change (over secure TLS connections) 
to a centralized security server. 

 
2. For secure URLs transmitted by 802.1X with certificates, 
Why are these not a "double-check" on the validity of the software? 

Again, it would seem natural to utilize these secure certificates as "double-checks" on 
the MUD Manager being "in-sync"  with the devices. 

3. As a less secure double-check on being "in-sync", is the reporting of 
 MUD URL sent via MUD Devices via DHCP or LLDAP that is not what is in the manifest. 

These reporting features are useful in transition scenarios as well as detecting attacks on the MUD manager.  




Editorial nits: 

1. section 1, last paragraph, sentence 2 

Old text: /can get/
New text: /has/ 

English grammar

2. Just for my sanity, would you check the following text is correct

$$SUIT_severable-members-extensions //= (
  suit-manifest-mud => bstr .cbor SUIT_MUD_container
)
It appears you are looking to define a CBOR Type for the 
the SUIT_MOD_container is defined in the text. 

What I think I'm missing is the .cbor value for SUIT. 
It looks correct, but I could  not derive this from draft-ietf-suit-manifest-24: 

SUIT_Severable_Manifest_Members = (
  ? suit-payload-fetch => bstr .cbor SUIT_Command_Sequence,
  ? suit-install => bstr .cbor SUIT_Command_Sequence,
  ? suit-text => bstr .cbor SUIT_Text_Map,
  * $$SUIT_severable-members-extensions,
)

And your IANA definitions of: 

IANA is requested to add a new value to the SUIT envelope elements registry created with [I-D.ietf-suit-manifest]:
Label: TBD2 [[Value allocated from the standards action address range]]

Name: Manufacturer Usage Description (MUD)
Reference: [[TBD: This document]]

Again, this may be due to my incomplete understanding. 
This is why this is a NIT rather than an Issue.