[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)

[Megan Ferguson <[e-mail]>]

Hi Deb,

This reply is for draft-ietf-cose-merkle-tree-proofs-18 (RFC-to-be 9942).  Paul is listed as the Responsible AD for that document.

Thanks!

Megan Ferguson
RFC Production Center

> On Jun 5, 2026, at 5:29 PM, Deb Cooley <[e-mail]> wrote:
> 
> This is for the cose draft, correct?  So you want Paul as the AD?
> 
> Deb
> 
> On Fri, Jun 5, 2026 at 7:20 PM Megan Ferguson <[e-mail]> wrote:
> Henk, Antoine, and Orie, (and *AD),
> 
> [*AD - please note that this document has had several updates to code.  Please review/approve all changes to code highlighted in the AUTH48 diff below.]
> 
> After some forensic email searching / editing work, I *think* the version posted below encompasses all the desired changes we’ve received to date.  Please review *extra* carefully and let us know if anything is missing and/or updated incorrectly.
> 
> Going forward, **please base any edits of the linked edited XML version** (see below).
> 
> Some known clean up:
> 
> We were unsure if the following changes that do not currently appear in the current XML file were intentionally removed or if they should be reinstated:
> 
> 1) See the following in Figure 6:
> 
> >>> 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 : {         [ << ... >> ]
> >>>       }
> 
> 
> Current:
>     / receipts / 394 : [
>       <</ cose-sign1 / 18([
> 
> 
> 2) We believe that the use of # in the EDN (it was switched to “/" at one point) is intentional (so that an ending delimiter is not necessary).  Please review and confirm.  Related author communication summarized below for convenience:
> > 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 /
> 
> However, later:
> 
> > 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) Please review the use of commas in the CDDL and let us know if any further changes are desired:
> 
> > Currently, all CDDL definitions use comma inconsistently. This not "wrong" but really bad style. In my opinion, we should get rid of all commas.
> 
> 
> 
> 4) Regarding the follow up questions we had sent April 14, we have made some related updates.  Please review and confirm the following:
> 
> -edited our previously suggested sentence to the Terminology section to remove “to-be-signed bytes”.
> -added a sentence to the Terminology section regarding the term “claim”.
> -updated the reference to RFC 9052 to instead point to STD 96 to match the previously accepted additional sentence to the Terminology section.
> -made the update described in (5) below.
> -still have the question described in (6) below.
> 
> Other than these issues, we believe all of our concerns from that mail have been resolved.
> 
> 5) Regarding this question/answer pair from April 14:
> 
> <!--[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.
> —>
> 
> This text still does not parse for us… Please review and approve our further update to the first sentence of Section 4.2.
> 
> Previous:
> 
>    Similar to COSE Key Type Parameters [IANA.cose_header-parameters],
>    for example EC2 keys (1: 2) require and give meaning to specific
>    parameters, such as -1 (crv), -2 (x), -3 (y), -4 (d).  
> Current:
>    As is the case for COSE Key Type Parameters
>    [IANA.cose_header-parameters], EC2 keys (1: 2) require and give
>    meaning to specific parameters, such as -1 (crv), -2 (x), -3 (y), and
>    -4 (d).  RFC9162_SHA256 (395: 1) supports both (-1) inclusion and
>    (-2) consistency proofs.
> 
> 6) Regarding the following query/response from April 14:
> 
> <!--[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?  If you remove the parenthetical, it would read as:
> 
> First the verifier applies the inclusion proof to a possible entry bytes.
> 
> Again, apologies for any confusion in the crossed mails/versions, but please review more carefully than usual and let us know if we’ve bundled anything here.
> 
> 
>   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 (comprehensive)
>    https://www.rfc-editor.org/authors/rfc9942-rfcdiff.html (side by side)
> 
>    https://www.rfc-editor.org/authors/rfc9942-auth48diff.html (AUTH48 changes only)
>    https://www.rfc-editor.org/authors/rfc9942-auth48rfcdiff.html (side by side)
> 
>    https://www.rfc-editor.org/authors/rfc9942-lastdiff.html (last version to this)
>    https://www.rfc-editor.org/authors/rfc9942-lastrfcdiff.html (side by side)
> 
>   The Final Review page for this document is viewable at:
> 
> 
> Thank you.
> 
> Megan Ferguson 
> RFC Production Center
> 
> > On Jun 4, 2026, at 8:39 AM, Henk Birkholz <[e-mail]> wrote:
> > 
> > +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>
> >>     >
> > 
>