Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domain
draft-ietf-suit-trust-domains-12

[Ballot comment]
Section 6:

        To avoid Dependency faults, a Manifest author MAY use explicit
        Dependencies where possible, or a Manifest processor MAY track
        references to loose Dependencies via reference counting in the
        same way as explicit Dependencies, as described in Section 5.6.5.

The construct "MAY ... where possible" sounds like that first MAY is really
a SHOULD? As in it is preferred over the second MAY "where possible"? And
in case the first MAY/SHOULD is not possible, it sounds like the second MAY
is really a MUST? Eg I don't think you can skip both MAYs and still be a
valid implementation?

[Ballot comment]
Thank you for preparing this I-D. I do not see any transport-related concerns.

I do have some comments which ought to be helpful in preparing the next revision of this document:

1. Thanks to Thomas Fossati, for the IoT directorate review. Please consider the comments in: review-ietf-suit-trust-domains-10-iotdir-telechat-fossati-2025-03-06-00.

2. CDDL: It would be helpful to readers to define “CDDL” in the definitions of section 2. I think this should be supported by a normative reference.

3. Definitions: I think it would be helpful to also define TEE here as Trusted Execution Environment in Section 2. I see there are discrepancies in the different SUIT documents, is it possible to ensure that all documents have a common set of definitions - this could be achieved by

4. RFC 1119: I’m quite a fan of RFC2119 requirements being clear when read as individual sentences - e.g., in the following I would suggest that you replace “This” by saying what is optionally to be implemented.
“This element is OPTIONAL for Recipients to implement.”

5. Table: It is helpful to add a caption to tables to describe the table contents (see Table 1).

6. Figure: I appreciated the figure at the end of section 4. CoSWID is not defined, please define in caption or definitions. This figure would benefit from a caption.

7. RFC 1119: I couldn’t work-out what was intended to be permitted by the following:
      “Commands defined outside of this document and
      [I-D.ietf-suit-manifest] MAY have additional restrictions.”
- Is this a “MAY” extend the command set - i.e. permitting extension in some way, if so please clarify this by other RFCs... or some other extension mechanism.
- If this simply saying there might be further restrictions, then I think it ought to be a little more explained what this impacts.
I expect this is just a need for better wording.

8. Finally, I do have a concern that I would like to see addressed on the text around this:
“If a Recipient supports groups of interdependent Components (a Component Set), then it SHOULD verify “
- I appreciate the way that this I-D does already provide an explanation of the implication of not following all the other recommendations (SHOULDs). It would seem useful to also explain here what happens if an implementation does not verify this, or alternatively to motivate explicitly why it is good to verify.

[Ballot comment]
Thank you to Tim Evens for the GENART review.

I support the DISCUSS positions of Mohamed Boucadair and Orie Steele.

** Section 2. 

-- This document already normatively cites draft-ietf-suit-manifest.  However, this document repeats many of the definitions here that are already present in draft-ietf-suit-manifest.  Why?

-- Why does this document provide alternative to draft-ietf-suit-manifest for identical terms.  For example:

(draft-ietf-suit-manifest) “  *  Payload: A piece of information to be delivered.  Typically      Firmware for the purposes of SUIT.”

(here) “    *  Payload: A piece of information to be delivered.  Typically Firmware/Software, configuration, or Resource data such as text or images.”

See also “Manifest, “Recipient”, and a number of others.

Are these definitional changes significant?

** Section 7
  This extension is backwards compatible when used with a Manifest
  Processor that supports the Update Procedure but = does not support
  the Staging Procedure and Installation Procedure:

What does the “=” mean here?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-suit-trust-domains-10

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-suit-trust-domains-10.txt

# for your convenience, please find some non-blocking COMMENTS

# I am not that familiar with IOT/SUIT technologies, and it was not an easy document for me to process. My review is rather generic and high level. If my comments refer to items obvious when familiar with the technology, then feel free to ignore.


# comments
# ========

101   *  software Components from multiple software signing authorities.
103   *  a mechanism to remove an unneeded Component

GV> idnit: Is there a reason why "Component" is written with a uppercase 'C'?

113   Because of the more complex use cases that are typically targetted by
114   devices implementing this specification, the applicable device class
115   is typically Class 2+ and often isolation level Is8, for example Arm
116   TrustZone for Cortex-M, as described in [I-D.ietf-iotops-7228bis]

GV> I looked up Arm in the 7228bis document and could not find it. Maybe an example that can be found in the document could be used instead? Class2+ is also not specified. I assume it reference to CLass2, 3, 4 etc... (higher as class 2), but i am not sure. Mostly this confusion is from not being overly familiar with IOT.
I am also not sure what Cortex-M or the trustzone refers towards?

118   Dependency Manifests enable several additional use cases.  In

GV> What is a dependency manifest? This is the first time this term is used in the text.
I found that a manifest provides instructions and metadata necessary for a device to
Verify the authenticity and integrity of an update, to determine whether the update is applicable, to retrieve the update payload (e.g., firmware image) and to install and activate the update in a secure manner.
I am tryng to understand what is a dependency manifest? Maybe it is specified later in the text and i did not come to it yet.

