[Suit] Re: Gorry Fairhurst's No Objection on draft-ietf-suit-trust-domains-10: (with COMMENT)

[Brendan Moran <[e-mail]>]

Hi Gorry,

Thank you for your review.

1. I believe the latest version corrects Thomas's one remaining nit.

2. CDDL is now a normative reference and it is referenced both at
first mention and in the appendix that details the full CDDL.

3. The TEEP Architecture (RFC9397) is now referenced in the
terminology section. This defines terminology such as TEE.

4. The latest version uses the explicit element name, rather than saying "this"

5. I have added captions to the tables in the latest version.

6. The CoSWID reference has been removed.

7. This section has been reworded to be clearer about the intended
restrictions: Future commands define their own restrictions.

8. A new line has been added that explains the consequences of not
checking that all components in a component set are specified.

Best Regards,
Brendan

On Wed, Apr 16, 2025 at 8:31 AM Gorry Fairhurst via Datatracker
<[e-mail]> wrote:
>
> Gorry Fairhurst has entered the following ballot position for
> draft-ietf-suit-trust-domains-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-suit-trust-domains/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
>