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-msg-wrap-19 Reviewer: Peter Yee Review Date: 2025-10-29 IETF LC End Date: 2025-10-13 IESG Telechat date: Not scheduled for a telechat Summary: This specification describes a means for conveying RATS Conceptual Messages wrapped in JSON or CBOR and transported as CWTs, JWTs, or X.509 extensions. I’m not sufficiently CDDL savvy to determine whether the definitions given are correct, but overall, the document is well-written and appears coherent. I found a very small number of nits and I have two questions that I will note under minor issues, but I’m going to say this document is ready with nits. [Ready with Nits] Major issues: None Minor issues: Page 10, 6th paragraph: Is there some expectation of what happens when a sending implementation allows more nesting depth than a receiving implementation? Page 26, section 10.5, 4th paragraph: do indicator values need to be in monotonically ascending order or are gaps fine? Nits/editorial comments: Page 1, Abstract, 1st paragraph, 1st sentence: since the use of “(RFC9334)” is not a reference (which are not allowed in abstracts in any case), then it should be written as “(RFC 9334”. (See RFC 7322, section 3.5.) Page 1, Abstract, 1st paragraph, last sentence. The same correction applies here as well. Page 7, ind definition, 2nd sentence: change “included” to “inclusive”. Page 7, ind definition, 3rd sentence: change “values” to “bits”. There are many more values than bits, as the previous sentence shows. Append a comma after “so”. Delete the comma after “ambiguous”. Page 11, section 4, 1st sentence: append a comma after “integrity”. Page 12, section 4.1, sentence after “signed-cbor-cmw” layout: append a comma after “Record”. Page 16, section 5.2, paragraph after the wire registration: change “registrered” to “registered”. Page 19, section 6: at least one sentence explaining what this section is wouldn’t be a bad thing. Page 23, section 9.1, 1st paragraph, 1st sentence: append a comma after “Tags”. Page 28, section 10.5.2, 2nd paragraph: append “prior to publication of this specification as an RFC” after “regularly updated” to make it clearer what’s going on here. The 3rd paragraph helps that understanding, but reading the 2nd paragraph in order might leave the reader confused as to what’s going on here. Another thought is to mark section 10.5.2 as to be deleted by the RFC Editor on publication as it is almost completely irrelevant after that.