285   *  All Dependency Manifests must be present before any Payload is
286       fetched.

GV> I am confused what "must be present" exactly means. Does this mean that Dependency Manifest must be ready on the IOT for being consumed by an authority or  be read and available on the authority? (i fear i am lost on IOT procedures/terminology)

307   In addition, when multiple Manifests are used for an Update, each
308   Manifest's steps occur in a lockstep fashion; all Manifests have
309   Dependency resolution performed before any Manifest performs a
310   Payload fetch, etc.

GV> It it specified somewhere what lockstep fashion means in the context of SUIT? Can this reference be added?
I assume that "lockstep fashion" refers to the synchronized execution of update steps across multiple manifests.

348 5.  Dependencies
349
350   A Dependency is another SUIT_Envelope that describes additional
351   Components.
352
353   As described in Section 1, Dependencies enable several common use
354   cases.

GV> This aligns with an observation i had earlier in this review. Maybe for clarification add a pointer to section 5 when introducing the term dependency manifest in the introduction section 1?

358   This section augments the definitions in Required Checks
359   (Section 6.2) of [I-D.ietf-suit-manifest].

GV> When reading the word "augment" then i understand that it refers to a language construct that allows you to insert new definitions into an existing model/procedure. Would it make sense to specify where the procedure documented in section 5.1 is inserted in (Section 6.2) of [I-D.ietf-suit-manifest]? I assume it is appended at the end? or is this inserted somewhere else?

424   $$SUIT_Manifest_Extensions //=
425       (suit-manifest-component-id => SUIT_Component_Identifier)

GV> Would it make sense to suggest that the syntax used here appears to be in CBOR Data Definition Language (CDDL)?

631 5.5.  Dependency Resolution
632
633   The Dependency Resolution Command Sequence is a container for the
634   Commands needed to acquire and process the Dependencies of the
635   current Manifest.  All Dependency Manifests SHOULD be fetched before
636   any Payload is fetched to ensure that all Manifests are available and
637   authenticated before any of the (larger) Payloads are acquired.

GV> About the "SHOULD" mentioned here. What is the impact when the payload is fetched before all dependency manifests are fetched? If the procedure is broken in under that assumption, would it not be a "MUST" ?

Gunter Van de Velde
RTG Area Director

[Ballot discuss]
Hi Brendan and Ken,

Thank you of the effort put into this document.

This review takes into account RFC 9019, RFC 9124, and draft-ietf-suit-manifest.

I have a set of DISCUSS and COMMENT items. The list may seem long but that is a sign that I enjoyed reading. Let's walk through and hope to converge before the telechat.

Note that there are many nits in the document, I flagged some of them in my marked version, which I have online. I can share the link offline with the authors upon request.

# Meta Comments

## Lack of overview of blocking issues since the document was WGLC in 2023

I found that a WGLC was issued in 2023 against -02 but there is no mention in the write-up what were the issues that hindered the publication of the document since then. I also failed to find other records, including in the history tab of the document Datatracker.

I checked  diff vs -02, but it would be good if we had a summary of the changes summarized “somewhere” (the side-to-side diff is verbose as most of the changes are minor ones): I tagged at least very few changes to the CDDL, removal of the delegation part, and more examples.

Also checked the meeting presentation, but again no hint to understand the delay/blocking points.

Maybe this is due to my poor search skills, I didn’t find a record of a second WGLC or a conclusion of the first WGLC (-02).

## Need for helpers for those who will deploy

Approaching this from OPS, and how this can be put into effect, a short overview of the various pieces being grafted would be helpful. I’m not asking to have that in this document (but would happy if you do so), but I invite the WG to consider having such an overview. If you already have, please share it LOUDLY. Thank you.

Please note that I’m not looking for general matters such as 9019, but how the various specs are glued together.

## Lack for friendly representation of CDDL structures

--This is not specific to this document, but this document exacerbate the need--

It is not straightforward to pragmatically append the CDDL augmentation to what was defined in the base manifest spec and display graphically the augmentations.

It would be useful to have for CDDL a representation similar to RFC8340 for abstract YANG data structure (RFC8791). Hope this will inspire some :-)

## Document Flow

CURRENT:
  5.4.1.  Multiple Manifest Processors

I feel like some of the text in this section should be provided early in the document to help readers easily digest. Please think about it. Thanks.

# DISCUSS

## Link with the IM/Compatibility (RFC9124)

I see this spec as mainly targeting REQ.USE.MFST.COMPONENT from RFC9124. I failed to see how the current spec satisfies the following:

  Satisfies:  USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT
      (Section 4.4.4)

## Applicability: RFC7228/RFC7228bs is normative

CURRENT:
  Because of the more complex use cases that are typically targetted by
  devices implementing this specification, the applicable device class
  is typically Class 2+ and often isolation level Is8, for example Arm
  TrustZone for Cortex-M, as described in [I-D.ietf-iotops-7228bis]

Should I-D.ietf-iotops-7228bis be normative as this defines the devices to which the spec is applicable?

BTW, please fix some nits:

NEW:
  Because of the more complex use cases that are typically targeted by
  devices implementing this specification, the applicable device class
  is typically Class 2+ and often isolation level Is8, for example Arm
  TrustZone for Cortex-M, as described in [I-D.ietf-iotops-7228bis].

