Authors,
While reviewing this document during Final Review, please resolve (as
necessary) the following questions, which are also in GitHub issues (see
https://github.com/rfc-editor-drafts/FinalReview-rfc10013/issues).
1) <!--[rfced] Is the intention here to point to the "Named Information"
registry
group as a whole, or may we update the text and citation to specifically point
to the "Named Information Hash Algorithm Registry"?
Current:
The type of the digest algorithm identifier
can be either int or text and is interpreted according to the "Named
Information" IANA registry [IANA.named-information].
...
[IANA.named-information]
IANA, "Named Information",
<https://www.iana.org/assignments/named-information>.
Perhaps:
The type of the digest algorithm identifier
can be either int or text and is interpreted according to the "Named
Information Hash Algorithm Registry" IANA registry [IANA.named-information].
...
[IANA.named-information]
IANA, "Named Information Hash Algorithm Registry",
<https://www.iana.org/assignments/named-information>.
-->
2) <!--[rfced] Please note that we have put the following text in the
<aside> element. It is defined as "a container for content that
is semantically less important or tangential to the content that
surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
Please let us know any objections.
Original:
(Note that the complete definition of sw-
version-type depends on the $version-scheme CDDL socket defined in
Section 2.2 of [RFC9393].)
-->
3) <!--[rfced] Section 5 (Security Considerations) and Section 6 (Privacy
Considerations) both cite RFC 9711. However, there seems to be
some inconsistency in the names of the specific sections:
Section 5:
The considerations discussed in Sections 9.1 (Claim Trustworthiness),
9.4 (Multiple EAT Consumers) and 9.5 (Detached EAT Bundle Digest
Security Considerations) of [RFC9711] apply to this document as well.
Section 6:
The differential encryption considerations discussed in Section 9.1
(Multiple EAT Consumers) of [RFC9711] also apply to this document.
RFC 9711:
9.1. Claim Trustworthiness
9.4. Multiple EAT Consumers
9.5. Detached EAT Bundle Digest Security Considerations
Please let us know how we may update Section 6.
Perhaps A:
The differential encryption considerations discussed in Section 9.1
(Claim Trustworthiness) of [RFC9711] also apply to this document.
Perhaps B:
The differential encryption considerations discussed in Section 9.4
(Multiple EAT Consumers) of [RFC9711] also apply to this document.
-->
4) <!--[rfced] We had the following questions related to figures
throughout the document:
a) As all other figures and titles in the document had names,
we have updated to give Table 5 a name. Please review and let us
know any objections.
b) We note that Figure 4 states that it uses RFC 8792 folding while
Figures 2, 3, and 5 do not (but they appear to use folding). Please
review and let us know if/how to update.
c) We see that type="cbor-edn" is used for some sourcecode
elements. This type does not appear on the current list of preferred
values for the type attribute:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
Would you like to remove type="cbor-edn"? It is acceptable to leave the "type"
attribute not set. Alternately, would you like to suggest type="cbor-edn" be
considered as as addition to the list? If so, we can submit it for review by
the RPC team.
-->
5) <!--[rfced] We had the following questions related to the Collected CDDL:
a) Should the parentheses appear in both places?
Section 4.2:
alg: (int / text)
Appendix A:
alg: int / text
b) There are some spacing variations between the CDDL throughout the
document and that collected in the appendix, such as:
Section 4.3.2:
[ + authority-id-type ]
Appendix A:
[+ authority-id-type]
Please let us know if/how to make things uniform.
c) We note some trailing commas in the appendix that do not appear in
the CDDL spread throughout the document. Please review and let us
know if these should be made uniform. For example:
Section 4.3:
component-id-label => component-id
Appendix A:
component-id-label => component-id,
-->
6) <!--[rfced] FYI - We have added expansions for abbreviations
upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
review each expansion in the document carefully to ensure
correctness.
-->
7) <!--[rfced] We had the following questions/comments related to terminology
use throughout the document:
a) We see several variations of the following:
measured component vs. "measured component" vs. measured-component
vs. Measured Component
Please review and let us know if/how to make these uniform.
b) We note that RFC 9711 uses "measurements" claim while this document uses:
measurements claim vs. Measurements claim
Please review and let us know if/how to update.
c) May we update uses of attester to be capped (i.e., Attester) to match other
documents' use and the use in the IANA Considerations section?
d) We see variation in the following, please confirm that these terms
appear as intended.
Content-Type vs. content-type
Content-Format vs. content-format
-->
8) <!--[rfced] We had the following questions/comments related to the use
of the <tt> tag in the XML:
a) We see the following terms inconsistently surrounded by <tt> tags
in the XML file. It is difficult to tell if some terms in running
text that are currently not marked with <tt> actually should be marked
with <tt> (e.g., digest, measurements, name, version, etc.). Please
review and let us know if any of these terms should be marked (or feel
free to mark them in the edited XML and resubmit if that is easier).
b) Please note the use of quotation marks inside the <tt> tags in some
cases (and not used in others). We recommend moving them outside of
the <tt> tags unless they are part of the literal string. Please let
us know if/how to make these terms uniform.
<tt>"authorities"</tt>
<tt>authorities</tt>
<tt>content-format</tt>
<tt>digest</tt>
<tt>"id"</tt> (vs. "ID")
<tt>measurements</tt>
<tt>Measurements</tt>
<tt>"measurement"</tt>
<tt>name</tt>
<tt>text</tt>
<tt>version</tt>
-->
9) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
Thank you.
RFC Production Center
On Jun 22, 2026, at 11:20 AM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Your document has now entered Final Review (formerly AUTH48).
Final Review is being handled in GitHub as part of the GitHub pilot test
(see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test).
Your document is available for review at:
https://github.com/rfc-editor-drafts/FinalReview-rfc10013
Please do the following:
a) accept your invitations to join the repo as collaborators. Simon, Hannes,
and Henk, please provide your GitHub usernames so that we can send you
invitations. We have already sent an invitation to Thomas. If the AD
(Christopher Inacio) and the WG Chairs (Kathleen Moriarty and Ned Smith) would
like invitations as well, please provide GitHub usernames.
b) see the README for details on the Final Review process:
https://github.com/rfc-editor-drafts/FinalReview-rfc10013/blob/Approved/README.md
c) review the edits in the RPC-edits pull request:
https://github.com/rfc-editor-drafts/FinalReview-rfc10013/pulls
d) address the issues:
https://github.com/rfc-editor-drafts/FinalReview-rfc10013/issues
Once the content is stable in GitHub, we will provide the updated XML file
and the output files for review and approval.
You and your coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Once the document has been reviewed and approved by all of the authors,
it will be published as an RFC. If an author is no longer available,
there are several remedies; see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10013/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Production Center
--------------------------------------
RFC 10013 (draft-ietf-rats-eat-measured-component)
Title : Entity Attestation Token (EAT) Measured Component
Author(s) : S. Frost,
T. Fossati,
H. Tschofenig,
H. Birkholz
WG Chair(s) : Ned Smith, Kathleen Moriarty
Area Director(s) : Deb Cooley, Christopher Inacio
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
