IETF Last Call Review of draft-ietf-rats-msg-wrap-19
review-ietf-rats-msg-wrap-19-genart-lc-yee-2025-10-29-00

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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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.