Thank you for the work on this document.

Thank you for addressing my DISCUSS and posting the registration request to the media-types mailing list. 

I am following discussions regarding the UCCS doc draft-ietf-rats-uccs-10 (especially see Orie's and my ballots), and I believe changes to that document may affect this document. I suggest the responsible AD to hold this doc until that one is also approved.

I support Francesca's DISCUSS.

I suggest dropping your use of BCP 14, for two reasons:

(a) You only use one MUST, which could be shed without loss of force by changing "MUST use" to "uses";

(b) I think the use of MUST in the media type templates is not appropriate because, when those are copied verbatim to the registry, the BCP 14 template isn't going to be there to explain what "MUST" (in all caps) means.

# Orie Steele, ART AD, comments for draft-ietf-rats-eat-media-type-11 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-11.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Yoshiro Yoneya for the ARTART Review.

I agree with the comments from Eric, Roman and Francesca.

I support Francesca's DISCUSS.

I can see how the UCCS tags are used in the context of EAT, but I do not see how application/uccs+cbor is used in RATS, or when it would be preferred to application/eat-ucs+cbor.

Since I am still holding a discuss on the UCCS draft:

https://mailarchive.ietf.org/arch/msg/rats/MXkaNqo9WhrTVjY2g7AEjno0PBM/

I will leave this ballot position as no objection, but I would ask that when you submit your registration review for these media types, you draw attention to the registration review for application/uccs+cbor which is here:

https://mailarchive.ietf.org/arch/msg/media-types/Txlf2LFo4C9goydmECFDwxDnqYg/

And explain to the DEs why both registrations are necessary, and under which circumstances they should be used... and ideally this is also reflected in BOTH documents.

No comments beyond what has already been raised.

Thank you to Christer Holmberg for the GENART review.

** Section 6.7
   Optional parameters:  "eat_profile" (EAT profile in string format.
      OIDs MUST use the dotted-decimal notation.  The parameter value is
      case-insensitive.)

-- Is using RFC2119 key words in an IANA template the right thing to do?  Perhaps add this keyword to Section 3 instead:

OLD
The value of the eat_profile claim is either an OID or a URI

NEW 
The value of the eat_profile claim MUST be either an OID or a URI.  If an OID is used, it MUST use the dotted-decimal notation).

-- Why is there guidance in the IANA template about the OID, but nothing saying it also needs to be a URI?  It might be clearer to provide guidance on the format of this parameter in only one place (Section 3).

** Section 6.9
   TBD1..6 are to be assigned from the space 256..999.

s/999/9999/ as that is the full range for IETF Review code points.  Or is the request really to get a <1000 code point?

Other than supporting Eric's position I don't have much to add.

# Éric Vyncke, INT AD, comments for draft-ietf-rats-eat-media-type-11

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Kathleen Moriarty for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Jouni Korhonen, the IoT directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-rats-eat-media-type-10-iotdir-lc-korhonen-2024-10-09/ (and I have read Thomas' reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

I was unable to find any normative language about the use of those media types, not even "MAY" use. Section 3 has a single "MUST", which is only about the quoted-string encoding.

## Section 3

Please bear with my ignorance of OID, but it seems to me that draft-ietf-rats-eat-31 states that only the PEN should be used in the OID (to compress), so the example of `eat_profile=2.999.1` in this document refers to an existing company (IBM) per https://www.iana.org/assignments/enterprise-numbers/. If I understand correctly, then please use another PEN or the documentation PEN 32473 (per RFC 5612).  

## Section 5

Suggest using "MUST" in `The application must verify that the received data matches the expected format`. Also, what should the application do in this does not match?