## Consistency with the base manifest

CURRENT:
  Steps 3 and 5 are added to the expected installation workflow of a
  Recipient:

  1.  Verify the signature of the Manifest.

  2.  Verify the applicability of the Manifest.

  3.  Resolve Dependencies.

  4.  Fetch Payload(s).

  5.  Verify Candidate.

  6.  Install Payload(s).

Putting aside steps 3/5, the list does not mirror all the items in 4.2 of the manifest. I’d like to check this is done on purpose and understand why.

As I’m there, is there always one “candidate”? I suspect that I understand that the sequential flow will lead to a candidate, but I’m not sure if there are cases where we might have conditional parts of the code and that these conditional parts are handled as single/distinct candidates.

## Amend base manifest spec

(1) CURRENT:
  The new metadata structure is shown below.


  +-------------------------+
  | Envelope                |
  +-------------------------+
  | Authentication Block    |
  | Manifest          --------------> +------------------------------+
  | Severable Elements      |          | Manifest                    |
  | Human-Readable Text    |          +------------------------------+
  | CoSWID                  |          | Structure Version            |
  | Integrated Dependencies |          | Sequence Number              |
  | Integrated Payloads    |          | Reference to Full Manifest  |
  +-------------------------+    +------ Common Structure            |
                                  | +---- Command Sequences            |
  +-------------------------+    | |  | Digests of Envelope Elements |
  | Common Structure        | <--+ |  +------------------------------+
  +-------------------------+      |
  | Dependency Indices      |      +-> +-----------------------+
  | Component IDs          |          | Command Sequence      |
  | Common Command Sequence ---------> +-----------------------+
  +-------------------------+          | List of (pairs of (  |
                                        |  * command code      |
                                        |  * argument /        |
                                        |      reporting policy |
                                        | ))                    |
                                        +-----------------------+

Do we need to tag this as updating the manifest as it extends it?

As I’m there:

  * please say this is an update of the figure in Section 4.2 if the manifest spec.

  * CoSWID: Where is this defined?

(2) The same DISCUSS is also triggered by the following:

CURRENT:

5.3.  Changes to Abstract Machine Description

  This section augments the Abstract Machine Description (Section 6.4)
  in [I-D.ietf-suit-manifest]. 

## CDDL is Normative

CURRENT:
  The following CDDL describes the Manifest Component ID:

RFC 8610  should be listed normative.

## CDDL Consistency

CURRENT:
  The Components specified by SUIT_Dependency will contain a Manifest
  Envelope that describes a Dependency of the current Manifest.  The
  Manifest is identified, but the Recipient should expect an Envelope
  when it acquires the Dependency.  This is because the Manifest is the
  one invariant element of the Envelope, where other elements may
  change by countersigning, adding authentication blocks, or severing
  elements.

  When executing suit-condition-image-match over a Component that is
  designated in SUIT_Dependency, the digest MUST be computed over just

I failed to find I don’t see SUIT_Dependency in the CDDL snippets.

Please check and let me know if I missed something or whether a fix is needed. Thanks.

## Inappropriate use of the normative language

The normative language use in the document should be checked. I flagged at least the following ones

(1)

CURRENT:
      Commands defined outside of this document and
      [I-D.ietf-suit-manifest] MAY have additional restrictions.

Consider: “Additional restrictions may be added by future commands”.

(2)

CURRENT:
      For example, every Dependency's Dependency Resolution
      step MUST be executed before any dependent's Payload fetch step.

s/MUST/must as this is an example

(3)

CURRENT:
  *  When a Manifest Processor supports multiple independent
      Components, they MAY have shared Dependencies.

Putting aside an apparent inconsistency between “independent” and “have dependencies”, this sentence can be reworded to be affirmative (s/MAY/may)

(4)

CURRENT:
  Because the Author and the Distribution System have different roles
  and MAY be separate entities, it is highly RECOMMENDED to leverage
  permissions (see Section 9 of [I-D.ietf-suit-manifest]).  For
  example, The Device can protect itself from attacker who breaches the


The first MAY is weird (may, would be just fine) while “highly” in the second part does not change the level of requirement :-) Consider delete that mention.

BTW, s/example, The Device/example, the Device

## Lack of elaboration of specific security considerations

I was expecting at least a reminder of cons specific to the multi trust domain case. Adding specific pointers where this is discussed in 9124/9019 would be a minimum.

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-suit-trust-domains-10
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-suit-trust-domains-10.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### CBOR canonical encoding

```
457   size as a null).  SUIT_Dependencies MUST be sorted according to CBOR
458   canonical encoding.
```

Don't use the term "Canonical CBOR"... see: https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.3-6.1

Do use the term "Core Deterministic Encoding Requirements" for example as used in:

https://datatracker.ietf.org/doc/html/rfc9052#section-9 .

[Ballot comment]

## Comments

Thank you to Valery Smyslov for the ART ART review.
I would like to see his review addressed on the list.

### overrides the URI

```
130       Payloads.  The network operator overrides the URI of a Payload by
131       providing a dependent Manifest that references the original
132       Manifest, but replaces its URI.
```

