[Rats] Robert Wilton's No Objection on draft-ietf-rats-eat-21: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-rats-eat-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Discuss cleared based on the agreement to make the change proposed below.

(2) p 0, sec

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.

This is probably contentious, but given that this is a new spec, I wonder
whether it wouldn't be better (i.e., encourage wider interop) if only CBOR,
COSE and CWT were used/allowed.

(3) p 20, sec 4.2.6.  swname (Software Name) Claim

   The "swname" claim contains a very simple free-form text value for
   naming the software used by the entity.  Intentionally, no general
   rules or structure are set.  This will make it unsuitable for use
   cases that wish precise naming.

I found it interesting, and slightly surprising, that the hardware model claim
is opaque, but the software name claim is not.

(4) p 24, sec 4.2.11.  uptime (Uptime) Claim

   The "uptime" claim MUST contain a value that represents the number of
   seconds that have elapsed since the entity or submodule was last
   booted.

Relative to other claim descriptions, the MUST in this description seems
strange.  Perhaps better as just "The "uptime" claim contains a value ..."

(5) p 88, sec Appendix B.  UEID Design Rationale

   A UEID is not a UUID [RFC4122] by conscious choice for the following
   reasons.

Note that the UUID spec is currently being updated (it is also on this week's
telechat review), so some of the concerns being described here may no longer be
valid.  It is still only 128 bits though, and 6 bits are spent identifying UUID
format and version.

(6) p 89, sec Appendix B.  UEID Design Rationale

   Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared
   to 16 for a UUID.

Note that the paragraph at the end of appendix B.1. states that UEIDs are a
minumum of 128 bits ...

Regards,
Rob