Cédric,
Thank you for your reply and guidance regarding the cluster-wide questions for
both RFCs-to-be 9942 and 9943. We have implemented the majority of these
changes as requested.
Note that we have replied to our original cluster-wide mail in order to ensure
all participants from both documents see that the responses have been received.
See the thread with subject line "Re: [EXTERNAL] Re: AUTH48: RFC-to-be 9942
<draft-ietf-cose-merkle-tree-proofs-18> for your review” for full response from
Cédric).
Some follow up questions/comments related to the cluster-wide questions exist
below (marked with [rfced]). We believe the follow-ups impact RFC-to-be 9942
only. (Note that resolved issues have been removed.)
Note that further document-specific questions for RFC-to-be 9942 also exist; we
have copied them at the end of this message for your convenience.
> 1) We had a number of questions related to the consistent use of terminology
> throughout the cluster:
>
> b) Should the following similar forms be made uniform in prose? If so,
> please let us know which is preferred:
>
> COSE Header Parameter vs. COSE header parameter (see also other header
> parameter instances without COSE)
> Note: RFCs 9052/9053 use lowercase header parameter and quotes for names
> (e.g., "alg" header parameter). All uses of COSE Header Parameter are in
> titles.
> Yes, please use "COSE header parameter" outside of titles.
[rfced] (Affects RFC-to-be 9942 only) We didn’t see a reply to the second part
of this question regarding putting parameter names in double quotes. We have
updated the new header parameter names to appear in lowercase with double
quotes around them (e.g., “receipts” header parameter) to match RFC 9052/9053.
Please review and let us know any objections.
> Receipt vs. receipt
> Note: RFC 9052 includes a single instance of the term receipt that seems to
> be used in the general sense.
> We would prefer to stay with "Receipt" to make it clear the terminology
> definition applies, except in CBOR/CDDL labels, where the prevailing
> convention is lowercase (therefore "receipt(s)”).
[rfced] (We believe this affects RFC-to-be 9942 only - please let us know if
updates to RFC-to-be 9943 are also necessary) Please let us know if/where any
updates (preferably using Old/New) need to be made related to CBOR/CDDL labels
with regard to the term Receipt vs. receipt.
>
> In addition, a reviewer has caught two mistakes.
>
> One in the examples of Figures 2 and 6, in which the inclusion path should be
> an array to match the schema:
>
> / inclusion / -1 : [
> <<[
> / size / 6, / leaf / 5,
> / inclusion path /
> h'9352f974...4ffa7ce0',
> h'54806f32...f007ea06'
> ]>>
>
>
> Should be:
>
> / inclusion / -1 : [
> <<[
> / size / 6, / leaf / 5,
> / inclusion path /
> [ h'9352f974...4ffa7ce0',
> h'54806f32...f007ea06' ]
> ]>>
>
>
> In figure 2. And:
>
> / inclusion / -1 : [
> <<[
> / size / 20, / leaf / 17,
> / inclusion path /
> h'fc9f050f...221c92cb',
> h'bd0136ad...6b28cf21',
> h'd68af9d6...93b1632b'
> ]>>
> ],
>
>
> Should be:
>
> / inclusion / -1 : [
> <<[
> / size / 20, / leaf / 17,
> / inclusion path /
> [ h'fc9f050f...221c92cb',
> h'bd0136ad...6b28cf21',
> h'd68af9d6...93b1632b' ]
> ]>>
> ],
>
>
> In Figure 6.
>
> The other in Figure 2, where the value of 394 (receipts) ought to be an array:
>
> / receipts / 394 : {
> << ... >>
> }
>
>
> Should be:
>
> / receipts / 394 : { [ << ... >> ]
> }
>
[rfced] (RFC-to-be 9942 only) Please review any updates to code carefully as
indentation or spacing may (accidentally) be affected when copying and pasting.
We recommend using the rfcdiff file to view whitespace changes.
>
>
> • In Section 4.2
>
> This document establishes a registry of verifiable data structure algorithm
> proofs, see Table 2 for details
>
> Should say:
>
> This document establishes a registry of verifiable data structure algorithm
> proofs, see Table 3 for details
[rfced] (RFC-to-be 9942 only) Note that we have left this as a pointer to the
section (8.2.2.2) to match a similar sentence in Section 4.1. Please let us
know if you would prefer them to both be updated to point to the Tables
themselves (i.e., Table 2 in Section 4.1 and Table 3 in Section 4.2).
>
> In addition, there are a couple of inconsistencies across the CDDL snippets:
>
> • There is a mix of cose.label/cose.value(s) and
> cose-label/cose-value(s). Using the latter consistently would be preferable.
> • There is a mix of CDDL using comma-terminated lines (eg.
> Signed_Consistency_Proof) and non comma-terminated (eg.
> Signed_Inclusion_Proof). They are both valid CDDL, but using the convention
> adopted in RFC9052 (comma termination) consistently would be preferable.
>
> Finally, several EDN snippets (Figures 2, 6 and 9) incorrectly use # comment,
> when the correct EDN syntax is / comment /. For example:
> / algorithm / 1 : -7, # ES256
>
>
> Should be:
>
> / algorithm / 1 : -7, / ES256 /
[rfced] (RFC-to-be 9942 only) Again, please carefully review any updates we’ve
made to code to ensure they appear as desired.
One further question that arose for RFC-to-be 9942 in the following:
Current:
This is the value used to identify the Verifiable Data
Structure Proof Type.
Should this be read as VDS Proof Type or VDP Proof Type or VDP type (overlap of
Proof)?
Please review our updates in the files posted below carefully as we do not make
updates once the documents are published as RFCs.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9942.txt
https://www.rfc-editor.org/authors/rfc9942.pdf
https://www.rfc-editor.org/authors/rfc9942.html
https://www.rfc-editor.org/authors/rfc9942.xml
The diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9942-diff.html
https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9942-auth48diff.html
https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html (side by side)
Note - please see the thread for RFC-to-be 9943 to view any changes related to
these cluster-wide questions as we have combined the updates with those in
response to the document-specific questions we received.
The document-specific questions for RFC-to-be 9942 are copied below. We will
await your response to the follow-up questions and document-specific questions
for each document in this cluster before moving forward in the publication
process.
The AUTH48 status page for RFC-to-be 9942 is viewable here:
https://www.rfc-editor.org/auth48/rfc9942
Further cluster information is viewable here:
https://www.rfc-editor.org/cluster_info.php?cid=C557
Thank you.
Megan Ferguson
RFC Production Center
>
>
> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9942
> <draft-ietf-cose-merkle-tree-proofs-18> for your review
>
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the source file.
>
> 1) <!-- [rfced] Please note that the title of the document has been
> updated as follows:
>
> a) We have flipped the abbreviation and expansion for COSE to match
> similar uses in past RFC titles.
>
> Original:
> COSE (CBOR Object Signing and Encryption) Receipts
>
> Current:
> CBOR Object Signing and Encryption (COSE) Receipts
>
> b) We have updated the "short title" (in the running header of the PDF
> version) as follows:
>
> Original:
> COSE (CBOR Object Signing and Encryption) Receipts
>
> Current:
> COSE Receipts
> -->
>
>
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977071980%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B%2BRf6SgCsBXR0Kk9GyWYTUzNxPFi8%2Bk1cx60ACDt%2BTI%3D&reserved=0.
> -->
>
>
> 3) <!--[rfced] We had the following questions related to the Terminology
> section:
>
> a) Would you like the terms to be alphabetized for the ease of the
> reader?
>
> b) The Terminology section of draft-ietf-scitt-architecture has a
> sentence introducing terms from [STD96] in its Terminology section
> (see below) that are also used in this document.
>
> Original:
> The terms "header", "payload", and "to-be-signed bytes" are defined
> in [STD96].
>
> Should this sentence (or something similar as "to-be-signed bytes" is
> not used in this document) be added along with a reference to [STD96]?
> (Same goes for the sentence in the companion document about the
> definition of "claim".)
>
> If so, please let us know how/where to add as well as if the reference
> entry would be normative or informative.
>
> c) We note that this document uses the following terms that are
> defined in the Terminology section of
> draft-ietf-scitt-architecture-22. Should any pointers/citations be
> added to direct the reader to Section 3 of that document?
>
> envelope
> non-equivocation
> statement
> transparency service
>
>
> d) Please see our cluster-wide questions related to discrepancies
> between the definitions that appear in both documents in this cluster
> and variances in their appearance (e.g., capitalization).
>
> -->
>
>
> 4) <!--[rfced] This sentence doesn't parse. Please let us know how to
> update.
>
> Original:
> ...such as -1 (crv), -2 (x), -3 (y), -4 (d), RFC9162_SHA256 (TBD_1
> (requested assignment 395) : 1) supports both (-1) inclusion and (-2)
> consistency proofs.
> -->
>
>
> 5) <!--[rfced] Please note that Figure 1 exceeds our character limit in
> three places (line 319 is 5 characters over the character limit).
> Please review how these lines could be broken to fit within the
> 69 character limit associated with sourcecode.
> -->
>
>
> 6) <!--[rfced] We had two questions related to this document's use of the
> term "SHA256":
>
> a) We note that the EDN provided in Section 4.3 uses RFC9162 SHA-256
> while other uses of this term in prose use RFC9162_SHA256. Please
> confirm that this is as intended.
>
> b) We see both SHA256 and sha-256 in running text. Should these be
> made uniform as SHA256?
>
> -->
>
>
> 7) <!-- [rfced] We note that [RFC9162] uses "leaf_index" rather than
> "leaf-index". Please review and let us know if updates should be
> made.
>
> Current:
> The term leaf-index is used for alignment with the use established in
> Section 2.1.3.2 of [RFC9162].
> -->
>
>
> 8) <!-- [rfced] We note that [RFC9162] uses "Merkle Tree Hash" rather
> than "Merkle tree hash". Please note that there is inconsistency
> in this document related to Merkle Tree vs. Merkle tree as well.
>
> Current:
> The payload of an RFC9162_SHA256 inclusion proof signature is the
> Merkle tree hash as defined in [RFC9162].
> -->
>
>
> 9) <!--[rfced] This sentence doesn't seem to parse. Please rephrase.
>
> Original:
> First the verifier applies the inclusion proof to a possible entry
> (set member) bytes.
>
> -->
>
>
> 10) <!--[rfced] Please review this text for clarity (particularly for a
> missing verb after which?).
>
> Original:
> If this process succeeds, the result is a Merkle root, which in the
> attached as the COSE Sign1 payload.
> -->
>
>
> 11) <!--[rfced] The following may require clarification:
>
> Current:
> The privacy considerations section of [RFC9162] and [RFC9053] apply to
> this document.
>
> RFCs 9162 and 9053 do not have sections explicitly named "Privacy
> Considerations". RFC 9053 doesn't appear to contain the term "privacy" at
> all. Please review.
> -->
>
>
> 12) <!--[rfced] We had the following questions/comments related to the
> IANA Considerations section:
>
> a) For clarity, we have updated the IANA Considerations section by
> breaking Section 8.2.2 up into subsections for each of the two
> registries. Please review this reorganization as well as any pointers
> to it throughout the text to ensure we have correctly maintained your
> intent.
>
> b) Please note that we have updated Tables 2 and 3 to include the
> Change Controller column as appears at the corresponding IANA
> registries. Please let us know any concerns.
>
> c) Note: Any updates to Section 2 and/or Tables 1-3 that have been
> made or resulting from author replies to our separate terminology or
> abbreviation queries that would impact the information actually
> registered at
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23verifiable-data-structure-algorithms&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977090307%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OPkB21dgDmIqpqKcgFc0pU4Y7uuuplVbnyqytmjd6sY%3D&reserved=0
> will be communicate to IANA by the RPC once AUTH48 completes.-->
>
>
> 13) <!--[rfced] We had the following questions/comments related to
> abbreviations used throughout the document.
>
> a) 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.
>
> b) We would like to update to use an abbreviation (instead of its
> expanded form) after first use in accordance with the guidance at
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977101792%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fEPKIWO1ggyKBixVsB0X9brsSAV2yLUY2hNOWE%2Fkb2M%3D&reserved=0
> for the
> following abbreviations. Please let us know any objections.
>
> VDS
> VDP
>
> *Note: In the meantime, we have updated all uses in prose to be
> capitalized for these two terms. Please review the use of "verifiable
> data structure" (in quotes): may this instance be changed to VDS as
> well?
>
> **Note: We also see "verifiable data structure algorithm proofs".
> Could this be made "VDP algorithms"?
>
> c) Things get a bit messy when we look at the expansion of VDP if the
> expansion of "P" is plural "proofs".
>
> For example, in the following:
>
> Original:
> This document describes how to convey VDS and associated VDP types in
> unified COSE envelopes.
>
> If we were to expand this, we'd get "verifiable data structure proofs
> types" (with the double plurals).
>
> However, sometimes the -s on proof disappears when this was expanded
> in the text.
>
> For example:
>
> Original:
> ..defining the integers used to identify verifiable data structure
> proof types...
>
> and
>
> Original:
> A data structure which supports one or more Verifiable Data Structure
> Proof Types.
>
> It's also a bit strange for it to be plural here:
>
> Original:
> The combination of representations of various VDS and VDP can
> significantly increase the burden for implementers and create
> interoperability challenges for transparency services.
>
> Where we will have to make it "various VDSs and VDP" (the reader will
> likely expect VDPs).
>
> Is it possible to update to use Verifiable Data Structure Proofs
> (VDPs)?
>
>
> -->
>
>
> 14) <!-- [rfced] See a list below of terms enclosed in <tt> in this
> document. Some of these terms appear both with and without <tt>
> (alg, receipts, vdp, vds). Please review to ensure the usage of
> <tt> is correct and consistent. Let us know if any updates are
> needed.
>
> <tt>alg</tt>
> <tt>exp</tt>
> <tt>iat</tt>
> <tt>leaf-index</tt>
> <tt>nbf</tt>
> <tt>receipts</tt>
> <tt>tree-size</tt>
> <tt>vdp</tt>
> <tt>vds</tt>
>
> -->
>
>
> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977113797%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r%2FuPnpPET0cOTYitAqQz%2F96%2BSsp4NB9TTQdAW04kIo4%3D&reserved=0>
> 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.
>
> Megan Ferguson
> RFC Production Center
>
> *****IMPORTANT*****
>
> Updated 2026/03/06
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977125077%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lkRHGWHCD1SsiIb2hkGXM8UNve0xSRAAFU6kNA2f%2FVs%3D&reserved=0).
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977140257%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6bsxB1oc2pwje1janEZ%2B7940uLfGUMqICRxuYJHtZ48%3D&reserved=0).
>
> * 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977152312%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=30yzZ%2FUfdHTUQIBpLHU%2FXqPYHVRu0%2F0fQPs7Rf6H1Ts%3D&reserved=0>.
>
> * 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
>
> * [email protected] (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).
>
> * [email protected], which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
>
> * More info:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977164303%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XRDDChxznCfHIiG%2FhMcmpyDGqPk2zEsu9EpDYzXl4NI%3D&reserved=0
>
> * The archive itself:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977175905%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BUKAZrU2swukkIJOG8oWndWQ397uTS%2Fq2EZPJrvNMP8%3D&reserved=0
>
> * 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,
> [email protected] 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977187655%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qsPCrDUKjaIBxXtI57IBxEzPPiGH%2FEu5i7o%2Fv%2F6vh9w%3D&reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977199698%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7vcXAEDWb%2BltJKQuqDIYokz1QfSpthPBxwDM%2BDtuAmA%3D&reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977211143%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9it0nVXLGJa7SVC5djTQ1%2Fl%2FRCg6bQDslu4cN%2FhTp4E%3D&reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977222330%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cQWeH8x%2Fkuy3%2B%2FF4zc17fJdugcB6I180WC1%2FQTsEn%2B4%3D&reserved=0
>
> Diff file of the text:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-diff.html&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977233546%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HPpcvNCnXbFyuCIsMDlOcG7gTHPy%2BiauTPUiRMlWGYg%3D&reserved=0
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-rfcdiff.html&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977244824%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZmPZ%2F18a5sNyFGx6xvSlAorJuoIC1dzTCXI7CZlFRI0%3D&reserved=0
> (side by side)
>
> Diff of the XML:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-xmldiff1.html&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977255836%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9cG72ByeGNCfv%2FeQ5GYpDZ1SW%2F%2FGG7j4SwdYXx5XLKA%3D&reserved=0
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9942&data=05%7C02%7Cfournet%40microsoft.com%7Cbadedbd668a64aa8914608de7bdb02f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639084377977266632%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eJk5J3YmLCsAAfrZajfoOX%2Fq%2BIyjVfhF81aKewOOI4I%3D&reserved=0
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9942 (draft-ietf-cose-merkle-tree-proofs-18)
>
> Title : COSE (CBOR Object Signing and Encryption) Receipts
> Author(s) : O. Steele, H. Birkholz, A. Delignat-Lavaud, C. Fournet
> WG Chair(s) : Ivaylo Petrov, Michael B. Jones
>
> Area Director(s) : Deb Cooley, Paul Wouters
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