I don't understand this.

This could mean providing a locally sourced alternative to a remote resource, or it could mean redirecting a remote resource to some other resource.

### Terminology

```
260   *  Image: Information that a Recipient uses to perform its function,
261       typically Firmware/Software, configuration, or Resource data such
262       as text or images.  Also, a Payload, once installed is an Image.
```

Consider moving this up, so we can see how Payload, Resource and image are related.
Also consider not repeating "Firmware/Software, configuration, or Resource data".

### Dependent

```
370   it can skip redundant signature verifications.  For example, if a
371   dependent's signer has access rights to all Components specified in a
372   Dependency, then that Dependency does not require a signature
373   verification.  Similarly, if the signer of the dependent has full
374   rights to the device, according to the ACL, then no signature
375   verification is necessary on the Dependency.
```

Consider introducing the concept of a dependent in the terminology section.

```
405   The single dependent Manifest is sometimes called a Root Manifest.
```

Is this just a graph / network / tree / dag of manifests?

It it possible to specify the required checks in terms of common terminology for graphs?

Perhaps parent / child, ancestor / descendent, etc...

### Dependency Manifest's Component ID

```
418   be used by the Root Manifest.  When a Dependency Manifest also
419   declares a Component ID, the Dependency Manifest's Component ID is
420   overridden by the Component ID declared by the dependent.
```

Children name their parent's component? or parents name their child's components?

Also, why do we care about overriding here?
What problem is the overriding behavior solving?
This section is motivated by "multiple, independent Root Manifests"... but then refers to dependents, which could be of any root I presume?

A diagram would be helpful here.

Later you have:

```
625   Parameters Directive.  The second Manifest processor MAY also control
626   which Parameters may be set by the first Manifest processor by means
627   of an ACL that lists the allowed Parameters.  For example, a URI may
628   be set by a dependent without a substantial impact on the security
629   properties of the Manifest.
```

And again later:

```
676   skip setting the Parameter to its argument.  This allows dependent
677   Manifests to change the behavior of a Manifest, a Dependency that
678   wishes to enforce a specific value of a Parameter MAY use suit-
679   directive-override-parameters instead.
```

### Dependency Manifest Envelopes

```
439   Dependency Manifest Envelopes.  SUIT_Dependencies is a map of
```

capitalized but not defined.

### Dependency Manifests are also Components

Perhaps introduce them in terminology upfront...

```
206   *  Component: An updatable logical block of the Firmware, Software,
207       configuration, or data of the Recipient.
```

later:

```
521   *  Dependency Manifests are also Components.
```

I'm not an expert on suit, but this seems to confuse a manifest for firmware, with the firmware itself.
Consider clarifying and consolidating terminology.


### Manifest -> Manifest Processor?


```
544   As described in Section 5.1, each Manifest [Processor] must invoke each of its [Manifest] ...
```

Also "Manifest Processor" or "Manifest processor" ? ... in several places.


### When is this a MUST?

```
635   current Manifest.  All Dependency Manifests SHOULD be fetched before
636   any Payload is fetched to ensure that all Manifests are available and
637   authenticated before any of the (larger) Payloads are acquired.
```

... when its ok to fail later?... consider making this a MUST.


### Manifest Processor MUST abort?

```
693   If the current Component index does not have an entry in the suit-
694   dependencies map, then this Command MUST Abort.
```

or based on:

```
703   When SUIT_Process_Dependency completes, it forwards the last status
704   code that occurred in the Dependency.
```

Perhaps the Command must produce an Abort status code?

Later, I see:

```
729   If any of these steps fails, the Manifest Process MUST immediately
730   Abort.
```

also all caps abort is the same thing right?

```
754   or overwrite.  If the reference count of a component is non-zero, any
755   command that alters that component MUST cause [the Manifest Processor to] ~an~ immediate[ly] ABORT.
```


### MUST NOT allow faults?

```
788   WARNING: This can cause faults where there are loose Dependencies
789   (e.g., version range matching, see
790   [I-D.ietf-suit-update-management]), since a Component can be removed
791   while it is depended upon by another Component.  To avoid Dependency
792   faults, a Manifest author MAY use explicit Dependencies where
793   possible, or a Manifest processor MAY track references to loose
794   Dependencies via reference counting in the same way as explicit
795   Dependencies, as described in Section 5.6.5.
```

Why not MUST? Is there some other mechanism that authors would be better able to use to not produce faults?


### Can implement without parse?

```
828   images are already validated when suit-install is invoked.  This
829   makes suit-candidate-verification OPTIONAL to implement and OPTIONAL
830   to parse.
```

I don't understand why the need for the double optionals here.

### Security Considerations

```
1185 10.  Security Considerations
```

The introduction states:

```
13   This specification describes extensions to the SUIT Manifest format
14   for use in deployments with multiple trust domains.  A device has
```

Are there no security considerations that are unique to deployments with multiple trust domains?

## Nits

### Reads awk

```
155   By using Dependencies, Components such as Software, configuration,
156   and other Resource data authenticated by different Trust Anchors can
157   be delivered to devices.
```

[Ballot discuss]
Hi Brendan and Ken,

Thank you of the effort put into this document.

