I have one easy comment: 

Section 7.2, 7.3, 7.4, and 7.5:  The bullets from these sections are all selected or paraphrased from RFC9053.  In some cases the paraphrasing is imprecise.  I'd almost rather see the bullets eliminated, leaving the section numbers of RFC9053.  This might ensure that a developer actually consults with RFC9053 vice assuming the bullets are complete.

Thank you for the work on this document and for addressing my DISCUSS and COMMENTs.

Updated to add: I note that the new media type registration has not been sent to the media-types mailing list for review. However, given how its symmetrical one for CBOR has been sent and raised no objection, I am not blocking the document on that.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-rats-uccs-10

# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rats-uccs-10.txt

# After reviewing the document, I did not identify any significant typographical errors. The text is well-written.

# idnits gives some warnings about the references


#DETAILED COMMENTS
#=================
## classified as [minor] and [major]

15	Abstract
16
17	   When transported over secure channels, CBOR Web Token (CWT, RFC 8392)
18	   Claims Sets may not need the protection afforded by wrapping them
19	   into COSE, as is required for a true CWT.  This specification defines
20	   a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses
21	   conditions for its proper use.

[minor]

GV> What about the following rewrite making the abstract more higher level descriptive:

"
This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without a signature, message authentication code (MAC), or encryption. UCCS enables the use of CWT claims in environments where data protection is provided by other means, such as secure communication channels or trusted execution environments. This specification describes the UCCS format, its encoding, and processing considerations, and discusses the security implications of using unprotected claims sets.
"

Thanks for addressing my comments in https://mailarchive.ietf.org/arch/msg/rats/LnJ-Bieodx9UVE3IdQ9IElYllZE/

Thanks for addressing my concerns. I have updated my ballot to 'No Objection'

Supporting Orie's Dicsuss.

Thanks for the work done in this document. To be honest, I was about to ballot ABSTAIN because CWT at rest (e.g., in audit trails or logs) are no more secure and the secure channel transport entity could be different than the CWT producer/consumer, but I am trusting the SEC ADs in their ballot (i.e., I probably do not understand the use cases), hence a NoObjection ballot. Some non-blocking comments anyway:

# Section 1

s/A true CWT/A RFC8392 CWT/ ? Unsure whether 'true' is applicable here.

Should there be a reference for "PCIe IDE" ?

# Section 2

Please expand "RATS" 

# Section 4

Please expand "EAT"

# Section 7.1

Even if by default the text is normative, should BCP14 terms be used ?

# Sections 7.2 to 7.5

These sections are specific to currently used crypto algorithms, should these section be more condensed in a generic one ? or should there be a section about future algorithms ?

# Appendix A

How can `This appendix is informative.` and `this specification shows how to use CDDL` appear in the same section ? s/this specification shows how to use CDDL/this example shows how to use CDDL/