MIME-Version: 1.0
References: 
 <174478868450.1354916.15943053909594624224@dt-datatracker-64c5c9b5f9-hz6qg>
In-Reply-To: 
 <174478868450.1354916.15943053909594624224@dt-datatracker-64c5c9b5f9-hz6qg>
From: Brendan Moran <brendan.moran.ietf@gmail.com>
Date: Tue, 22 Jul 2025 13:20:09 +0100
Message-ID: 
 <CAPmVn1O16=TWjRVzj8m3VoU=awrEvhSDD3Tk4FKQ1AHDjdyUWg@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: PUFDLZAGZKDIN53RLYPEXR6K6PQYIOSN
CC: The IESG <iesg@ietf.org>, draft-ietf-suit-trust-domains@ietf.org,
 suit-chairs@ietf.org, suit@ietf.org, dthaler1968@gmail.com,
 dave.thaler.ietf@gmail.com
Precedence: list
Subject: =?utf-8?q?=5BSuit=5D_Re=3A_Gorry_Fairhurst=27s_No_Objection_on_draft-ietf-su?=
 =?utf-8?q?it-trust-domains-10=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/suit/2Bt7s13zK218RW2ce1ZdQnkFXoI>

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 "t=
his"

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=E2=80=AFAM Gorry Fairhurst via Datatracker
<noreply@ietf.org> 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/handlin=
g-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 conc=
erns.
>
> 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 consi=
der
> 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 =E2=80=9CCDDL=E2=80=9D =
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 Tr=
usted
> Execution Environment in Section 2. I see there are discrepancies in the
> different SUIT documents, is it possible to ensure that all documents hav=
e a
> common set of definitions - this could be achieved by
>
> 4. RFC 1119: I=E2=80=99m quite a fan of RFC2119 requirements being clear =
when read as
> individual sentences - e.g., in the following I would suggest that you re=
place
> =E2=80=9CThis=E2=80=9D by saying what is optionally to be implemented. =
=E2=80=9CThis element is
> OPTIONAL for Recipients to implement.=E2=80=9D
>
> 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 no=
t
> defined, please define in caption or definitions. This figure would benef=
it
> from a caption.
>
> 7. RFC 1119: I couldn=E2=80=99t work-out what was intended to be permitte=
d by the
> following:
>       =E2=80=9CCommands defined outside of this document and
>       [I-D.ietf-suit-manifest] MAY have additional restrictions.=E2=80=9D
> - Is this a =E2=80=9CMAY=E2=80=9D extend the command set - i.e. permittin=
g 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, t=
hen 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: =E2=80=9CIf a Recipient supports groups of interdependent Co=
mponents (a
> Component Set), then it SHOULD verify =E2=80=9C - I appreciate the way th=
at this I-D
> does already provide an explanation of the implication of not following a=
ll the
> other recommendations (SHOULDs). It would seem useful to also explain her=
e what
> happens if an implementation does not verify this, or alternatively to mo=
tivate
> explicitly why it is good to verify.
>
>
>