This review takes into account RFC 9019, RFC 9124, and draft-ietf-suit-manifest.

I have a set of DISCUSS and COMMENT items. The list may seem long but that is a sign that I enjoyed reading. Let's walk through and hope to converge before the telechat.

Note that there are many nits in the document, I flagged some of them in my marked version, which I have online. I can share the link offline with the authors upon request.

# Meta Comments

## Lack of overview of blocking issues since the document was WGLC in 2023

I found that a WGLC was issued in 2023 against -02 but there is no mention in the write-up what were the issues that hindered the publication of the document since then. I also failed to find other records, including in the history tab of the document Datatracker.

I checked  diff vs -02, but it would be good if we had a summary of the changes summarized “somewhere” (the side-to-side diff is verbose as most of the changes are minor ones): I tagged at least very few changes to the CDDL, removal of the delegation part, and more examples.

Also checked the meeting presentation, but again no hint to understand the delay/blocking points.

Maybe this is due to my poor search skills, I didn’t find a record of a second WGLC or a conclusion of the first WGLC (-02).

## Need for helpers for those who will deploy

Approaching this from OPS, and how this can be put into effect, a short overview of the various pieces being grafted would be helpful. I’m not asking to have that in this document (but would happy if you do so), but I invite the WG to consider having such an overview. If you already have, please share it LOUDLY. Thank you.

Please note that I’m not looking for general matters such as 9019, but how the various specs are glued together.

## Lack for friendly representation of CDDL structures

--This is not specific to this document, but this document exacerbate the need--

It is not straightforward to pragmatically append the CDDL augmentation to what was defined in the base manifest spec and display graphically the augmentations.

It would be useful to have for CDDL a representation similar to RFC8340 for abstract YANG data structure (RFC8791). Hope this will inspire some :-)

## Document Flow

CURRENT:
  5.4.1.  Multiple Manifest Processors

I feel like some of the text in this section should be provided early in the document to help readers easily digest. Please think about it. Thanks.

# DISCUSS

## Link with the IM/Compatibility (RFC9124)

I see this spec as mainly targeting REQ.USE.MFST.COMPONENT from RFC9124. I failed to see how the current spec satisfies the following:

  Satisfies:  USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT
      (Section 4.4.4)

## Applicability: RFC7228/RFC7228bs is normative

CURRENT:
  Because of the more complex use cases that are typically targetted by
  devices implementing this specification, the applicable device class
  is typically Class 2+ and often isolation level Is8, for example Arm
  TrustZone for Cortex-M, as described in [I-D.ietf-iotops-7228bis]

Should I-D.ietf-iotops-7228bis be normative as this defines the devices to which the spec is applicable?

BTW, please fix some nits:

NEW:
  Because of the more complex use cases that are typically targeted by
  devices implementing this specification, the applicable device class
  is typically Class 2+ and often isolation level Is8, for example Arm
  TrustZone for Cortex-M, as described in [I-D.ietf-iotops-7228bis].

## Consistency with the base manifest

CURRENT:
  Steps 3 and 5 are added to the expected installation workflow of a
  Recipient:

  1.  Verify the signature of the Manifest.

  2.  Verify the applicability of the Manifest.

  3.  Resolve Dependencies.

  4.  Fetch Payload(s).

  5.  Verify Candidate.

  6.  Install Payload(s).

Putting aside steps 3/5, the list does not mirror all the items in 4.2 of the manifest. I’d like to check this is done on purpose and understand why.

As I’m there, is there always one “candidate”? I suspect that I understand that the sequential flow will lead to a candidate, but I’m not sure if there are cases where we might have conditional parts of the code and that these conditional parts are handled as single/distinct candidates.

## Amend base manifest spec

(1) CURRENT:
  The new metadata structure is shown below.


  +-------------------------+
  | Envelope                |
  +-------------------------+
  | Authentication Block    |
  | Manifest          --------------> +------------------------------+
  | Severable Elements      |          | Manifest                    |
  | Human-Readable Text    |          +------------------------------+
  | CoSWID                  |          | Structure Version            |
  | Integrated Dependencies |          | Sequence Number              |
  | Integrated Payloads    |          | Reference to Full Manifest  |
  +-------------------------+    +------ Common Structure            |
                                  | +---- Command Sequences            |
  +-------------------------+    | |  | Digests of Envelope Elements |
  | Common Structure        | <--+ |  +------------------------------+
  +-------------------------+      |
  | Dependency Indices      |      +-> +-----------------------+
  | Component IDs          |          | Command Sequence      |
  | Common Command Sequence ---------> +-----------------------+
  +-------------------------+          | List of (pairs of (  |
                                        |  * command code      |
                                        |  * argument /        |
                                        |      reporting policy |
                                        | ))                    |
                                        +-----------------------+

Do we need to tag this as updating the manifest as it amends it?

As I’m there:

  * please say this is an update of the figure in Section 4.2 if the manifest spec.

  * CoSWID: Where is this defined?

(2) The same DISCUSS is also triggered by the following:

CURRENT:

5.3.  Changes to Abstract Machine Description

  This section augments the Abstract Machine Description (Section 6.4)
  in [I-D.ietf-suit-manifest]. 

