Last Call Review of draft-ietf-rats-architecture-21
review-ietf-rats-architecture-21-opsdir-lc-clarke-2022-09-12-00

Sorry for being late to this.  I was asked to review this document on behalf of
the OPS DIR.  Overall, I found the document well-written, though dense.  It
does describe a high-level architecture for remote attestation, and I tried to
divine what impact this architecture might have on operators.  I had some
initial confusion (for example, what endorsements are provided in the ROM
example), and I think moving Section 4 up closer to the beginning will help the
reader set some of that initial context.

Operator-wise I was a bit concerned about what some of the process might mean
for troubleshooting and overall system performance.  For example, the TLS
handshake verification, if implemented would add more parties and more time as
it's verified (if I understand that correctly).  That said, I debated about
whether it's useful to raise it as an issue here or later on when such
implementation is defined.  If here, I think expanding on the desire operators
might have for remote attestation and the considerations it presents on overall
system understanding might be useful.

On the security front, I'm not an expert, but I was expecting to see something
about any risks with combining roles such as Attester and Verifier on the same
system.  Maybe there aren't any, but that hybrid example got me thinking what
would be the risk if the system doing my background check also evaluated the
data.

On the nits front:

Section 3:

You have a "Section Section 4" double word.

===

Section 5.1:

Double "the"

===

Section 8.4

You have a "section Section 11" double word.