Hi Carl,

Thank you for the catch. We have updated "$EAT-CBOR-Tagged-Token” to 
"$CBOR-Tagged-Token” in Section 3.

—Files (please refresh)— 

The updated XML file is here:
https://www.rfc-editor.org/authors/rfc9711.xml

The updated output files are here:
https://www.rfc-editor.org/authors/rfc9711.txt
https://www.rfc-editor.org/authors/rfc9711.pdf
https://www.rfc-editor.org/authors/rfc9711.html

These diff files show all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9711-auth48diff.html
https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html (side by side)

These diff files show only the change made during the last editing round:
https://www.rfc-editor.org/authors/rfc9711-lastdiff.html
https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html (side by side)

These diff files show all changes made to date:
https://www.rfc-editor.org/authors/rfc9711-diff.html
https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html (side by side)

Best regards,
RFC Editor/kc


> On Feb 7, 2025, at 2:33 PM, Carl Wallace <c...@redhoundsoftware.com> wrote:
> 
> There is a stray $EAT-CBOR-Tagged-Token in Section 3. It should be 
> $CBOR-Tagged-Token (as appears in section 7.3.2). Sorry for not catching this 
> sooner.
> 
> On 2/7/25, 5:22 PM, "Karen Moore" <kmo...@staff.rfc-editor.org 
> <mailto:kmo...@staff.rfc-editor.org>> wrote:
> 
> 
> Dear Giri and *Roman (AD),
> 
> 
> Thank you for providing the document that outlines Round 4 of the suggested 
> changes. We have updated our files accordingly. Please review, especially the 
> formatting/spacing in Section 4.2.3.3, and let us know if any further changes 
> are desired or if you approve the document in its current form (the new 
> formatting/spacing is best viewed in this file: 
> https://www.rfc-editor.org/authors/rfc9711.txt 
> <https://www.rfc-editor.org/authors/rfc9711.txt>).
> 
> 
> *Roman, please review the updates that were made to Sections 3, 4.1, 4.2.3.2, 
> 4.2.3.3, 4.2.10, 4.2.18, 5, 7.3, 7.3.1, 7.3.2, and 9.1 and Appendices A.1.7, 
> A.2.2, A.2.3, B.2, and D during AUTH48, and let us know if you approve. 
> Please review the changes in this file: 
> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>. Note that the 
> authors provided comments for some of the changes in the attached word 
> document, if needed.
> 
> 
> —Files (please refresh)— 
> 
> 
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9711.xml 
> <https://www.rfc-editor.org/authors/rfc9711.xml>
> 
> 
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9711.txt 
> <https://www.rfc-editor.org/authors/rfc9711.txt>
> https://www.rfc-editor.org/authors/rfc9711.pdf 
> <https://www.rfc-editor.org/authors/rfc9711.pdf>
> https://www.rfc-editor.org/authors/rfc9711.html 
> <https://www.rfc-editor.org/authors/rfc9711.html>
> 
> 
> These diff files show all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>
> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html 
> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by side)
> 
> 
> These diff files show only the change made during the last editing round:
> https://www.rfc-editor.org/authors/rfc9711-lastdiff.html 
> <https://www.rfc-editor.org/authors/rfc9711-lastdiff.html>
> https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html 
> <https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html> (side by side)
> 
> 
> These diff files show all changes made to date:
> https://www.rfc-editor.org/authors/rfc9711-diff.html 
> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
> https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html 
> <https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html> (side by side)
> 
> 
> Best regards,
> RFC Editor/kc
> 
> 
> 
> 
> 
> 
> 
> 
>> On Feb 7, 2025, at 7:37 AM, Giridhar Mandyam <giridhar.mand...@gmail.com 
>> <mailto:giridhar.mand...@gmail.com>> wrote:
>> 
>> Dear RFC Ed,
>> Enclosed are the editors' latest responses. We think we are ready to publish 
>> after the enclosed changes are made. Thanks for all of your patience, and 
>> your efforts in getting this document together.
>> 
>> -Giri
>> 
>> On Wed, Feb 5, 2025 at 2:08 PM Karen Moore <kmo...@staff.rfc-editor.org 
>> <mailto:kmo...@staff.rfc-editor.org>> wrote:
>> Dear Giri,
>> 
>> Thank you for providing the document that outlines Round 3 of the authors’ 
>> suggested changes. These updates are now reflected in our files. Please 
>> review carefully (especially changes to the JSON examples), and let us know 
>> if any further changes are needed. We have some additional questions.
>> 
>> 1) We have not heard back from you yet regarding the following. Please 
>> confirm if we may remove the quote marks from the terms listed in the JWT 
>> Claim Name fields in Section 10.2 per IANA’s preference. If you have any 
>> questions for IANA about this change, please let us know (as we have now 
>> removed IANA from this thread).
>> 
>>> 1) Based on discussion with IANA, they prefer that the document match the 
>>> "CBOR Web Token (CWT) Claims" registry (i.e., no quotation marks in the JWT 
>>> Claim Name fields in Section 10.2; see the registry at 
>>> <https://www.iana.org/assignments/cwt> 
>>> <https://www.iana.org/assignments/cwt&gt;>). We are CCing IANA on this 
>>> thread in case you have questions. If none, we will update Section 10.2 per 
>>> their preference.
>>> 
>>>> b) Section 10.2. May we remove all quote marks from the JWT Claim Name
>>>> fields? We note that quote marks are not used in the "CBOR Web Token
>>>> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> 
>>>> <https://www.iana.org/assignments/cwt&gt;>.
>>>> For example:
>>>> OLD: JWT Claim Name: "eat_nonce"
>>>> NEW: JWT Claim Name: eat_nonce
>>>> 
>>>> EDITORS’ RESPONSE: Original text should not be changed. Please revert.
>> 
>> 2) Regarding the pointer to the EAT WG GitHub repository, we changed the 
>> link to a citation per guidance in our online style guide (see "Referencing 
>> Web-Based Public Code Repositories (e.g., GitHub)” at 
>> <https://www.rfc-editor.org/styleguide/part2/> 
>> <https://www.rfc-editor.org/styleguide/part2/&gt;>). Please let us know if 
>> any additional updates are needed.
>> 
>> Original:
>> See https://github.com/ietf-rats-wg/eat 
>> <https://github.com/ietf-rats-wg/eat> for additional information and stub 
>> files, when
>> using the CDDL presented in this section to validate EAT protocol
>> messages.
>> 
>> Current:
>> See [EAT-GitHub] for additional information and stub files, when
>> using the CDDL presented in this section to validate EAT protocol
>> messages.
>> 
>> Informative References Entry:
>> [EAT-GitHub]
>> "Entity Attestation Token IETF Draft Standard", 
>> commit 62c726b, January 2024,
>> <https://github.com/ietf-rats-wg/eat> 
>> <https://github.com/ietf-rats-wg/eat&gt;>.
>> 
>> —Files (please refresh)— 
>> 
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9711.xml 
>> <https://www.rfc-editor.org/authors/rfc9711.xml>
>> 
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9711.txt 
>> <https://www.rfc-editor.org/authors/rfc9711.txt>
>> https://www.rfc-editor.org/authors/rfc9711.pdf 
>> <https://www.rfc-editor.org/authors/rfc9711.pdf>
>> https://www.rfc-editor.org/authors/rfc9711.html 
>> <https://www.rfc-editor.org/authors/rfc9711.html>
>> 
>> These diff files show all changes made during AUTH48:
>> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
>> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>
>> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html 
>> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by 
>> side)
>> 
>> This diff file shows all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9711-diff.html 
>> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
>> 
>> Best regards,
>> RFC Editor/kc
>> 
>>> On Jan 28, 2025, at 11:44 AM, Karen Moore <kmo...@staff.rfc-editor.org 
>>> <mailto:kmo...@staff.rfc-editor.org>> wrote:
>>> 
>>> Dear Giri,
>>> 
>>> We have updated our files with the proposed changes provided on January 
>>> 25th. Please review the updates (especially changes to the sourcecode to 
>>> ensure we captured all edits correctly) and let us know if any further 
>>> changes are needed. Note that we have an additional clarification below.
>>> 
>>> 1) Based on discussion with IANA, they prefer that the document match the 
>>> "CBOR Web Token (CWT) Claims" registry (i.e., no quotation marks in the JWT 
>>> Claim Name fields in Section 10.2; see the registry at 
>>> <https://www.iana.org/assignments/cwt> 
>>> <https://www.iana.org/assignments/cwt&gt;>). We are CCing IANA on this 
>>> thread in case you have questions. If none, we will update Section 10.2 per 
>>> their preference.
>>> 
>>>> b) Section 10.2. May we remove all quote marks from the JWT Claim Name
>>>> fields? We note that quote marks are not used in the "CBOR Web Token
>>>> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> 
>>>> <https://www.iana.org/assignments/cwt&gt;>.
>>>> For example:
>>>> OLD: JWT Claim Name: "eat_nonce"
>>>> NEW: JWT Claim Name: eat_nonce
>>>> 
>>>> EDITORS’ RESPONSE: Original text should not be changed. Please revert.
>>> 
>>> 
>>> 
>>> —Files (please refresh)— 
>>> 
>>> The updated XML file is here:
>>> https://www.rfc-editor.org/authors/rfc9711.xml 
>>> <https://www.rfc-editor.org/authors/rfc9711.xml>
>>> 
>>> The updated output files are here:
>>> https://www.rfc-editor.org/authors/rfc9711.txt 
>>> <https://www.rfc-editor.org/authors/rfc9711.txt>
>>> https://www.rfc-editor.org/authors/rfc9711.pdf 
>>> <https://www.rfc-editor.org/authors/rfc9711.pdf>
>>> https://www.rfc-editor.org/authors/rfc9711.html 
>>> <https://www.rfc-editor.org/authors/rfc9711.html>
>>> 
>>> These diff files show only the changes made during the last edit round:
>>> https://www.rfc-editor.org/authors/rfc9711-lastdiff.html 
>>> <https://www.rfc-editor.org/authors/rfc9711-lastdiff.html>
>>> https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html 
>>> <https://www.rfc-editor.org/authors/rfc9711-lastrfcdiff.html> (side by side)
>>> 
>>> These diff files show all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
>>> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>
>>> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html 
>>> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by 
>>> side)
>>> 
>>> This diff file shows all changes made to date:
>>> https://www.rfc-editor.org/authors/rfc9711-diff.html 
>>> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9711 
>>> <https://www.rfc-editor.org/auth48/rfc9711>
>>> 
>>> Best regards,
>>> RFC Editor/kc
>>> 
>>> 
>>>> From: Karen Moore <kmo...@staff.rfc-editor.org 
>>>> <mailto:kmo...@staff.rfc-editor.org>>
>>>> Subject: Re: [auth48] AUTH48: RFC-to-be 9711 <draft-ietf-rats-eat-31> for 
>>>> your review
>>>> Date: January 27, 2025 at 2:54:40 PM PST
>>>> To: "lgl securitytheory.com" <l...@securitytheory.com 
>>>> <mailto:l...@securitytheory.com>>, Giridhar Mandyam 
>>>> <giridhar.mand...@gmail.com <mailto:giridhar.mand...@gmail.com>>, Carl 
>>>> Wallace <c...@redhoundsoftware.com <mailto:c...@redhoundsoftware.com>>, 
>>>> Jeremy O'Donoghue <jodon...@qti.qualcomm.com 
>>>> <mailto:jodon...@qti.qualcomm.com>>
>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org 
>>>> <mailto:rfc-edi...@rfc-editor.org>>, "rats-...@ietf.org 
>>>> <mailto:rats-...@ietf.org>" <rats-...@ietf.org 
>>>> <mailto:rats-...@ietf.org>>, rats-chairs <rats-cha...@ietf.org 
>>>> <mailto:rats-cha...@ietf.org>>, "Smith, Ned" <ned.sm...@intel.com 
>>>> <mailto:ned.sm...@intel.com>>, Roman Danyliw <r...@cert.org 
>>>> <mailto:r...@cert.org>>, auth48archive <auth48archive@rfc-editor.org 
>>>> <mailto:auth48archive@rfc-editor.org>>
>>>> 
>>>> Dear Giri and *Laurence,
>>>> 
>>>> Thank you for providing the document that outlines further suggested 
>>>> changes; we are working on the updates and will get back to you shortly.
>>>> 
>>>> *Laurence, we have updated our files to reflect changes based on the 
>>>> responses provided by Giri on January 22nd. We have not incorporated the 
>>>> changes yet that Giri sent on January 25th. While we are working on 
>>>> incorporating those updates, please visit our mail archive to catch up on 
>>>> any email correspondence you may have missed at 
>>>> <https://mailarchive.ietf.org/arch/search/?q=rfc9711>. You 
>>>> <https://mailarchive.ietf.org/arch/search/?q=rfc9711&gt;.&nbsp;&nbsp;You> 
>>>> can also view the changes that have been made to date by accessing the 
>>>> files below. Should you have any questions, please let us know.
>>>> 
>>>> —Files (please refresh)— 
>>>> 
>>>> The updated XML file is here:
>>>> https://www.rfc-editor.org/authors/rfc9711.xml 
>>>> <https://www.rfc-editor.org/authors/rfc9711.xml>
>>>> 
>>>> The updated output files are here:
>>>> https://www.rfc-editor.org/authors/rfc9711.txt 
>>>> <https://www.rfc-editor.org/authors/rfc9711.txt>
>>>> https://www.rfc-editor.org/authors/rfc9711.pdf 
>>>> <https://www.rfc-editor.org/authors/rfc9711.pdf>
>>>> https://www.rfc-editor.org/authors/rfc9711.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711.html>
>>>> 
>>>> These diff files show all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>
>>>> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by 
>>>> side)
>>>> 
>>>> This diff file shows all changes made to date:
>>>> https://www.rfc-editor.org/authors/rfc9711-diff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
>>>> 
>>>> Best regards,
>>>> RFC Editor/kc
>>>> 
>>>> 
>>>> On Jan 27, 2025, at 9:55 AM, lgl securitytheory.com 
>>>> <l...@securitytheory.com <mailto:l...@securitytheory.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I’m a little confused about the status here. Has the RFC Editor processed 
>>>> everything so that all proposed changes appear in the AUTH48 diff? 
>>>> 
>>>> I am waiting for that to happen before I do a review of those changes.
>>>> 
>>>> Also, I’m not sure the Jan 22 email from Karen Moore was sent to me. I 
>>>> can’t find it in my inbox.
>>>> 
>>>> LL
>>>> 
>>>> 
>>>> On Jan 25, 2025, at 10:50 AM, Giridhar Mandyam <giridhar.mand...@gmail.com 
>>>> <mailto:giridhar.mand...@gmail.com>> wrote:
>>>> 
>>>> Thanks for the quick response. Enclosed please find the editors' response. 
>>>> Note that in the process of re-validation of CDDL and cbor.diag examples 
>>>> based on the last round of revisions, we encountered some changes that 
>>>> need to be made in the document. Sorry about this, but the CDDL validator 
>>>> that is in widespread use in the IETF has been evolving.
>>>> 
>>>> -Giri
>>>> 
>>>> On Wed, Jan 22, 2025 at 4:43 PM Karen Moore <kmo...@staff.rfc-editor.org 
>>>> <mailto:kmo...@staff.rfc-editor.org>> wrote:
>>>> Dear Giri,
>>>> 
>>>> Thank you for your review and detailed reply. We have updated our files 
>>>> based on your responses. Please see some additional 
>>>> questions/clarifications below.
>>>> 
>>>> 1) In Section 10.5, we updated “Integer" to “Value”; however, there is 
>>>> still a mismatch with this document and the columns in the IANA registry. 
>>>> In the "Entity Attestation Token (EAT) Intended Uses” registry 
>>>> (https://www.iana.org/assignments/rats/rats.xhtml 
>>>> <https://www.iana.org/assignments/rats/rats.xhtml>), the columns are 
>>>> “Value”, Description”, and “Reference”, but this document lists “Value”, 
>>>> “Name”, and “Description”. Should this document be updated as follows to 
>>>> match the registry?
>>>> 
>>>> Current:
>>>> The three columns for the registry are:
>>>> 
>>>> 1. Value: This is a unique integer that is used to identify the
>>>> intended use in CBOR-encoded tokens.
>>>> 
>>>> 2. Name: This is unique short descriptive string that is used to
>>>> identify the use in JSON-encoded tokens.
>>>> 
>>>> 3. Description: This is one or more text paragraphs that
>>>> sufficiently define what the intended use means. It may also be
>>>> a reference to another document.
>>>> 
>>>> Perhaps:
>>>> 1. Value: This is a unique integer that is used to identify the
>>>> intended use in CBOR-encoded tokens.
>>>> 
>>>> 2. Description: This is one or more text paragraphs that
>>>> sufficiently define what the intended use means. It may also be
>>>> a reference to another document.
>>>> 
>>>> 3. Reference: This field contains a reference to the defining 
>>>> specification.
>>>> 
>>>> #27 g) Section 10.5. The columns for the "Entity Attestation Token
>>>> (EAT) Intended Uses" registry are "Integer", "Name", and 
>>>> "Description" in this document, but "Value", "Description", and 
>>>> "Reference" in the IANA registry <https://www.iana.org/assignments/rats> 
>>>> <https://www.iana.org/assignments/rats&gt;>. 
>>>> Which one is correct? If the IANA registry is correct, please provide
>>>> updated text for Section 10.5 where it describes the three columns.
>>>> 
>>>> 
>>>> [EDITORS’ RESPONSE]: Please make change as below to synchronize the EAT 
>>>> text with the IANA registry:
>>>> 
>>>> ORIGINAL:
>>>> Integer: This is a unique integer used to identify the intended use in 
>>>> CBOR-encoded tokens.
>>>> 
>>>> NEW:
>>>> Value: This is a unique integer used to identify the intended use in 
>>>> CBOR-encoded tokens.
>>>> 
>>>> 
>>>> 2) Please note that we made the following change (“use cases” instead of 
>>>> “use case”). Please let us know if this update is acceptable.
>>>> 
>>>> Original:
>>>> However, EAT is intended for use in low-security use cases
>>>> the same as high-security use case.
>>>> 
>>>> Current:
>>>> However, EAT is intended for use in low-security use cases
>>>> the same as high-security use cases.
>>>> 
>>>> 3) Per your explanation, we left “detached EAT bundle” as lowercase, and 
>>>> we made one capitalized instance lowercase for consistency (see Section 
>>>> 4.2.18). If this is incorrect, please let us know.
>>>> 
>>>> —Files— 
>>>> 
>>>> The updated XML file is here:
>>>> https://www.rfc-editor.org/authors/rfc9711.xml 
>>>> <https://www.rfc-editor.org/authors/rfc9711.xml>
>>>> 
>>>> The updated output files are here:
>>>> https://www.rfc-editor.org/authors/rfc9711.txt 
>>>> <https://www.rfc-editor.org/authors/rfc9711.txt>
>>>> https://www.rfc-editor.org/authors/rfc9711.pdf 
>>>> <https://www.rfc-editor.org/authors/rfc9711.pdf>
>>>> https://www.rfc-editor.org/authors/rfc9711.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711.html>
>>>> 
>>>> These diff files show all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9711-auth48diff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-auth48diff.html>
>>>> https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-auth48rfcdiff.html> (side by 
>>>> side)
>>>> 
>>>> This diff file shows all changes made to date:
>>>> https://www.rfc-editor.org/authors/rfc9711-diff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
>>>> 
>>>> Note that it may be necessary for you to refresh your browser to view the 
>>>> most recent version. Please review the document carefully to ensure 
>>>> satisfaction as we do not make changes once it has been published as an 
>>>> RFC.
>>>> 
>>>> Please contact us with any further updates or with your approval of the 
>>>> document in its current form. We will await approvals from each author 
>>>> prior to moving forward in the publication process.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9711 
>>>> <https://www.rfc-editor.org/auth48/rfc9711>
>>>> 
>>>> Thank you,
>>>> RFC Editor/kc
>>>> 
>>>> 
>>>> On Jan 22, 2025, at 7:54 AM, Giridhar Mandyam via auth48archive 
>>>> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> wrote:
>>>> 
>>>> Please see enclosed. These are the consolidated editors' responses.
>>>> 
>>>> -Giri Mandyam
>>>> 
>>>> 
>>>> 
>>>> On Jan 13, 2025, at 8:49 PM, RFC Editor via auth48archive 
>>>> <auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>> wrote:
>>>> 
>>>> Authors,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>>> the following questions, which are also in the XML file.
>>>> 
>>>> 1) <!--[rfced] Section 1. FYI - We expanded the first mentions of "ueid"
>>>> and "oemid" as shown below. Please let us know if this is not accurate.
>>>> 
>>>> Original:
>>>> The ueid is
>>>> effectively a serial number uniquely identifying the device. This
>>>> ueid is the base64url encoding of a 48-bit MAC address preceded by 
>>>> the type byte 0x02. The oemid identifies the manufacturer using a 
>>>> Private Enterprise Number [PEN]. 
>>>> 
>>>> Current:
>>>> The ueid (Universal Entity ID) is
>>>> effectively a serial number uniquely identifying the device. This
>>>> ueid is the base64url encoding of a 48-bit Media Access Control (MAC)
>>>> address preceded by the type byte 0x02. The oemid (Hardware OEM ID) 
>>>> identifies the manufacturer using a Private Enterprise Number (PEN) [PEN]. 
>>>> --> 
>>>> 
>>>> 
>>>> 2) <!--[rfced] Section 1.2. Please clarify the latter part of this
>>>> sentence. Is the intended meaning that EAT is not used for
>>>> specific token definition as shown below?
>>>> 
>>>> Original:
>>>> EAT is a framework for defining attestation tokens for specific use
>>>> cases, not a specific token definition.
>>>> 
>>>> Perhaps:
>>>> EAT is a framework that is used for defining attestation tokens for 
>>>> specific use cases; it is not used for specific token definition.
>>>> -->
>>>> 
>>>> 
>>>> 3) <!--[rfced] Sections 1.2 and 4.2.18. The term "follow-on documents"
>>>> hasn't been used since early RFCs. Would it be clearer to say
>>>> "subsequent documents" as shown below? Note that there are 2 instances.
>>>> 
>>>> Original:
>>>> Finally, the notion of an EAT profile is introduced that facilitates
>>>> the creation of narrowed definitions of EATs for specific use cases in
>>>> follow-on documents. 
>>>> [...]
>>>> 
>>>> Nested tokens can be one of three types as defined in this document or 
>>>> types standardized in follow-on documents (e.g., [UCCS]).
>>>> 
>>>> Perhaps:
>>>> Finally, this document introduces the notion of an EAT profile that 
>>>> facilitates the creation of narrowed definitions of EATs for 
>>>> specific use cases in subsequent documents. 
>>>> [...]
>>>> 
>>>> Nested tokens can be one of three types as defined in this document or 
>>>> types that are standardized in subsequent documents (e.g., [UCCS]).
>>>> -->
>>>> 
>>>> 
>>>> 4) <!--[rfced] Section 2. We note that RFC 7515 (Section 2) defines 
>>>> "base64url encoding" rather than "base64url encoded". Would you 
>>>> like to update the terminology list to match RFC 7515, or is this 
>>>> variance okay?
>>>> 
>>>> Original:
>>>> base64url-encoded: base64url-encoded is as described in [RFC7515],
>>>> i.e., using URL- and filename-safe character set [RFC4648] with
>>>> all trailing '=' characters omitted and without the inclusion of
>>>> any line breaks, whitespace, or other additional characters.
>>>> 
>>>> Perhaps:
>>>> base64url encoding: As defined in [RFC7515], base64 encoding 
>>>> uses a URL- and filename-safe character set [RFC4648] with 
>>>> all trailing '=' characters omitted and without the 
>>>> inclusion of any line breaks, whitespace, or other additional 
>>>> characters.
>>>> -->
>>>> 
>>>> 
>>>> 5) <!--[rfced] Section 2. We added a citation to RFC 9052 for "COSE" for 
>>>> easy
>>>> reference. If that is not correct or desired, please let us know.
>>>> 
>>>> Original:
>>>> Claim Key: The CBOR map key used to identify a claim. (The term
>>>> "Claim Key" comes from CWT. This document, like COSE, uses the
>>>> term "label" to refer to CBOR map keys to avoid confusion with
>>>> cryptographic keys.)
>>>> 
>>>> Current:
>>>> Claim Key: The CBOR map key used to identify a claim. (The term
>>>> "Claim Key" comes from CWT. This document, like COSE [RFC9052], 
>>>> uses the term "label" to refer to CBOR map keys to avoid 
>>>> confusion with cryptographic keys.)
>>>> -->
>>>> 
>>>> 
>>>> 6) <!--[rfced] Section 4. Can "of most of what is defined" be rephrased
>>>> for clarity as shown below?
>>>> 
>>>> Original:
>>>> This specification includes a CDDL definition of most of what is
>>>> defined in [RFC8392]. Similarly, this specification includes CDDL
>>>> for most of what is defined in [RFC7519].
>>>> 
>>>> Perhaps:
>>>> This specification includes a CDDL definition that is based on the 
>>>> CDDL definitions in [RFC8392] and [RFC7519].
>>>> -->
>>>> 
>>>> 
>>>> 7) <!--[rfced] Section Titles
>>>> 
>>>> a) Should the title of Section 4.2.2 be updated as shown
>>>> below (i.e., remove "(SUEIDs)") for consistency with the
>>>> other section titles? (See the separate question re: removing
>>>> the hyphen in 'semipermanent'.)
>>>> 
>>>> Original:
>>>> 4.2.1. ueid (Universal Entity ID) Claim
>>>> 4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs)
>>>> 
>>>> Perhaps:
>>>> 4.2.1. ueid (Universal Entity ID) Claim
>>>> 4.2.2. sueids (Semipermanent UEIDs) Claim
>>>> 
>>>> ...
>>>> b) Should the title of Section 4.2.18 contain "Claim" for 
>>>> consistency?
>>>> 
>>>> Original:
>>>> 4.2.16. measurements (Measurements) Claim
>>>> 4.2.17. measres (Software Measurement Results) Claim
>>>> 4.2.18 submods (Submodules)
>>>> 
>>>> Perhaps:
>>>> 4.2.16. measurements (Measurements) Claim
>>>> 4.2.17. measres (Software Measurement Results) Claim
>>>> 4.2.18 submods (Submodules) Claim
>>>> -->
>>>> 
>>>> 
>>>> 8) <!--[rfced] Section 4.2.3.2. Please clarify what "these" refers to in
>>>> "Many companies already have purchased one of these" (last sentence).
>>>> 
>>>> Original:
>>>> The IEEE operates a global registry for MAC addresses and company
>>>> IDs. This claim uses that database to identify OEMs. The contents
>>>> of the claim may be either an IEEE MA-L, MA-M, MA-S, or CID
>>>> [IEEE-RA]. An MA-L, formerly known as an OUI, is a 24-bit value used
>>>> as the first half of a MAC address. Similarly, MA-M is a 28-bit
>>>> value used as the first part of a MAC address, and MA-S, formerly
>>>> known as OUI-36, is a 36-bit value. Many companies already have
>>>> purchased one of these.
>>>> -->
>>>> 
>>>> 
>>>> 9) <!--[rfced] Section 4.2.3.3. This sentence cites the application 
>>>> for PENs (https://pen.iana.org/pen/PenApplication.page 
>>>> <https://pen.iana.org/pen/PenApplication.page>), so it seems 
>>>> either the text or the reference should be updated. Which do you prefer?
>>>> 
>>>> Original:
>>>> IANA maintains a registry for Private Enterprise Numbers [PEN].
>>>> 
>>>> where
>>>> [PEN] "Private Enterprise Number (PEN) Request", n.d.,
>>>> <https://pen.iana.org/pen/PenApplication.page> 
>>>> <https://pen.iana.org/pen/PenApplication.page&gt;>.
>>>> 
>>>> 
>>>> Option A (if the reference remains the same):
>>>> IANA maintains the application for Private Enterprise
>>>> Numbers [PEN].
>>>> 
>>>> Option B (if the reference is changed to the registry itself):
>>>> 
>>>> IANA maintains a registry for Private Enterprise Numbers [PEN]. 
>>>> 
>>>> where:
>>>> [PEN] IANA, "Private Enterprise Numbers (PENs)", 
>>>> <https://www.iana.org/assignments/enterprise-numbers/> 
>>>> <https://www.iana.org/assignments/enterprise-numbers/&gt;>.
>>>> -->
>>>> 
>>>> 
>>>> 10) <!--[rfced] Section 4.2.7. A word is missing after "may be". Please
>>>> confirm if "used" is the correct word as shown below.
>>>> 
>>>> Original:
>>>> The "manifests" claim Section 4.2.15 may be instead if this is too
>>>> simple.
>>>> 
>>>> Current:
>>>> The "manifests" claim (Section 4.2.15) may be used instead if this 
>>>> is too simple.
>>>> -->
>>>> 
>>>> 
>>>> 11) <!-- [rfced] Section 4.2.10. We notice that [W3C.GeoLoc] is listed as
>>>> an informative reference, whereas [WGS84] is a normative
>>>> reference. Considering the key word "MUST" in this sentence,
>>>> should [W3C.GeoLoc] be listed as a normative reference?
>>>> 
>>>> Original:
>>>> Latitude, longitude, altitude, accuracy, altitude-accuracy, 
>>>> heading and speed MUST be as defined in the W3C Geolocation
>>>> API [W3C.GeoLoc] (which, in turn, is based on [WGS84]).
>>>> -->
>>>> 
>>>> 
>>>> 12) <!--[rfced] Section 4.2.10. With the expansion of "GNSS", 
>>>> should this be rephrased?
>>>> 
>>>> Original:
>>>> For example, it might have been minutes or hours or more
>>>> since the last contact with a GNSS satellite. 
>>>> 
>>>> Current:
>>>> For example, it might have been minutes, hours, or more
>>>> since the last contact with a Global Navigation Satellite 
>>>> System (GNSS) satellite. 
>>>> 
>>>> Perhaps:
>>>> For example, it might have been minutes, hours, or more
>>>> since the last contact with a satellite in the Global 
>>>> Navigation Satellite System (GNSS). 
>>>> -->
>>>> 
>>>> 
>>>> 13) <!--[rfced] Section 4.2.15. Should the word 'tag' be added here,
>>>> as the term 'SWID tag' is used in RFC 9393?
>>>> 
>>>> Original:
>>>> For example, the manifest may be a CBOR-encoded CoSWID, an 
>>>> XML-encoded SWID or other.
>>>> 
>>>> Current:
>>>> For example, the manifest may be a CBOR-encoded CoSWID, an 
>>>> XML-encoded Software Identification (SWID), or other.
>>>> 
>>>> Perhaps:
>>>> For example, the manifest may be a CBOR-encoded CoSWID, an 
>>>> XML-encoded Software Identification (SWID) tag, or other.
>>>> -->
>>>> 
>>>> 
>>>> 14) <!--[rfced] Sections 4.2.15 and 4.2.16. RFC 7252 uses Content-Format
>>>> "identifier" rather than "integer". Given this, should "integer"
>>>> be removed or replaced with "identifier" as shown below for
>>>> consistency (3 instances)?
>>>> 
>>>> Original:
>>>> Identification of the type of manifest is always by a Constrained
>>>> Application Protocol (CoAP) Content-Format integer [RFC7252].
>>>> 
>>>> The first item in the array of two MUST be an integer CoAP 
>>>> Content-Format identifier. 
>>>> 
>>>> The identification of format is by CoAP Content Format, the same as 
>>>> the "manifests" claim in Section 4.2.15.
>>>> 
>>>> Perhaps:
>>>> Identification of the type of manifest is always by a Constrained
>>>> Application Protocol (CoAP) Content-Format identifier [RFC7252].
>>>> 
>>>> The first item in the array of two MUST be a CoAP Content-Format 
>>>> identifier. 
>>>> 
>>>> The format is identified by a CoAP Content-Format identifier, which 
>>>> is the same for the "manifests" claim in Section 4.2.15.
>>>> -->
>>>> 
>>>> 
>>>> 15) <!--[rfced] Section 4.2.16. What words are missing after "a"? 
>>>> 
>>>> Original:
>>>> This claim can be a [RFC9393].
>>>> 
>>>> Perhaps:
>>>> This claim can be a CoSWID [RFC9393].
>>>> -->
>>>> 
>>>> 
>>>> 16) <!--[rfced] Section 4.2.17. Should the terms/values listed in these
>>>> two paragraphs match for consistency as shown below? 
>>>> 
>>>> Also, 'success/fail' or 'success/failure' is a corresponding pair 
>>>> rather than 'successful/fail'. (If this is updated, seemingly the 
>>>> CDDL below and in Section 7.3.1 would also need an update, e.g., 
>>>> 'comparison-successful'.)
>>>> 
>>>> Current:
>>>> This claim provides a simple standard way to report the result 
>>>> of a comparison as success, failure, fail to run, and absence.
>>>> 
>>>> 
>>>> 1 - comparison successful: The comparison to reference values was
>>>> successful.
>>>> 
>>>> 2 - comparison fail: The comparison was completed but did not
>>>> compare correctly to the reference values.
>>>> 
>>>> 3 - comparison not run: The comparison was not run. This includes
>>>> error conditions such as running out of memory.
>>>> 
>>>> 4 - measurement absent: The particular measurement was not
>>>> available for comparison.
>>>> 
>>>> Perhaps:
>>>> This claim provides a simple standard way to report the result 
>>>> of a comparison as a success, a failure, not run, or absent.
>>>> 
>>>> 
>>>> 1 - comparison success: The comparison to reference values was
>>>> successful.
>>>> 
>>>> 2 - comparison failure: The comparison was completed but did not
>>>> compare correctly to the reference values.
>>>> 
>>>> 3 - comparison not run: The comparison was not run. This includes
>>>> error conditions such as running out of memory.
>>>> 
>>>> 4 - measurement absent: The particular measurement was not
>>>> available for comparison.
>>>> --> 
>>>> 
>>>> 
>>>> 17) <!--[rfced] Sections 4.2.18.1 and 4.2.18.3. Would it be correct to say
>>>> that the keys (or no keys) are distinct from the surrounding
>>>> token produced by the attester? 
>>>> 
>>>> Original:
>>>> The Claims-Set type provides a means of representing claims from a
>>>> submodule that does not have its own attesting environment, i.e., it
>>>> has no keys distinct from the attester producing the surrounding
>>>> token. 
>>>> 
>>>> The CBOR-Nested-Token and JSON-Selector types provide a means of
>>>> representing claims from a submodule that has its own attesting
>>>> environment, i.e., it has keys distinct from the attester producing
>>>> the surrounding token. 
>>>> 
>>>> Perhaps:
>>>> The Claims-Set type provides a means of representing claims from a
>>>> submodule that does not have its own attesting environment, i.e., it
>>>> has no keys that are distinct from the surrounding token produced by 
>>>> the attester.
>>>> 
>>>> The CBOR-Nested-Token and JSON-Selector types provide a means of
>>>> representing claims from a submodule that has its own attesting
>>>> environment, i.e., it has keys that are distinct from the 
>>>> surrounding token produced by the attester. 
>>>> -->
>>>> 
>>>> 
>>>> 18) <!--[rfced] Section 4.2.18.2. We updated this sentence to clarify
>>>> "is directly". If it changes the intended meaning, please let us know.
>>>> 
>>>> Original:
>>>> The input to the digest algorithm is directly the CBOR or 
>>>> JSON-encoded Claims-Set for the submodule. 
>>>> 
>>>> Current:
>>>> The direct input to the digest algorithm is either the 
>>>> CBOR-encoded or the JSON-encoded Claims-Set for the 
>>>> submodule. 
>>>> -->
>>>> 
>>>> 
>>>> 19) <!--[rfced] Section 6.3.9. FYI, "end-end" has been updated to 
>>>> "end-to-end".
>>>> (This is similar to a change that was made in version 31 of the original.)
>>>> 
>>>> Original:
>>>> While not always possible, a profile should specify or make reference
>>>> to, a full end-end specification for key identification. 
>>>> 
>>>> Current:
>>>> While not always possible, a profile should specify, or make reference
>>>> to, a full end-to-end specification for key identification. 
>>>> -->
>>>> 
>>>> 
>>>> 20) <!--[rfced] Section 6.3.12. The text mentions the measurement and
>>>> measurements claims; however, Section 4.2.16 only refers to the
>>>> "measurements" claim. Should "claims" perhaps be singular, or
>>>> should "measurement" be removed or updated (perhaps "measres"
>>>> claim was intended)?
>>>> 
>>>> Original:
>>>> The "manifests" claim (Section 4.2.15) along with the
>>>> measurement and "measurements" (Section 4.2.16) claims are examples
>>>> of this, allowing the use of CoSWID and other formats. 
>>>> 
>>>> Perhaps:
>>>> The "manifests" claim (Section 4.2.15) along with the 
>>>> "measurements" claim (Section 4.2.16) and "measres" claim (Section 4.2.17) 
>>>> are examples of this, allowing the use of CoSWID and other formats.
>>>> -->
>>>> 
>>>> 
>>>> 21) <!--[rfced] Section 6.3.12. FYI - We updated the following text as the
>>>> second sentence is a fragment. If this changes the intended
>>>> meaning, please let us know.
>>>> 
>>>> Original:
>>>> For example, there are variations in the CoSWID format. A profile 
>>>> that require the receiver to accept all variations that are allowed 
>>>> to be sent.
>>>> 
>>>> Current:
>>>> For example, there are variations in the CoSWID format, such as a profile 
>>>> that requires the receiver to accept all variations that are allowed 
>>>> to be sent.
>>>> -->
>>>> 
>>>> 
>>>> 22) <!--[rfced] Section 7.1. This sentence mentions that CDDL for the
>>>> seven claims is included "here". Please clarify what "here"
>>>> refers to - is it referring to Section 7.1 or to one of the
>>>> subsections?
>>>> 
>>>> Original:
>>>> CDDL for the seven claims defined by [RFC8392] and [RFC7519] is
>>>> included here.
>>>> 
>>>> Perhaps:
>>>> CDDL for the seven claims defined by [RFC8392] and [RFC7519] is
>>>> also specified in this document.
>>>> -->
>>>> 
>>>> 
>>>> 23) <!--[rfced] Section 7.2. What does "This" refer to - is it "The
>>>> following subsections" as shown below?
>>>> 
>>>> Current:
>>>> 7.2. Encoding Data Types
>>>> 
>>>> This makes use of the types defined in "Standard Prelude" 
>>>> (Appendix D of [RFC8610]).
>>>> 
>>>> Perhaps:
>>>> 7.2. Encoding Data Types
>>>> 
>>>> The following subsections use the types defined in 
>>>> "Standard Prelude" (Appendix D of [RFC8610]).
>>>> -->
>>>> 
>>>> 
>>>> 24) <!--[rfced] Section 7.3.1. This sentence does not parse - is "use"
>>>> perhaps missing after the comma? Please let us know how we may
>>>> update for clarity.
>>>> 
>>>> Original:
>>>> When there is variation between CBOR and JSON, the
>>>> JC<> CDDL generic defined in Appendix D. 
>>>> 
>>>> Perhaps:
>>>> When there is variation between CBOR and JSON, use the
>>>> JC<> CDDL generic defined in Appendix D. 
>>>> -->
>>>> 
>>>> 
>>>> 25) <!--[rfced] Section 9.1. The following text does not parse
>>>> (specifically, the latter part after the comma). Please let us
>>>> know how we may update for clarity.
>>>> 
>>>> Original:
>>>> For example, this document says that a UEID is permanent and that it
>>>> must not change, but it does not say what degree of attack to change
>>>> it must be defended.
>>>> 
>>>> Perhaps:
>>>> For example, this document states that a UEID is permanent and that it
>>>> must not change, but it does not state if change is needed to defend 
>>>> against a certain degree of attack.
>>>> -->
>>>> 
>>>> 
>>>> 26) <!--[rfced] Section 10.2. Is this sentence necessary? 
>>>> 
>>>> Original:
>>>> The "Claim Value 
>>>> Type(s)" here all name CDDL definitions and are only for the CWT
>>>> registry.
>>>> 
>>>> It seems redundant with this text in the preceding paragraph:
>>>> 
>>>> The "Claim Key" and "Claim Value Types(s)" are for the CWT registry
>>>> only.
>>>> -->
>>>> 
>>>> 
>>>> 27) <!--[rfced] Below are questions about the IANA-related text. 
>>>> In addition to responding to these questions, please review 
>>>> all of the IANA-related updates carefully and let us know
>>>> if any further updates are needed.
>>>> 
>>>> a) Section 4.2.18.2. Please clarify which IANA registry is
>>>> being referred to in the last sentence (i.e., the "JOSE Algorithm
>>>> registry"). Is it the "JSON Web Signature and Encryption
>>>> Algorithms" registry <https://www.iana.org/assignments/jose/>? 
>>>> <https://www.iana.org/assignments/jose/&gt;?>
>>>> 
>>>> Original:
>>>> The hash algorithm identifier is always from the COSE
>>>> Algorithm registry, [IANA.COSE.Algorithms]. Either the integer or
>>>> string identifier may be used. The hash algorithm identifier is
>>>> never from the JOSE Algorithm registry.
>>>> 
>>>> Perhaps:
>>>> The hash algorithm identifier is always from the "COSE Algorithms" 
>>>> registry [IANA.COSE.Algorithms]. Either the integer or
>>>> the string identifier may be used. The hash algorithm identifier is
>>>> never from the "JSON Web Signature and Encryption Algorithms" registry.
>>>> 
>>>> b) Section 10.2. May we remove all quote marks from the JWT Claim Name
>>>> fields? We note that quote marks are not used in the "CBOR Web Token 
>>>> (CWT) Claims" registry <https://www.iana.org/assignments/cwt> 
>>>> <https://www.iana.org/assignments/cwt&gt;>.
>>>> For example:
>>>> OLD: JWT Claim Name: "eat_nonce"
>>>> NEW: JWT Claim Name: eat_nonce
>>>> 
>>>> c) Section 10.2. In the "CBOR Web Token (CWT) Claims" registry
>>>> for eat_nonce (Claim Key 10), the Reference field includes "OpenID
>>>> Connect Core 1.0" (https://openid.net/specs/openid-connect-core-1_0.html 
>>>> <https://openid.net/specs/openid-connect-core-1_0.html>), 
>>>> but the Reference field in the draft did not. FYI, this document 
>>>> has been updated to match the registry, and "OpenID Connect Core 1.0" 
>>>> has been added as an informative reference. 
>>>> 
>>>> In the JWT Claims registry, should "eat_nonce" have a matching 
>>>> Reference field? (This document states the Reference fields are 
>>>> "common and equivalent".) If so, we will ask IANA to update the registry
>>>> as follows.
>>>> 
>>>> Old: eat_nonce Nonce [IETF] [RFC-ietf-rats-eat-30]
>>>> New: eat_nonce Nonce [IETF] [OpenID Connect Core 1.0][RFC-ietf-rats-eat-30]
>>>> 
>>>> 
>>>> d) Section 10.2. Regarding "Claim Description" (in both the CWT and JWT
>>>> Claims registries), would you like to update these to remove 'Indicates'
>>>> so they are similar to other descriptions? If so, we will ask IANA to
>>>> update the registries accordingly with any changes made.
>>>> 
>>>> Original:
>>>> ueid The Universal Entity ID
>>>> 
>>>> sueids Semi-permanent UEIDs
>>>> 
>>>> hwmodel Model identifier for hardware
>>>> 
>>>> dbgstat Indicates status of debug facilities
>>>> 
>>>> eat_profile Indicates the EAT profile followed
>>>> 
>>>> intuse Indicates intended use of the EAT
>>>> 
>>>> Perhaps:
>>>> ueid Universal Entity ID
>>>> 
>>>> sueids Semipermanent UEIDs
>>>> 
>>>> hwmodel Model identifier for hardware
>>>> 
>>>> dbgstat The status of debug facilities
>>>> 
>>>> eat_profile The EAT profile followed
>>>> 
>>>> intuse The intended use of the EAT
>>>> 
>>>> e) Section 10.3. In the "DEV URN Subtypes" registry, may we 
>>>> update the descriptions as follows?
>>>> - change "Identifier" to "ID" to match the "JSON Web Token Claims"
>>>> registry, "CBOR Web Token (CWT) Claims" registry, and the running text in
>>>> this document.
>>>> - change "Semi-permanent" to "Semipermanent" per Merriam-Webster 
>>>> (throughout this document and in the two other registries).
>>>> 
>>>> Original:
>>>> ueid Universal Entity Identifier
>>>> sueid Semi-permanent Universal Entity Identifier
>>>> 
>>>> Perhaps:
>>>> ueid Universal Entity ID
>>>> sueid Semipermanent Universal Entity ID
>>>> 
>>>> f) Section 10.4. FYI - In the "CBOR Tags" registry at
>>>> https://www.iana.org/assignments/cbor-tags/ 
>>>> <https://www.iana.org/assignments/cbor-tags/>, the reference to Section 5
>>>> of this document is included under the Semantics column. We will ask
>>>> IANA to update the registry so that "RFC 9711, Section 5" is only
>>>> in the Reference column.
>>>> 
>>>> Original:
>>>> +=====+============+===============================+
>>>> | Tag | Data Items | Semantics |
>>>> +=====+============+===============================+
>>>> | 602 | array | Detached EAT Bundle Section 5 |
>>>> 
>>>> Current:
>>>> +=====+===========+=====================+=====================+
>>>> | Tag | Data Item | Semantics | Reference |
>>>> +=====+===========+=====================+=====================+
>>>> | 602 | array | Detached EAT Bundle | RFC 9711, Section 5 |
>>>> 
>>>> 
>>>> g) Section 10.5. The columns for the "Entity Attestation Token
>>>> (EAT) Intended Uses" registry are "Integer", "Name", and 
>>>> "Description" in this document, but "Value", "Description", and 
>>>> "Reference" in the IANA registry <https://www.iana.org/assignments/rats> 
>>>> <https://www.iana.org/assignments/rats&gt;>. 
>>>> Which one is correct? If the IANA registry is correct, please provide
>>>> updated text for Section 10.5 where it describes the three columns.
>>>> -->
>>>> 
>>>> 
>>>> 28) <!-- [rfced] FYI, a normative reference to RFC 5234 has been added 
>>>> because
>>>> this document contains ABNF. See the IESG statement on "Guidelines for
>>>> the Use of Formal Languages in IETF Specifications"
>>>> (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/
>>>>  
>>>> <https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/>)
>>>>  -
>>>> specifically "The use of a language requires a reference to the
>>>> specification for that language. This reference is normative ..."
>>>> 
>>>> Please review where RFC 5234 is cited and let us know if you prefer
>>>> otherwise. Also, RFC 7405 has been added because "%s" is used.
>>>> 
>>>> Current:
>>>> The ABNF [RFC5234] [RFC7405] for these two URNs is as follows, 
>>>> where b64ueid is the base64url-encoded binary byte string for 
>>>> the UEID or SUEID:
>>>> 
>>>> body =/ ueidbody
>>>> ueidbody = %s"ueid:" b64ueid
>>>> -->
>>>> 
>>>> 
>>>> 29) <!--[rfced] FYI, we updated the URL for this reference because it
>>>> was a direct download of the PDF file. The updated URL points to
>>>> a landing page with more information and the option to download
>>>> the file instead. Please let us know if you prefer otherwise.
>>>> 
>>>> Original:
>>>> [WGS84] National Geospatial-Intelligence Agency (NGA), "WORLD GEODETIC 
>>>> SYSTEM 1984, NGA.STND.0036_1.0.0_WGS84", 8 July 2014,
>>>> <https://earth-info.nga.mil/php/download.php?file=coord-wgs84> 
>>>> <https://earth-info.nga.mil/php/download.php?file=coord-wgs84&gt;>. 
>>>> 
>>>> Current:
>>>> [WGS84] National Geospatial-Intelligence Agency (NGA), "Department
>>>> of Defense World Geodetic System 1984: Its Definition and
>>>> Relationships with Local Geodetic Systems",
>>>> NGA.STND.0036_1.0.0_WGS84, July 2014,
>>>> <https://nsgreg.nga.mil/doc/view?i=4085> 
>>>> <https://nsgreg.nga.mil/doc/view?i=4085&gt;>.
>>>> -->
>>>> 
>>>> 
>>>> 30) <!--[rfced] FYI, we updated this reference to reflect the most current
>>>> version (September 2024). Please let us know if you prefer otherwise.
>>>> 
>>>> Original:
>>>> [ThreeGPP.IMEI]
>>>> 3GPP, "3rd Generation Partnership Project; Technical Specification 
>>>> Group Core Network and Terminals; Numbering, addressing and 
>>>> identification", 2019, <https://portal.3gpp.org/desktopmodules/ 
>>>> <https://portal.3gpp.org/desktopmodules/>
>>>> Specifications/SpecificationDetails.aspx?specificationId=729>. 
>>>> 
>>>> Current:
>>>> [ThreeGPP.IMEI]
>>>> 3GPP, "Numbering, addressing and identification", 3GPP
>>>> TS 23.003, Version 19, September 2024,
>>>> <https://portal.3gpp.org/desktopmodules/Specifications/ 
>>>> <https://portal.3gpp.org/desktopmodules/Specifications/>
>>>> SpecificationDetails.aspx?specificationId=729>.
>>>> --> 
>>>> 
>>>> 
>>>> 31) <!--[rfced] There is a more recent version of this reference
>>>> (September 2024). May we point to that version instead, or do you
>>>> prefer the 2013 (outdated) version?
>>>> 
>>>> Current:
>>>> [W3C.GeoLoc]
>>>> Popescu, A., Ed., "Geolocation API Specification", W3C
>>>> Recommendation, 24 October 2013,
>>>> <https://www.w3.org/TR/2013/REC-geolocation-API- 
>>>> <https://www.w3.org/TR/2013/REC-geolocation-API->
>>>> 20131024/>.
>>>> 
>>>> Perhaps:
>>>> [W3C.GeoLoc]
>>>> Cáceres, M. and R. Grant, "Geolocation", W3C
>>>> Recommendation, September 2024,
>>>> <https://www.w3.org/TR/geolocation/> 
>>>> <https://www.w3.org/TR/geolocation/&gt;>.
>>>> -->
>>>> 
>>>> 
>>>> 32) <!--[rfced] Appendix A. Please review this note and let us know if
>>>> there are any outstanding actions regarding regenerating the examples.
>>>> 
>>>> AUTHOR NOTE:
>>>> RFC Editor: When the IANA values are permanently assigned, please
>>>> contact the authors so the examples can be regenerated. Regeneration
>>>> is required because IANA-assigned values are inside hex and based-64
>>>> encoded data and some of these are signed.
>>>> -->
>>>> 
>>>> 
>>>> 33) <!--[rfced] Questions about the sourcecode
>>>> 
>>>> a) We updated <artwork> to <sourcecode> in Sections 1 and 10.3 as
>>>> well as Appendices A.1.1 - A.2.3 and D. Please confirm that this is
>>>> correct.
>>>> 
>>>> In addition, please consider whether the "type" attribute of any sourcecode
>>>> element should be set and/or has been set correctly.
>>>> 
>>>> The current list of preferred values for "type" is available at
>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> 
>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types&gt;>.
>>>> If the current list does not contain an applicable type, feel free to
>>>> suggest additions for consideration. Note that it is also acceptable
>>>> to leave the "type" attribute not set.
>>>> 
>>>> ...
>>>> Sourcecode in the Appendices
>>>> 
>>>> b) We notice that each sourcecode element in the appendices contains
>>>> introductory text, formatted as a comment within the sourcecode. Should 
>>>> this
>>>> text be moved outside of the sourcecode? If not, please consider the 
>>>> questions
>>>> that follow.
>>>> 
>>>> c) Appendix A.2.1. The text below refers to a section that is 
>>>> outside of the sourcecode. Should a pointer to "Appendix A.1.7
>>>> of RFC 9711" be added?
>>>> 
>>>> Original:
>>>> / This is a full CWT-format token. The payload is the /
>>>> / attestation hardware block above. The main structure /
>>>> / visible is that of the COSE_Sign1. /
>>>> 
>>>> Perhaps:
>>>> / This is a full CWT-format token. The payload is the /
>>>> / attestation hardware block in Appendix A.1.7 of /
>>>> / RFC 9711. The main structure that is visible is /
>>>> / that of the COSE_Sign1. /
>>>> 
>>>> d) Appendix A.2.2. The text below refers to "the next section". 
>>>> Should a pointer be added to Appendix A.2.3?
>>>> 
>>>> Original:
>>>> / Most importantly, it includes a submodule that is a /
>>>> / detached digest which is the hash of the "TEE" claims /
>>>> / set in the next section.
>>>> 
>>>> e) Appendix D. The text below refers to the I-D 
>>>> "draft-ietf-rats-uccs". May we move this sentence outside of 
>>>> the sourcecode so that a citation can be added for the I-D?
>>>> 
>>>> Original:
>>>> ; This is replicated from draft-ietf-rats-uccs
>>>> 
>>>> Claims-Set = {
>>>> * $$Claims-Set-Claims
>>>> * Claim-Label .feature "extended-claims-label" => any...
>>>> 
>>>> Perhaps:
>>>> The following example is replicated from [UCCS].
>>>> 
>>>> Claims-Set = {
>>>> * $$Claims-Set-Claims
>>>> * Claim-Label .feature "extended-claims-label" => any...
>>>> 
>>>> f) Appendix D. Please clarify where a reader can find "claims-set.cddl" 
>>>> as this is the only mention of it in this document.
>>>> 
>>>> Original:
>>>> ; Note that the payload of a JWT is defined in claims-set.cddl. That
>>>> ; definition is common to CBOR and JSON.
>>>> --> 
>>>> 
>>>> 
>>>> 34) <!--[rfced] Appendix A.1.2. To avoid repetition, we updated "with the
>>>> CPU" to "containing the CPU". Please review.
>>>> 
>>>> Original:
>>>> The main attestation is associated with the chip with the 
>>>> CPU and running the main OS.
>>>> 
>>>> Current:
>>>> The main attestation is associated with the chip containing 
>>>> the CPU and running the main OS. 
>>>> -->
>>>> 
>>>> 
>>>> 35) <!--[rfced] Appendix A.1.3. Is the intention to say that 47 bytes are
>>>> encoded in CBOR "including" an 8-byte nonce and 16-byte UEID as
>>>> shown below? Please let us know how we may update for clarity.
>>>> 
>>>> Original:
>>>> 47 bytes encoded in CBOR (8-byte nonce, 16-byte UEID).
>>>> 
>>>> Perhaps:
>>>> 47 bytes are encoded in CBOR (including an 8-byte nonce and 
>>>> a 16-byte UEID).
>>>> -->
>>>> 
>>>> 
>>>> 36) <!--[rfced] Appendix A.1.4. Within the sourcecode, may we update
>>>> "eliptic" to "elliptic" as shown below? If different spacing is
>>>> desired, please let us know.
>>>> 
>>>> Original:
>>>> / kty / 1: 2, / EC2, eliptic curve with x & y /
>>>> 
>>>> Perhaps:
>>>> / kty / 1: 2, / EC2, elliptic curve with x & y/
>>>> -->
>>>> 
>>>> 
>>>> 37) <!--[rfced] Appendix A.1.6. We believe "Trustus Verifications" is a
>>>> service (rather than multiple services) that verifies the
>>>> software component measures, so we have updated accordingly. If
>>>> what is shown below is not correct, please let us know.
>>>> 
>>>> Original:
>>>> "Trustus Verifications" is the name of the services that verifies the
>>>> software component measurements.
>>>> 
>>>> Current:
>>>> "Trustus Verifications" is the name of the service that verifies the
>>>> software component measurements.
>>>> -->
>>>> 
>>>> 
>>>> 38) <!--[rfced] Appendix B.2. How can "UEID takes the view" be reworded 
>>>> to avoid personification? Also, it is not clear what "It" refers to
>>>> in the second sentence - is it also "UEID"? Please clarify.
>>>> 
>>>> Original:
>>>> UEID takes the view that this construction is no longer needed, in 
>>>> particular because cryptographic-quality random number generators 
>>>> are readily available. It takes the view that hardware, software, 
>>>> and/or manufacturing processes implement UEID in a simple and 
>>>> direct way.
>>>> -->
>>>> 
>>>> 
>>>> 39) <!--[rfced] Appendix C.4. We are having trouble parsing the first
>>>> sentence below. Please let us know how we may update for clarity.
>>>> 
>>>> Original:
>>>> EAT thus cannot be defined permanence in terms of defense against
>>>> attack. EAT's definition of permanence is in terms of operations and
>>>> device lifecycle.
>>>> 
>>>> Perhaps:
>>>> Thus, EAT's permanence cannot be defined in terms of defense against
>>>> attack; it can be defined in terms of operations and device life cycle.
>>>> -->
>>>> 
>>>> 
>>>> 40) <!--[rfced] Appendix E.3. May we rephrase this text for clarity?
>>>> Please let us know if this conveys the intended meaning.
>>>> 
>>>> Original:
>>>> However, EAT is intended for use in low-security use cases 
>>>> the same as high-security use case.
>>>> 
>>>> Perhaps:
>>>> However, EAT is intended for use in both low-security and 
>>>> high-security use cases.
>>>> -->
>>>> 
>>>> 
>>>> 41) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is 
>>>> output
>>>> in fixed-width font. In the txt output, there are no changes to the font,
>>>> and the quotation marks have been removed. 
>>>> 
>>>> Please review carefully and let us know if the output is acceptable or if 
>>>> any
>>>> updates are needed.
>>>> -->
>>>> 
>>>> 
>>>> 42) <!-- [rfced] Please review whether any of the notes in this document
>>>> should be 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 
>>>> <https://authors.ietf.org/en/rfcxml-vocabulary#aside>).
>>>> -->
>>>> 
>>>> 
>>>> 43) <!-- [rfced] Throughout the text, the following terminology appears to 
>>>> be used 
>>>> inconsistently. Please review these occurrences and let us know if/how they
>>>> may be made consistent. 
>>>> 
>>>> Claims-Set (34) vs. claims set (8)
>>>> Claims-Sets (3) vs. claims-sets (1) vs. claims sets (11)
>>>> 
>>>> Detached EAT Bundle vs. detached EAT bundle 
>>>> [Note: should all instances be capitalized to match how it 
>>>> appears in the "CBOR Tags" registry 
>>>> (https://www.iana.org/assignments/cbor-tags 
>>>> <https://www.iana.org/assignments/cbor-tags>)?]
>>>> 
>>>> EAT nonce claim vs. "eat_nonce" claim
>>>> [Note: are these different or should they be consistent? One instance
>>>> mentions "EAT nonce claim" but points to Section 4.1, which discusses 
>>>> the "eat_nonce" claim:
>>>> One option to provide freshness is the EAT nonce claim (Section 4.1).
>>>> 
>>>> "Nonce" claim vs. "nonce" claim vs. nonce claim
>>>> Key ID vs. key ID vs. key identifier
>>>> Simple TEE vs. simple TEE
>>>> Submodule claim vs. submodule claim 
>>>> 
>>>> b) FYI - We updated the following terms for consistency. Please let us 
>>>> know 
>>>> if any further updates are needed.
>>>> 
>>>> base-64 and base 64 -> base64
>>>> Canonical -> canonical
>>>> CWT Tag -> CWT tag (per RFC 8392)
>>>> Collision Probability -> collision probability
>>>> EAT Claims -> EAT claims 
>>>> eco-system -> ecosystem
>>>> Simple TEE -> simple TEE
>>>> standards-action -> Standards Action (per RFC 8126)
>>>> Hexadecimal Representation -> hexadecimal representation (per other RFCs)
>>>> 
>>>> The following terms are capitalized in RFC 9334; however, they were
>>>> typically lowercased outside Section 2 of this document.
>>>> 
>>>> Attester (1 instance) -> attester
>>>> Endorser (1 instance) -> endorser 
>>>> Evidence (1 instance) -> evidence 
>>>> 
>>>> c) Should "nested token" be "Nested-Token" in the following since the text 
>>>> seems to be referring to the type, or is it correct per the context?
>>>> 
>>>> Current:
>>>> This CDDL uses, but does not define, Submodule or nested tokens
>>>> because the definition for these types varies between CBOR and JSON
>>>> and the JC<> generic cannot be used to define it.
>>>> 
>>>> The value of each entry in a submodule may be a Claims-Set, nested token,
>>>> or Detached-Submodule-Digest. 
>>>> -->
>>>> 
>>>> 
>>>> 44) <!-- [rfced] Abbreviations
>>>> 
>>>> a) We have added expansions for the following abbreviations
>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>> expansion in the document carefully to ensure correctness.
>>>> 
>>>> Company ID (CID)
>>>> Concise Software Identification (CoSWID) 
>>>> Certificate Revocation List (CRL) 
>>>> Elliptic Curve Digital Signature Algorithm (ECDSA) 
>>>> Extended Unique Identifier (EUI) 
>>>> Global Navigation Satellite System (GNSS)
>>>> Global System for Mobile Communications Association (GSMA) 
>>>> Hashed Message Authentication Code (HMAC) 
>>>> hardware (HW)
>>>> Initial Device Identifier (IDevID)
>>>> Internet of Things (IoT)
>>>> JSON Web Encryption (JWE) 
>>>> JSON Web Signature (JWS)
>>>> Local Device Identifier (LDevID) (per IEEE.802.1AR)
>>>> Media Access Control (MAC)
>>>> Not a Number (NaN)
>>>> Organizationally Unique Identifier (OUI) 
>>>> Software Version Number (SVN) 
>>>> software (SW)
>>>> Software Identification (SWID) 
>>>> 
>>>> b) FYI, we updated this expansion to match use in past RFCs.
>>>> 
>>>> JavaScript Object Signing and Encryption (JOSE) (this document) vs.
>>>> JSON Object Signing and Encryption (JOSE) (in RFC 9052 and many other RFCs)
>>>> -->
>>>> 
>>>> 
>>>> 45) <!-- [rfced] Please review the "Inclusive Language" portion of the 
>>>> online 
>>>> Style Guide 
>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>
>>>> and let us know if any changes are needed.
>>>> 
>>>> For example, please consider whether the following terms should be 
>>>> updated: 
>>>> - whitespace
>>>> - master
>>>> - Native
>>>> -->
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/kc/ar
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jan 13, 2025 at 8:48 PM <rfc-edi...@rfc-editor.org 
>>>> <mailto:rfc-edi...@rfc-editor.org>> wrote:
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2025/01/13
>>>> 
>>>> RFC Author(s):
>>>> --------------
>>>> 
>>>> Instructions for Completing AUTH48
>>>> 
>>>> Your document has now entered AUTH48. Once it has been reviewed and 
>>>> approved by you and all coauthors, it will be published as an RFC. 
>>>> If an author is no longer available, there are several remedies 
>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/ 
>>>> <https://www.rfc-editor.org/faq/>).
>>>> 
>>>> You and you coauthors are responsible for engaging other parties 
>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>> your approval.
>>>> 
>>>> Planning your review 
>>>> ---------------------
>>>> 
>>>> Please review the following aspects of your document:
>>>> 
>>>> * RFC Editor questions
>>>> 
>>>> Please review and resolve any questions raised by the RFC Editor 
>>>> that have been included in the XML file as comments marked as 
>>>> follows:
>>>> 
>>>> <!-- [rfced] ... -->
>>>> 
>>>> These questions will also be sent in a subsequent email.
>>>> 
>>>> * Changes submitted by coauthors 
>>>> 
>>>> Please ensure that you review any changes submitted by your 
>>>> coauthors. We assume that if you do not speak up that you 
>>>> agree to changes submitted by your coauthors.
>>>> 
>>>> * Content 
>>>> 
>>>> Please review the full content of the document, as this cannot 
>>>> change once the RFC is published. Please pay particular attention to:
>>>> - IANA considerations updates (if applicable)
>>>> - contact information
>>>> - references
>>>> 
>>>> * Copyright notices and legends
>>>> 
>>>> Please review the copyright notice and legends as defined in
>>>> RFC 5378 and the Trust Legal Provisions 
>>>> (TLP – https://trustee.ietf.org/license-info 
>>>> <https://trustee.ietf.org/license-info>).
>>>> 
>>>> * Semantic markup
>>>> 
>>>> Please review the markup in the XML file to ensure that elements of 
>>>> content are correctly tagged. For example, ensure that <sourcecode> 
>>>> and <artwork> are set correctly. See details at 
>>>> <https://authors.ietf.org/rfcxml-vocabulary> 
>>>> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
>>>> 
>>>> * Formatted output
>>>> 
>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>> formatted output, as generated from the markup in the XML file, is 
>>>> reasonable. Please note that the TXT will have formatting 
>>>> limitations compared to the PDF and HTML.
>>>> 
>>>> 
>>>> Submitting changes
>>>> ------------------
>>>> 
>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>> the parties CCed on this message need to see your changes. The parties 
>>>> include:
>>>> 
>>>> * your coauthors
>>>> 
>>>> * rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org> (the RPC 
>>>> team)
>>>> 
>>>> * other document participants, depending on the stream (e.g., 
>>>> IETF Stream participants are your working group chairs, the 
>>>> responsible ADs, and the document shepherd).
>>>> 
>>>> * auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org>, 
>>>> which is a new archival mailing list 
>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>> list:
>>>> 
>>>> * More info:
>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>  
>>>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>>>> 
>>>> * The archive itself:
>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ 
>>>> <https://mailarchive.ietf.org/arch/browse/auth48archive/>
>>>> 
>>>> * Note: If only absolutely necessary, you may temporarily opt out 
>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>> If needed, please add a note at the top of the message that you 
>>>> have dropped the address. When the discussion is concluded, 
>>>> auth48archive@rfc-editor.org <mailto:auth48archive@rfc-editor.org> will be 
>>>> re-added to the CC list and 
>>>> its addition will be noted at the top of the message. 
>>>> 
>>>> You may submit your changes in one of two ways:
>>>> 
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>> 
>>>> Section # (or indicate Global)
>>>> 
>>>> OLD:
>>>> old text
>>>> 
>>>> NEW:
>>>> new text
>>>> 
>>>> You do not need to reply with both an updated XML file and an explicit 
>>>> list of changes, as either form is sufficient.
>>>> 
>>>> We will ask a stream manager to review and approve any changes that seem
>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>> and technical changes. Information about stream managers can be found in 
>>>> the FAQ. Editorial changes do not require approval from a stream manager.
>>>> 
>>>> 
>>>> Approving for publication
>>>> --------------------------
>>>> 
>>>> To approve your RFC for publication, please reply to this email stating
>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>>>> as all the parties CCed on this message need to see your approval.
>>>> 
>>>> 
>>>> Files 
>>>> -----
>>>> 
>>>> The files are available here:
>>>> https://www.rfc-editor.org/authors/rfc9711.xml 
>>>> <https://www.rfc-editor.org/authors/rfc9711.xml>
>>>> https://www.rfc-editor.org/authors/rfc9711.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711.html>
>>>> https://www.rfc-editor.org/authors/rfc9711.pdf 
>>>> <https://www.rfc-editor.org/authors/rfc9711.pdf>
>>>> https://www.rfc-editor.org/authors/rfc9711.txt 
>>>> <https://www.rfc-editor.org/authors/rfc9711.txt>
>>>> 
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9711-diff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-diff.html>
>>>> https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-rfcdiff.html> (side by side)
>>>> 
>>>> Diff of the XML: 
>>>> https://www.rfc-editor.org/authors/rfc9711-xmldiff1.html 
>>>> <https://www.rfc-editor.org/authors/rfc9711-xmldiff1.html>
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9711 
>>>> <https://www.rfc-editor.org/auth48/rfc9711>
>>>> 
>>>> Please let us know if you have any questions. 
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9711 (draft-ietf-rats-eat-31)
>>>> 
>>> Title : The Entity Attestation Token (EAT)
>>> Author(s) : L. Lundblade, G. Mandyam, J. O'Donoghue, C. Wallace
>>> WG Chair(s) : Ned Smith, Nancy Cam-Winget, Kathleen Moriarty
>>> Area Director(s) : Deb Cooley, Paul Wouters
>>> <RFC 9711 Editor Feedback v0.1.docx>-- 
>>> auth48archive mailing list -- auth48archive@rfc-editor.org 
>>> <mailto:auth48archive@rfc-editor.org>
>>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org 
>>> <mailto:auth48archive-le...@rfc-editor.org>
>>> 
>>> <RFC 9711 Editor Feedback v0.2.docx>
>>> 
>>> 
>>> 
>>> 
>> 
>> <RFC 9711 Editor Feedback v0.4.docx>
> 
> 
> 
> 
> 
> 

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to