## CDDL is Normative

CURRENT:
  The following CDDL describes the Manifest Component ID:

RFC 8610  should be listed normative.

## CDDL Consistency

CURRENT:
  The Components specified by SUIT_Dependency will contain a Manifest
  Envelope that describes a Dependency of the current Manifest.  The
  Manifest is identified, but the Recipient should expect an Envelope
  when it acquires the Dependency.  This is because the Manifest is the
  one invariant element of the Envelope, where other elements may
  change by countersigning, adding authentication blocks, or severing
  elements.

  When executing suit-condition-image-match over a Component that is
  designated in SUIT_Dependency, the digest MUST be computed over just

I failed to find I don’t see SUIT_Dependency in the CDDL snippets.

Please check and let me know if I missed something or whether a fix is needed. Thanks.

## Inappropriate use of the normative language

The normative language use in the document should be checked. I flagged at least the following ones

(1)

CURRENT:
      Commands defined outside of this document and
      [I-D.ietf-suit-manifest] MAY have additional restrictions.

Consider: “Additional restrictions may be added by future commands”.

(2)

CURRENT:
      For example, every Dependency's Dependency Resolution
      step MUST be executed before any dependent's Payload fetch step.

s/MUST/must as this is an example

(3)

CURRENT:
  *  When a Manifest Processor supports multiple independent
      Components, they MAY have shared Dependencies.

Putting aside an apparent inconsistency between “independent” and “have dependencies”, this sentence can be reworded to be affirmative (s/MAY/may)

(4)

CURRENT:
  Because the Author and the Distribution System have different roles
  and MAY be separate entities, it is highly RECOMMENDED to leverage
  permissions (see Section 9 of [I-D.ietf-suit-manifest]).  For
  example, The Device can protect itself from attacker who breaches the


The first MAY is weird (may, would be just fine) while “highly” in the second part does not change the level of requirement :-) Consider delete that mention.

BTW, s/example, The Device/example, the Device

## Lack of elaboration of specific security considerations

I was expecting at least a reminder of cons specific to the multi trust domain case. Adding specific pointers where this is discussed in 9124/9019 would be a minimum.

[Ballot comment]
# Title

OLD: SUIT Manifest Extensions for Multiple Trust Domains
NEW: Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domains

# Abstract

Consider swapping the two sentence for better flow

NEW:
  A device has
  more than one trust domain when it enables delegation of different
  rights to mutually distrusting entities for use for different
  purposes or Components in the context of firmware or software update.  This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format
  for use in deployments with multiple trust domains. 

# Introduction

(1)

CURRENT:
  Devices that go beyond single-signer update require more complex
  rules for deploying software updates.  For example, devices may
  require:

  *  software Components from multiple software signing authorities.

  *  a mechanism to remove an unneeded Component

  *  single-object Dependencies

  *  a partly encrypted Manifest so that distribution does not reveal
      private information

  *  installation performed by a different execution mode than payload
      fetch

I have several comments on this part:

  + Was “single-signer update” introduced in some other documents? I failed to find this use in the suit manifest spec, rfc9019, etc. Same comment applies for “single-object Dependencies" term.

  + I was expecting to see explanation of “more complex” in the examples, which is not currently the case.

  + Consider s/software Components/Components given that “Component” is defined as “An updatable logical block of the Firmware, Software, configuration, or data of the Recipient”. No need to be redundant here.

  + Is the second bullet specific to the multi signer case? Isn’t this applicable even for the single-signer?

  + Where “payload fetch” mode is defined?

(2)

CURRENT:
  A device may contain a processor in its radio 

I don’t parse this. Please reword.

(3) What is a device operator? Is it the vendor? Else? Please consider adding a definition or supply a reference.

(4) Consider add references for TEEP-related entites:

CURRENT:
  *  A Trusted Application Manager (TAM) wants to distribute
      personalisation information to a Trusted Execution Environment in
      addition to a Trusted Application (TA), 

(5) Add a reference for “core Manifest specification”. Also, update the teep architecture to refer rfc9397, instead of the I-D.

CURRENT:
  These mechanisms are not part of the core Manifest specification, but
  they are needed for more advanced use cases, such as the architecture
  described in [I-D.ietf-teep-architecture].

(6) Fall a little bit short :-( A summary of the extensions would be helpful.

CURRENT:
  This specification extends the SUIT Manifest specification
  ([I-D.ietf-suit-manifest]).

# Section 2

I would avoid redundant terms but refer to draft-ietf-suit-manifest#section 2. Only new terms should be listed here.

On the “see” use (not only in this section, but through the document)

CURRENT:
      authorization information, and severable elements (see Section 5.1
      of [I-D.ietf-suit-manifest]).

There are more than 60 occurrences of such in the document. Please simply delete these as this makes the two too heavy. A reference is there to be checked/viewed/seen/etc. :-)

# Section 3

(1) multi trust domain used without being adequately introduced early in the document. Consider teasing this in the introduction:

CURRENT:
  The use of the features presented for use with multiple trust domains

(2) Other assumptions:

CURRENT:
  One additional assumption is added for the Update Procedure:

  *  All Dependency Manifests must be present before any Payload is
      fetched.

  One additional assumption is added to the Invocation Procedure:

