[auth48] Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48 Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)

[Henk Birkholz <[e-mail]>]

+1

this aligns with Carsten's input from April!

On 04.06.2026 16:36, Antoine Delignat-Lavaud wrote:
> Hi Megan,
> 
>  From our review we believe that all the changes I submitted in my 
> previous XML are already in the Editor's XML https://auth48- 
> transition.rfc-editor.org/authors/rfc9942.xml <https://auth48- 
> transition.rfc-editor.org/authors/rfc9942.xml> so no further action is 
> required from my submission.
> 
> However, I agree that we should take the EDN changes from Orie in his 
> email below (https://github.com/cose-wg/draft-ietf-cose-merkle-tree- 
> proofs/blob/dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml 
> <https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/blob/ 
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml>) before 
> closing the AUTH48 process.
> 
> Best,
> Antoine
> 
> ------------------------------------------------------------------------
> *From:* Orie <[e-mail]>
> *Sent:* Thursday, June 4, 2026 13:55
> *To:* Megan Ferguson <[e-mail]>
> *Cc:* Henk Birkholz <[e-mail]>; Antoine Delignat- 
> Lavaud <[e-mail]>; [e-mail] 
> <[e-mail]>; Cedric Fournet <[e-mail]>; Yogesh 
> Deshpande <[e-mail]>; [e-mail] 
> <[e-mail]>; [e-mail] <rfc-editor@rfc- 
> editor.org>; [e-mail] <[e-mail]>; [e-mail] 
> <[e-mail]>; [e-mail] 
> <[e-mail]>; Amaury Chamayou 
> <[e-mail]>; [e-mail] <scitt- 
> [e-mail]>; [e-mail] <[e-mail]>; Deb Cooley 
> <[e-mail]>; [e-mail] <auth48archive@rfc- 
> editor.org>
> *Subject:* Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48 Questions: 
> draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and draft-ietf- 
> scitt-architecture-22 (RFC-to-be 9943)
> Hi,
> 
> I've corrected the broken examples here: https://github.com/cose-wg/ 
> draft-ietf-cose-merkle-tree-proofs/blob/ 
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml <https:// 
> github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/blob/ 
> dbd7404d10765af013602e37743faf3a6dd8feb6/auth48/rfc9942.xml>
> 
> Let me know if there is anything else I can help with.
> 
> Regards,
> 
> OS
> 
> On Thu, Apr 23, 2026 at 5:42 PM Megan Ferguson <[e-mail]- 
> editor.org <mailto:[e-mail]>> wrote:
> 
>     Hi Henk and Antoine,
> 
>     Note that Antoine had submitted an XML file that we were wanting to
>     confirm was the intended file - we can fold the change described in
>     #1 of your message into that file once we receive confirmation it
>     was the intended file (or into a new XML file if Antoine sends it
>     (see our message sent 17 April for details)).
> 
>     The change to fold in:
> 
>     Old:
>     The following definition from [RFC8610] is provided:
> 
>     New:
>     Figure 1 defines how Receipts are included in a COSE_Sign1 data item:
> 
>     (We have updated our current file with the change in the meantime,
>     but making sure this is flagged and not lost in the mix.)
> 
>     With regard to #2, as these updates to code may be beyond editorial,
>     we would prefer if the authors made these changes directly in the
>     XML file (available at the link below but with coordination with
>     Antoine’s XML version in mind).  These changes have NOT been made.
> 
>     For #3, glad you were happy with the change :)
> 
>     Below are links to our current versions of the file (not updated
>     with Antoine’s changes until we hear back on the above issue):
> 
>        The files have been posted here (please refresh):
>     https://www.rfc-editor.org/authors/rfc9942.txt <https://www.rfc-
>     editor.org/authors/rfc9942.txt>
>     https://www.rfc-editor.org/authors/rfc9942.pdf <https://www.rfc-
>     editor.org/authors/rfc9942.pdf>
>     https://www.rfc-editor.org/authors/rfc9942.html <https://www.rfc-
>     editor.org/authors/rfc9942.html>
>     https://www.rfc-editor.org/authors/rfc9942.xml <https://www.rfc-
>     editor.org/authors/rfc9942.xml>
> 
>        The files have been posted here (please refresh):
>     https://www.rfc-editor.org/authors/rfc9942-diff.html <https://
>     www.rfc-editor.org/authors/rfc9942-diff.html>
>     https://www.rfc-editor.org/authors/rfc9942-rfcdiff.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-auth48diff.html>
>     https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html
>     <https://www.rfc-editor.org/authors/rfc9942-
>     auth48rfcdiff.html> (side by side)
>     https://www.rfc-editor.org/authors/rfc9942-lastdiff.html <https://
>     www.rfc-editor.org/authors/rfc9942-lastdiff.html>
>     https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html
>     <https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html> (side
>     by side)
> 
>     The AUTH48 status page for this document is available here:
>     https://www.rfc-editor.org/auth48/rfc9942 <https://www.rfc-
>     editor.org/auth48/rfc9942>
> 
>     The AUTH48 status page for this cluster is available here:
>     https://www.rfc-editor.org/auth48/C557 <https://www.rfc-editor.org/
>     auth48/C557>
> 
>     Thank you.
> 
>     Megan Ferguson
>     RFC Production Center
> 
>      > On Apr 23, 2026, at 9:06 AM, Henk Birkholz
>     <[e-mail]> wrote:
>      >
>      > Hi Megan,
>      >
>      > from here on I am referring the the approved part (left) of this
>     link:
>      >
>      >> https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html
>     <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html>
>      >
>      >
>      > (1) Introducing CDDL definitions
>      >
>      > "The following definition from [RFC8610] is provided:"
>      >
>      > is obviously wrong. Not sure where that happened on the way. Also
>     we should not use the passive here.
>      >
>      > This should say, e.g. "Figure 1 defines how Receipts are included
>     in a COSE_Sign1 data item:"
>      >
>      > The CDDL reference is already introduced somewhere above.
>      >
>      > (2) END in general
>      >
>      > Currently, all CDDL definitions use comma inconsistently. This
>     not "wrong" but really bad style. In my opinion, we should get rid
>     of all commas.
>      >
>      > Furthermore, the EDN is currently broken. An EDN comment that
>     starts with a "/" must also end with a "/". Alternatively, at the
>     end of a line a comment that starts with a "#" does not require an
>     ending delimiter. I'd prefer using "#" when there is a comment at
>     the end of a line.
>      >
>      > (3) In the EDN Figure 1
>      >
>      > The change from "{" to "[" is a nice catch. Thanks!
>      >
>      >
>      > Viele Grüße,
>      >
>      > Henk
>      >
>      >
>      > On 17.04.2026 20:16, Megan Ferguson wrote:
>      >> Hi Antoine,
>      >> Thanks for your reply.
>      >> I want to confirm that the XML attached is the one you were
>     meaning to send?
>      >> Asking because:
>      >> -Looks like the most recent changes we applied (sent 14 April)
>     were not included (e.g., the alphabetizing of the Terminology
>     section, etc.).
>      >> -Some other changes from previous versions seem to be reverted
>     (e.g., = /6.18(COSE_Sign1) has been changed back to #6.18(COSE_Sign1).
>      >> -We don’t see responses or action taken on our questions sent 14
>     April.
>      >> -There don’t seem to be new changes (most all of the things that
>     appear to have been changed have been touched before).
>      >> You can see a diff between the most recent version we had sent
>     on 14 April and the file you just sent at:
>      >> https://www.rfc-editor.org/authors/rfc9942question2-diff.html
>     <https://www.rfc-editor.org/authors/rfc9942question2-diff.html>
>      >> A diff between our 2nd-to-last version and the file you just
>     sent is viewable here:
>      >> https://www.rfc-editor.org/authors/rfc9942question1-diff.html
>     <https://www.rfc-editor.org/authors/rfc9942question1-diff.html>
>      >> Please let us know which of the following ways forward would
>     work best:
>      >> 1) This XML was sent in error, a new one will be submitted by
>     the authors.
>      >> 2) The mail just got crossed, the authors want the changes in
>     the RPC’s most recent version plus the updates (mostly revisions)
>     that were in the attached XML file (i.e., I can update our files to
>     include the changes highlighted in the second diff above). Note: if
>     this is the case, can you please also overtly respond to the
>     questions from 14 April so that we can close them out?
>      >> 3) The authors reject the changes in the RPC’s most recent
>     version and prefer the version in the most recent XML file instead.
>     Please also reply overtly to the questions so we can close them out.
>      >> Thanks!
>      >> Megan Ferguson
>      >> RFC Production Center
>      >>> On Apr 17, 2026, at 7:31 AM, Antoine Delignat-Lavaud
>     <[e-mail] <mailto:[e-mail]>> wrote:
>      >>>
>      >>> Dear Megan,
>      >>>
>      >>> Please find attached our latest corrections in XML. This
>     addresses all remaining editor comments and also corrects a few
>     additional editorial mistakes we found.
>      >>>
>      >>> I will send a separate update for 9943.
>      >>>
>      >>> Best,
>      >>> Antoine
>      >>> (on behalf of the authors)From: Megan Ferguson
>     <[e-mail] <mailto:[e-mail]>>
>      >>> Sent: Thursday, April 16, 2026 19:43
>      >>> To: Antoine Delignat-Lavaud <[e-mail]
>     <mailto:[e-mail]>>
>      >>> Cc: [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>;
>     [e-mail]<[e-mail]>; Cedric
>     Fournet <[e-mail] <mailto:[e-mail]>>;
>     Yogesh Deshpande <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:cose-
>     [e-mail]> <[e-mail] <mailto:[e-mail]>>; cose-
>     [e-mail] <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; Amaury Chamayou
>     <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail] <mailto:scitt-
>     [e-mail]>>; [e-mail] <mailto:scitt-
>     [e-mail]> <[e-mail] <mailto:scitt-
>     [e-mail]>>; Deb Cooley <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>
>      >>> Subject: Re: [EXTERNAL] [AD] [C557] Cluster-Wide AUTH48
>     Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942)
>     and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)
>      >>>  Hi Antoine,
>      >>>
>      >>> No problem!  Thanks for letting us know and we will wait to
>     hear from you.
>      >>>
>      >>> Megan Ferguson
>      >>> RFC Production Center
>      >>>
>      >>>> On Apr 16, 2026, at 11:05 AM, Antoine Delignat-Lavaud
>     <[e-mail] <mailto:[e-mail]>> wrote:
>      >>>>
>      >>>> Hi Megan,
>      >>>>
>      >>>> Many thanks for the extra feedback.
>      >>>>
>      >>>> We have a number of changes we are preparing following the
>     latest round of feedback that we will submit tomorrow. To avoid
>     conflicts we request that you hold off on further editing until we
>     have submitted the revisions.
>      >>>>
>      >>>> Best,
>      >>>> Antoine
>      >>>>
>      >>>> -----Original Message-----
>      >>>> From: Megan Ferguson <[e-mail]
>     <mailto:[e-mail]>>
>      >>>> Sent: 14 April 2026 21:52
>      >>>> To: Antoine Delignat-Lavaud <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>      >>>> Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail]; Cedric Fournet <[e-mail]
>     <mailto:[e-mail]>>; Yogesh Deshpande
>     <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>; rfc-
>     [e-mail] <mailto:[e-mail]>; cose-
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; Amaury Chamayou
>     <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:scitt-
>     [e-mail]>; Deb Cooley <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>      >>>> Subject: [EXTERNAL] Re: [AD] [C557] Cluster-Wide AUTH48
>     Questions: draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942)
>     and draft-ietf-scitt-architecture-22 (RFC-to-be 9943)
>      >>>>
>      >>>> Hi Antoine and *AD (*Paul),
>      >>>>
>      >>>> [*Paul - Would you please review and approve the removal of
>     text from Section 6 of RFC-to-be 9942?  ]
>      >>>>
>      >>>> Thank you for the updated file!
>      >>>>
>      >>>> We had some follow-up questions/comments for you to review:
>      >>>>
>      >>>> 1) We had asked about text additions to the Terminology section:
>      >>>>
>      >>>> a) Regarding the addition of the following to the Terminology
>     section:
>      >>>>
>      >>>>   The terms "header", "payload", and "to-be-signed bytes" are
>     defined
>      >>>>   in [STD96].
>      >>>>
>      >>>> We have updated to use the following (as to-be-signed bytes
>     does not appear in this document):
>      >>>>
>      >>>>   The terms “header" and "payload" are defined in [STD96].
>      >>>>
>      >>>> Note also that we ended up having to change the following
>     citation to RFC 9052, which is part of [STD96], and have updated the
>     References section to list STD 96 normatively and RFC 9052 only
>     within STD 96:
>      >>>>
>      >>>> Original:
>      >>>> A COSE Single Signer Data Object, as defined in [RFC9052],
>     containing the header parameters necessary to convey one or more VDP
>     for an associated VDS.
>      >>>>
>      >>>> Current:
>      >>>> A COSE Single Signer Data Object, as defined in RFC 9052
>     [STD96], containing the header parameters necessary to convey one or
>     more VDP for an associated VDS.
>      >>>>
>      >>>> Please let us know any objections/concerns.
>      >>>>
>      >>>> b) Please let us know if the following should also be added to
>     the Terminology section:
>      >>>>
>      >>>> The term "claim" is defined in [RFC8392].
>      >>>>
>      >>>> Note that RFC 8392 is already referenced.
>      >>>>
>      >>>> 2) Regarding the following query:
>      >>>>
>      >>>> <!--[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.
>      >>>> -->
>      >>>>
>      >>>> <!-- [authors] We have updated the sentence as follows for
>     clarity:
>      >>>>
>      >>>> ...for example EC2 keys (1: 2) require and give meaning to
>     specific parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d).
>     RFC9162_SHA256 (395: 1) supports both (-1) inclusion and (-2)
>     consistency proofs.
>      >>>>
>      >>>> Please let us know if you have any further suggestions. —>
>      >>>>
>      >>>> [rfced] We believe the meaning of the text is that Proofs are
>     similar to COSE Key Type Parameters because for both of them, EC2
>     keys (1: 2) require and give meaning to specific parameters.  An
>     example of that being -1 (crv), -2 (x), -3 (y), and -4 (d).
>      >>>>
>      >>>> We have updated the text to fit the above; please see our
>     updates and let us know if the current text conveys your intended
>     meaning.
>      >>>>
>      >>>>
>      >>>> 3) Regarding the following query:
>      >>>>
>      >>>> <!--[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.
>      >>>>
>      >>>> -->
>      >>>> <!--[authors] We think the current sentence with the comma
>     parses correctly.
>      >>>> -->
>      >>>>
>      >>>> Can you let us know how “(set member) bytes" relates to the
>     sentence?
>      >>>>
>      >>>>
>      >>>> The files below have been updated with all other requests.
>      >>>>
>      >>>> Please review carefully as we do not make changes once the
>     document is published as an RFC.
>      >>>>
>      >>>>  The files have been posted here (please refresh):
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966148880%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r4DIPKy4A51NEYLSt37ZLKv5EDL%2FxygdFTVBJ7s%2FZYw%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.txt>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966204186%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pF2Gd6Z6KsnvuMW6qbx8YPx33lbGRBjjAHFmCN8MsX8%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.pdf>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966258528%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FXaX%2BNva2Zt30IYNDPJzbCoqtKvwvNlCShmWv73AF3Q%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.html>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966292714%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zlkgpxcvnhQPTm61ibjbUEPFbH1pK1VcxnwBeCCb1CQ%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.xml>
>      >>>>
>      >>>>  The diff files have been posted here (please refresh):
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966319736%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cMdRSjokKj8NkfdX6fRqq4%2F0rG%2BRARw3IirM%2FM40C8A%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-diff.html>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966339679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QdufwmRO4W9ZXPP75%2BP%2BBE2EuUBkgpaCai8Mke7TXHY%3D&reserved=0(side <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html> by side)
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     auth48diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966357832%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=h6OFjLIsSG0HRpnWtdVa425KYVLM1DIrPO6p6bzxErs%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-auth48diff.html>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     auth48rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966377508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3%2BQy1%2BemdWPDD9FsVSeXNRYm3loUGcbJG5mKaxvPHKI%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html> (side by side)
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     lastdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966397952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Nz9zBQ5BinChOSCBs8AK8J2LmsGiNNJatNre%2F%2BEaiyg%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-lastdiff.html>
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     lastrfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966417496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fmDfferopj6deReTsUs6CH%2FB7xdQYzkey%2F8aZkM9Qn0%3D&reserved=0(side <https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html> by side)
>      >>>>
>      >>>> The AUTH48 status page for this document is available here:
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966436825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lmpG%2FPq5DZSUPpCVw5smdEnURPpul%2BA7qk8ZpxUfZtA%3D&reserved=0 <https://www.rfc-editor.org/auth48/rfc9942>
>      >>>>
>      >>>> The AUTH48 status page for this cluster is available here:
>      >>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauth48%2FC557&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966458747%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Za8iNKgbsahg2gNR2ip3ZzD2uD4xj1Y82qR2BT3C3fA%3D&reserved=0 <https://www.rfc-editor.org/auth48/C557>
>      >>>>
>      >>>> Thank you.
>      >>>>
>      >>>> Megan Ferguson
>      >>>> RFC Production Center
>      >>>>
>      >>>>
>      >>>>
>      >>>>> On Apr 14, 2026, at 8:52 AM, Antoine Delignat-Lavaud
>     <[e-mail] <mailto:[e-mail]>> wrote:
>      >>>>>
>      >>>>> Hi Megan,
>      >>>>>
>      >>>>> Many thanks for the updates. We have taken an additional pass
>     on the remaining questions and addressed them in further updates
>     that we have batched in the attached XML.
>      >>>>>
>      >>>>> We agree about the issues in Figure 2 and 6 that you pointed
>     out. In addition to the attached fix, we believe the fix for 394/
>     receipts format also requires a corresponding change to 9943 that I
>     will submit separately on the AUTH48 thread for 9943.
>      >>>>>
>      >>>>> Best,
>      >>>>> AntoineFrom: Megan Ferguson <[e-mail]
>     <mailto:[e-mail]>>
>      >>>>> Sent: Thursday, April 2, 2026 00:49
>      >>>>> To: [e-mail] <mailto:[e-mail]> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>      >>>>> <[e-mail]>; Antoine Delignat-Lavaud
>      >>>>> <[e-mail] <mailto:[e-mail]>>; Cedric
>     Fournet <[e-mail] <mailto:[e-mail]>>; Yogesh
>      >>>>> Deshpande <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>      >>>>> <[e-mail] <mailto:[e-mail]>>
>      >>>>> Cc: [e-mail] <mailto:rfc-editor@rfc-
>     editor.org> <[e-mail] <mailto:rfc-editor@rfc-
>     editor.org>>;
>      >>>>> [e-mail] <mailto:[e-mail]> <cose-
>     [e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>      >>>>> <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      >>>>> <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>      >>>>> <[e-mail] <mailto:[e-mail]>>;
>     Amaury Chamayou
>      >>>>> <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>      >>>>> <[e-mail] <mailto:[e-mail]>>; scitt-
>     [e-mail] <mailto:[e-mail]> <scitt-
>     [e-mail] <mailto:[e-mail]>>;
>      >>>>> Deb Cooley <[e-mail] <mailto:[e-mail]>>;
>      >>>>> [e-mail] <mailto:auth48archive@rfc-
>     editor.org><[e-mail] <mailto:auth48archive@rfc-
>     editor.org>>
>      >>>>> Subject: [EXTERNAL] [C557] Cluster-Wide AUTH48 Questions:
>      >>>>> draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942) and
>      >>>>> draft-ietf-scitt-architecture-22 (RFC-to-be 9943)  [You don't
>     often
>      >>>>> get email from [e-mail]
>     <mailto:[e-mail]>. Learn why this is
>      >>>>> important at https://aka.ms/LearnAboutSenderIdentification
>     <https://aka.ms/LearnAboutSenderIdentification> ]
>      >>>>>
>      >>>>> 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://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966479166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0%2FnaMibmODHDM7p6EpYNrEypDp9UdF8qiSUB%2BQ4sQ%2F8%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.txt>
>      >>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966498461%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d564yTKBqQuoqsWadwv7a8GAU0pwZ7Wead%2FVucNDhMI%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.pdf>
>      >>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966516633%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sCcYHCSCfNE5rhigAlBiYqDw%2Bnzw2CrhNvsXPFzMyFk%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.html>
>      >>>>>
>      >>>>> https://www/ <https://www/>.
>      >>>>> rfc-editor.org <http://rfc-editor.org/
>      >%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%40microsof
>      >>>>> t.com <http://t.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd01
>      >>>>>
>     1db47%7C1%7C0%7C639117967933259962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
>      >>>>>
>     hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
>      >>>>>
>     joyfQ%3D%3D%7C0%7C%7C%7C&sdata=mghfteDzbnRINFD04bWLb2867ZMSS6BlI%2FpgS
>      >>>>> mGlQLE%3D&reserved=0
>      >>>>>
>      >>>>>  The diff files have been posted here (please refresh):
>      >>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966534675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VVqmlCj9P4atZzeQ87%2FBjqGgwXb96rj9Air9B7Q2L8w%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-diff.html>
>      >>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     rfcdiff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966551383%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wIeTYi90zSS9cANvolYbIOnCcjvnAsOzYrqraYGY5BE%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html> (side by side)
>      >>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9942-
>     auth48diff.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966570928%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=70TQXtKhS9scGNPiA1IYy6Axi72aB4WiwG3ILX4x4%2B0%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-auth48diff.html>
>      >>>>>
>      >>>>> https://www/ <https://www/>.
>      >>>>> rfc-editor.org <http://rfc-editor.org/>%2Fauthors%2Frfc9942-
>     auth48rfcdiff.html&data=05%7C02%7Ca
>      >>>>> ntdl%40microsoft.com <http://40microsoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
>      >>>>>
>     41af91ab2d7cd011db47%7C1%7C0%7C639117967933344410%7CUnknown%7CTWFpbGZs
>      >>>>>
>     b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
>      >>>>>
>     oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NJnco6RugvGf9mCQrMTvIBm7
>      >>>>> 5rSWW3SESirynUFJheU%3D&reserved=0 (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/ <https://www/>.
>      >>>>> rfc-editor.org <http://rfc-editor.org/
>      >%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft.com
>     <http://40microsoft.com/>
>      >>>>>
>     %7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47
>      >>>>>
>     %7C1%7C0%7C639117967933364597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
>      >>>>>
>     OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
>      >>>>>
>     %3D%3D%7C0%7C%7C%7C&sdata=YV6LHK1h8WupPZed0nA9YLZ0Bns%2FNri2KLJYpyZ7TO
>      >>>>> A%3D&reserved=0
>      >>>>>
>      >>>>> Further cluster information is viewable here:
>      >>>>>
>      >>>>> https://www/ <https://www/>.
>      >>>>> rfc-editor.org <http://rfc-editor.org/
>      >%2Fcluster_info.php%3Fcid%3DC557&data=05%7C02%7Cantdl%40
>      >>>>> microsoft.com <http://microsoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91a
>      >>>>>
>     b2d7cd011db47%7C1%7C0%7C639117967933385568%7CUnknown%7CTWFpbGZsb3d8eyJ
>      >>>>>
>     FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
>      >>>>>
>     CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ztnb%2B8Pf7wdXY2UJZKlKxohciQVfn
>      >>>>> kvLyBAlZ2iYklI%3D&reserved=0
>      >>>>>
>      >>>>> 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://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fsearch&data=05%7C02%7Cantdl%40microsoft.com
>     <http://40microsoft.com/>%7Cdcf
>      >>>>>>
>     e6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1
>      >>>>>>
>     %7C0%7C639117967933405199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>      >>>>>>
>     RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
>      >>>>>>
>     %3D%3D%7C0%7C%7C%7C&sdata=zV3VFSc1LzeIRrm6mMfeThcuBArpvyasrJtWSg7o2B
>      >>>>>> 4%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://ww/ <https://ww/>
>      >>>>>> w.iana.org <http://w.iana.org/
>      >%2Fassignments%2Fcose%2Fcose.xhtml%23verifiable-data-struc
>      >>>>>> ture-algorithms&data=05%7C02%7Cantdl%40microsoft.com
>     <http://40microsoft.com/>%7Cdcfe6dabd4f64
>      >>>>>>
>     1837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639
>      >>>>>>
>     117967933424805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
>      >>>>>>
>     OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0
>      >>>>>>
>     %7C%7C%7C&sdata=sNzsRJzHbjTjioaKB48QaDOvdF1srGfB44dnkmboAZQ%3D&reser
>      >>>>>> ved=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://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7Cantdl%40microsoft.com <http://40microsoft.com/>%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639117967933442934%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FlAcTamXBVIZ7jGzQY4qfDlIYV8uIpEEdZIesb25l2I%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%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966586519%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tzAyeyC%2FeawpZPNfUdI7pVhtQPABSjeyi5dYraqXUls%3D&reserved=0 <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
>      >>>>>>     and let us know if any changes are needed.  Updates of this
>      >>>>>>     nature typically result in more precise language, which is
>      >>>>>>     helpful for readers.
>      >>>>>>
>      >>>>>> Note that our script did not flag any words in particular,
>     but this
>      >>>>>> should still be reviewed as a best practice.
>      >>>>>>
>      >>>>>> -->
>      >>>>>>
>      >>>>>>
>      >>>>>> Thank you.
>      >>>>>>
>      >>>>>> 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%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966606408%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ENkUmQhVN2%2BVtjmREbe8CMWw%2FiWsJCeDWo0iP3q1Vq4%3D&reserved=0 <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://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-
>     info&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966628254%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Z0WNOkjOgJdxMtVxG2cgsEE2c%2FAjGytSkjla8uMYEw%3D&reserved=0 <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://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-
>     vocabulary&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966649096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mq4RGj9NfnNfN%2Flk70qyMfIVYxvhd0WRavHU5MyTHYE%3D&reserved=0 <https://authors.ietf.org/rfcxml-vocabulary>>.
>      >>>>>>
>      >>>>>> *  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
>      >>>>>>
>      >>>>>>   * [e-mail] <mailto:rfc-editor@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).
>      >>>>>>
>      >>>>>>   * [e-mail] <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://ma/ <https://ma/>
>      >>>>>> ilarchive.ietf.org <http://ilarchive.ietf.org/
>      >%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxI
>      >>>>>> Ae6P8O4Zc&data=05%7C02%7Cantdl%40microsoft.com
>     <http://40microsoft.com/>%7Cdcfe6dabd4f641837df
>      >>>>>>
>     808de9a67b6dd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639117967
>      >>>>>>
>     933523144%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
>      >>>>>>
>     AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
>      >>>>>>
>     %7C&sdata=AO1dwmJfnFANnE0FZEedZD4KJ7nG3d0wQQ0LtYNOZdA%3D&reserved=0
>      >>>>>>
>      >>>>>>     *  The archive itself:
>      >>>>>>
>      >>>>>> https://ma/ <https://ma/>
>      >>>>>> ilarchive.ietf.org <http://ilarchive.ietf.org/
>      >%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7
>      >>>>>> Cantdl%40microsoft.com <http://40microsoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf
>      >>>>>>
>     86f141af91ab2d7cd011db47%7C1%7C0%7C639117967933540368%7CUnknown%7CTW
>      >>>>>>
>     FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
>      >>>>>>
>     IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=49r8yM4AczDKOe
>      >>>>>> uU53PknXmrIVsu%2BPIkfgzt13FjSu4%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,
>      >>>>>> [e-mail] <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://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.xml&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966673791%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wE17aWJCxEFrgMjER9Re7ALRq8TJ9Wtw6G4g4i%2B%2FaTU%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.xml>
>      >>>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.html&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966696945%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U16XsgfdOvDTgsuxJvWKEaAjvy00xIzc%2FB1EkcFubmE%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.html>
>      >>>>>> https://nam06.safelinks.protection.outlook.com/?
>     url=https%3A%2F%2Fwww.rfc-
>     editor.org%2Fauthors%2Frfc9942.pdf&data=05%7C02%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966717085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Eg0m5dTLAddo8oatk2UbMAA99XWKGA8TpPrgX51DuaE%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942.pdf>
>      >>>>>>
>      >>>>>> https://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fauthors%2Frfc9942.txt&data=05%7C02%7Cantdl%40micr
>      >>>>>> osoft.com <http://osoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2
>      >>>>>>
>     d7cd011db47%7C1%7C0%7C639117967933610534%7CUnknown%7CTWFpbGZsb3d8eyJ
>      >>>>>>
>     FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
>      >>>>>>
>     pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0Xs8fRQn%2F9s%2FKR4KKOb3t3s
>      >>>>>> MkwrQeOsS50MxigL29u4%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%7Cantdl%40microsoft.com%7C050d698d1d9442ae2e0d08de9be822a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639119618966736976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZJ73QiU002PuLoS5cEM84LopcvrhxZklzKdZLd1l6Ws%3D&reserved=0 <https://www.rfc-editor.org/authors/rfc9942-diff.html>
>      >>>>>>
>      >>>>>> https://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fauthors%2Frfc9942-rfcdiff.html&data=05%7C02%7Cant
>      >>>>>> dl%40microsoft.com <http://40microsoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f1
>      >>>>>>
>     41af91ab2d7cd011db47%7C1%7C0%7C639117967933637548%7CUnknown%7CTWFpbG
>      >>>>>>
>     Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
>      >>>>>>
>     FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4JkPMy%2FiIdR3z4AO
>      >>>>>> xDm9Z%2FFakeBp9aglNClQjCRfQc8%3D&reserved=0 (side by side)
>      >>>>>>
>      >>>>>> Diff of the XML:
>      >>>>>>
>      >>>>>> https://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fauthors%2Frfc9942-xmldiff1.html&data=05%7C02%7Can
>      >>>>>> tdl%40microsoft.com <http://40microsoft.com/
>      >%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f
>      >>>>>>
>     141af91ab2d7cd011db47%7C1%7C0%7C639117967933653396%7CUnknown%7CTWFpb
>      >>>>>>
>     GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
>      >>>>>>
>     kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y3%2FCQOq%2FC4kWF
>      >>>>>> %2BOKUOXlf2g4DRYowG4BNqUSl9xehWI%3D&reserved=0
>      >>>>>>
>      >>>>>>
>      >>>>>> Tracking progress
>      >>>>>> -----------------
>      >>>>>>
>      >>>>>> The details of the AUTH48 status of your document are here:
>      >>>>>>
>      >>>>>> https://ww/ <https://ww/>
>      >>>>>> w.rfc-editor.org <http://w.rfc-editor.org/
>      >%2Fauth48%2Frfc9942&data=05%7C02%7Cantdl%40microsoft
>      >>>>>> .com%7Cdcfe6dabd4f641837df808de9a67b6dd%7C72f988bf86f141af91ab2d7cd0
>      >>>>>>
>     11db47%7C1%7C0%7C639117967933672481%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
>      >>>>>>
>     eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
>      >>>>>>
>     IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=znCCRuGuMv8k2jGpXl1kM3BP2OMX32kE
>      >>>>>> KcPjcdcsu84%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
>      >>>>> <rfc9942.xml>
>      >>>>
>      >>>
>      >>> <rfc9942.xml>
>      >
>