Hi, inline:
On Wed, Apr 1, 2026 at 6:50 PM Megan Ferguson <
[email protected]> wrote:
> 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)?
>
VDS Proof Type seems correct.
>
> 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]