Please call out where the “other” assumptions are defined? I suspect that you meant 4.2 of the manifest. If so, please say so. If not, I need to understand ;-)

# Section 5

(1)

CURRENT:
  A Dependency is another SUIT_Envelope that describes additional
  Components.

  As described in Section 1, Dependencies enable several common use
  cases.

First, cite where the envelope is defined. Second, consider deleting the second sentence; it does not bring much, IMO.

(2) ACLs

CURRENT:
  (no ACLs defining which authorities have access to different
  Components/Commands/Parameters),

How/where these ACLs are supplied? Can we have examples or a reference where these examples are provided?

(3) Lack of interpreter behavior

CURRENT:
  If the Manifest contains more than one Component and/or Dependency,
  each Command sequence MUST begin with a Set Component Index Command.

Can we include a reminder about what to do when a mandatory condition is not met, I guess the process will abort.

A generic statement would be helpful as this applies to other similar statements in the document.

(4) Where Update is defined?

CURRENT:
  1.  The dependent MUST populate all Command sequences for the current
      Procedure (Update or Invoke).


Can we please add a pointer where this command is defined?

(5)

CURRENT:
  In complex systems, it may not always be clear where the Root
  Manifest should be stored;

Maybe

NEW:
  In complex systems, it may not always be clear where the Root
  Manifest is stored;

(6) Broken reference

CURRENT:
  This section augments the Abstract Machine Description (Section 6.4)
  in [I-D.ietf-suit-manifest]. 

Please check as there is no 6.4 in this doc. I guess you meant 6.4 of manifest. Please fix.


(7)

CURRENT:
  *  Five new Commands are introduced:

      -  Set Parameters

      -  Process Dependency

      -  Is Dependency

      -  Dependency Integrity

      -  Unlink

Consider adding a statemen to basically invite readers to look at Section 5.6.

(8) what is reference counting/reference count?

CURRENT:
  *  When a Manifest Processor supports shared Dependencies, it MUST
      support reference counting of those Dependencies.

That’is? I don’t get the meaning here. I see “reference count” used in some other parts but I have the same issue to parse the meaning, though.

(9) Lack of elaboration

CURRENT:
  3.  Loads the specified Component as a Dependency Manifest Envelope.

What does that mean concretely? Failed to find an elaboration of this in the doc.

(10) Lack of reference

CURRENT:
  Similar to suit-directive-override-parameters, suit-directive-set-

Cite 8.4.10.3 of manifest (idem for other similar constructs)

(11) Some more reasoning is needed:

CURRENT:
  parameters allows the Manifest to configure behavior of future
  Directives by changing Parameters that are read by those Directives.
  Set Parameters is for use when Dependencies are used because it
  allows a Manifest to modify the behavior of its Dependencies.

This explains why this is useful for dependency, but does not explain it can’t be used for other contexts.

(12) Factorize and ease identify failure conditions


CURRENT:
  If the current Component index does not have an entry in the suit-
  dependencies map, then this Command MUST Abort.

  If the current Component index has not been the target of a suit-
  condition-dependency-integrity, then this Command MUST Abort.

  If the current Component is True, then this Directive applies to all
  Dependencies.  If the current section is "Common metadata," then the
  Command sequence MUST Abort.

May factorize the abort part and list below the conditions as bullet list.

Also, please consider having a section with a summary of abort conditions defined in this specification.

(13) TTL and Configurable parameters

CURRENT:
  The Manifest Processor MAY cache the results of these operations for
  later use from the context of the current Manifest. 

Is there any TTL associated with this? If so, is that controllable/tunable?

Similar to the abort comment, consider having a dedicated section on configurable parameters supported by the specification.

I see that you mention at least two conditions to flush out the cache. That’s great.

# Section 8

Please check this sentence:

CURRENT:
  The Distribution System can Set the Parameter URI in the Fetch/

# Section 9

Any reason the labels weren’t assigned to be consistent with the flow use?

CURRENT:
            | 7    | Dependency Integrity | Section 5.6.4 |
            +-------+----------------------+---------------+
            | 8    | Is Dependency        | Section 5.6.3 |
            +-------+----------------------+---------------+
            | 11    | Process Dependency  | Section 5.6.2 |
            +-------+----------------------+---------------+
            | 19    | Set Parameters      | Section 5.6.1 |
            +-------+----------------------+---------------+
            | 33    | Unlink              | Section 5.6.5 |
            +-------+----------------------+---------------+

Hope this helps.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-suit-trust-domains-09. If any part of this review is inaccurate, please let us know.

IANA understands that all of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

draft-ietf-suit-manifest

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, in the SUIT Envelope Elements registry on the SUIT registry group to be created upon the approval of:

draft-ietf-suit-manifest

two new SUIT Envelope Elements will be registered as follows:

Label: 15
Name: Dependency Resolution
Reference: [ RFC-to-be; Section 5.5 ]

Label: 18
Name: Candidate Verification
Reference: [ RFC-to-be; Section 7.1 ]

Second, in the SUIT Manifest Elements registry also in the SUIT registry group to be created upon the approval of:

draft-ietf-suit-manifest

