Skip to main content

Last Call Review of draft-ietf-rats-architecture-21

Request Review of draft-ietf-rats-architecture
Requested revision No specific revision (document currently at 22)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-09-01
Requested 2022-08-18
Authors Henk Birkholz , Dave Thaler , Michael Richardson , Ned Smith , Wei Pan
I-D last updated 2022-08-19
Completed reviews Genart Last Call review of -21 by Gyan Mishra (diff)
Secdir Last Call review of -21 by Shawn M Emery (diff)
Opsdir Last Call review of -21 by Joe Clarke (diff)
Assignment Reviewer Gyan Mishra
State Completed
Request Last Call review on draft-ietf-rats-architecture by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 21 (document currently at 22)
Result Ready w/nits
Completed 2022-08-19
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-rats-architecture-??
Reviewer: Gyan Mishra
Review Date: 2022-08-19
IETF LC End Date: 2022-09-01
IESG Telechat date: Not scheduled for a telechat


This document provides an architectural overview of the entities involved that
make such tests possible through the process of generating, conveying, and
evaluating evidentiary claims.
   An attempt is made to provide for a model that is neutral toward processor
   architectures, the content of claims, and protocols.

Major issues:

Minor issues:
As this is a architecture specification should this be standards track.
Normative language should then be applied where applicable.  As the
architecture of rats is related to security a lot of what is in the security
considerations to me seems part of the architecture and maybe should be moved
to the body of the document or appendix. Section 3 describes the environment of
an attester.  Section 3.2 clearly describes a layered environment, however
section 3.3 describes a composite environment using a carrier grade router as
an example.  I think here the composite should be described just as is done in
the layer environment section but not referencing an environment use case that
may not be applicable to RAT.  So within a carrier grade router chassis the
backplane communication is all done vendor proprietary no external elements so
I don’t see how trust comes into play as well as the backplane communication is
hardware bus elements for backplane throughput for the LC and then as well
router OS software component for the backplane communication. I think maybe
choosing a better example that applies to RAT composite environment would be

Nits/editorial comments:
Throughout the document there are acronyms used and the acronyms have not been
expanded. Few words like ROM, BIOS, TEEP, TLS, CWT, JWT, X.509, TPM etc