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-eat-21 Reviewer: Ines Robles Review Date: 2023-08-09 IETF LC End Date: 2023-08-09 IESG Telechat date: Not scheduled for a telechat Summary: This document describes Entity Attestation Token (EAT) that provides an attested claims set that describes state and characteristics of an entity. This claims set is used by a relying party, server, or service to assess the trustworthiness of the entity. EAT is constructed as a framework for defining specific attestation tokens for specific use cases. The document is well documented, with good set of references. No major issues found, minor nits found as specified below. Major Issues: None Minor Issues: None Nits: - Abstract: What about "...service to determine how much it wishes to trust the entity." --> "...service to assess the trustworthiness of the entity." ? - Section 4.1.17: Maybe "failure, fail to run, ..." --> "failure, fail to run, among others." ? - In Section 4.2.14 "(DLOAs))" --> (DLOAs), the same for (Section 4.2.16)) in Section 6.2.12 - Section 4.3.3 and Section 7.3.1. "TBD(BUNDLE-Untagged-Message)" --> TBD602(BUNDLE-Untagged-Message) ? (To be aligned with IANA Section) - Section 6.2.12: "This document requires an EAT receiver must accept all claims it does not understand." are there specific security consideration to follow in this case not mentioned in section 9.1? - Section 6.3: It would be nice to have a caption for Table 2. (Same for rest of the tables) - Section 7.3.1: "one place that that a CBOR token" --> "one place where a CBOR token" ? - Appendix C.1: "EAT doesn't define a an device implementation and DevID does." --> "EAT doesn't define a device implementation, but DevID does." ? Thanks for this document, Ines.