three new SUIT Manifest Elements will be registered as follows:

Label: 5
Name: Manifest Component ID
Reference: [ RFC-to-be; Section 5.2.1 ]

Label: 15
Name: Dependency Resolution
Reference: [ RFC-to-be; Section 5.5 ]

Label: 24
Name: Uninstall
Reference: [ RFC-to-be; Section 6 ]

Third, in the SUIT Common Elements registry also in the SUIT registry group to be created upon the approval of:

draft-ietf-suit-manifest

a single new SUIT Common Element will be registered as follows:

Label: 1
Name: Dependencies
Reference: [ RFC-to-be; Section 5.2.2 ]

Fourth, in the SUIT Commands registry also in the SUIT registry group to be created upon the approval of:

draft-ietf-suit-manifest

five new SUIT Commands will be registered as follows:

Label: 7
Name: Dependency Integrity
Reference: [ RFC-to-be; Section 5.6.4 ]

Label: 8
Name: Is Dependency
Reference: [ RFC-to-be; Section 5.6.3 ]

Label: 11
Name: Process Dependency
Reference: [ RFC-to-be; Section 5.6.2 ]

Label: 19
Name: Set Parameters
Reference: [ RFC-to-be; Section 5.6.1 ]

Label: 33
Name: Unlink
Reference: [ RFC-to-be; Section 5.6.5 ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-08):

From: The IESG
To: IETF-Announce
CC: dave.thaler.ietf@gmail.com, debcooley1@gmail.com, draft-ietf-suit-trust-domains@ietf.org, dthaler1968@gmail.com, suit-chairs@ietf.org, suit@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SUIT Manifest Extensions for Multiple Trust Domains) to Proposed Standard


The IESG has received a request from the Software Updates for Internet of
Things WG (suit) to consider the following document: - 'SUIT Manifest
Extensions for Multiple Trust Domains'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification describes extensions to the SUIT Manifest format
  for use in deployments with multiple trust domains.  A device has
  more than one trust domain when it enables delegation of different
  rights to mutually distrusting entities for use for different
  purposes or Components in the context of firmware or software update.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-suit-trust-domains/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 25 October 2024.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential) individuals, including implementers, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document (draft-ietf-teep-protocol) that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

The shepherd then did a second review of the document as part of this
writeup and found a few minor editorial issues in -07 that were
addressed in -08, and a few more that should be addressed in -09 that
were called out in https://mailarchive.ietf.org/arch/msg/suit/lYTpc7Oha-iWOEP6hBzVqNZHplQ/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

== There is 1 instance of lines with non-ascii characters in the document.

I could not determine what that line is, but there is no reason to use non-ascii
in this document so the RFC editor pass could clean it up if needed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

1.  requested early reviews.

2.  So I ran idnits to see what popped up.  In addition to the normal random things (long lines, non-ascii characters, out of date drafts), there were 4 normative references that are Informational.  Of course, none of them are in the downref registry.  Can we confirm that they are normative references?

3.  Section 10:  I have two comments here.
a.  Why bother referencing RFC9019 when it merely points to RFC9124 (and really only to the draft of RFC9124 that existed at the time of publication).
b.  While RFC9124 discussed security considerations in terms of threats and consequences in great detail, it does not address the threats/consequences of having multiple trust domains.  What vulnerabilities are introduced by allowing dependencies?  What does the implementer have to consider when adding this complexity?  There are hints buried in the draft (must abort type language), but it is my opinion that those hints could be expanded and clarified in the security consideration section.

# Document Shepherd Write-Up for Group Documents

*This version is dated 25 July 2024.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential) individuals, including implementers, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document (draft-ietf-teep-protocol) that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

The shepherd then did a second review of the document as part of this
writeup and found a few minor editorial issues in -07 that are being
addressed in -08.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 25 July 2024.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential) individuals, including implementers, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document (draft-ietf-teep-protocol) that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential) individuals, including implementers, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document (draft-ietf-teep-protocol) that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential, including implementers) individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors are being consulted to verify.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document represents the concurrence of relatively few (but knowledgeable
and influential, including implementers) individuals, with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was no particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

An open source implementation is available at https://github.com/kentakayama/libcsuit
which is linked to the draft in the datatracker. It is unknown whether there are
additional implementations, such as non-open source.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a normative dependency from standards track work in the TEEP WG.
The TEEP WG has already reviewed this document, and the document shepherd of this
doc is an editor of the TEEP WG document that normatively references it.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal expert reviews were applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does use CDDL and the document passes a CDDL checker tool.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd previously conducted an extensive review of the document, with
feedback referenced in https://mailarchive.ietf.org/arch/msg/suit/-PGeEvC--XDRpdPMzYl_JUF0Sm4/
and the updated draft addresses that feedback.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None appear to be applicable except security area review.  This document
is in the security area and has been reviewed by security experts who
participate in the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This document extends draft-ietf-suit-manifest which was
previously submitted for Proposed Standard.  It is a normative dependency of
draft-ietf-teep-protocol which is also intended to be Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors are being consulted to verify.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, both authors agreed to be authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Confirmed.  Additions to existing registries follow stated guidelines.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/