[auth48] Re: [EXTERNAL] Document intake questions about <draft-ietf-lamps-pq-composite-sigs-19>

[Mike Ounsworth <[e-mail]>]

Hi Sarah,

A) Good.

B) Okay. I recognize that this is a complicated draft, further complicated by our use of kramdown ::include sucking in auto-generated content. I recognize that this could make the final edits more annoying since some edits to the xml will need to be back-ported to python, the python re-run, mk -> xml, and then check that all of that still matches the edited xml. The goal is to make sure that the reference implementation in python doesn't get out of sync with the final RFC.

I'm happy to spend as much time as needed to get this right, so please keep me in the loop and let me know how I can help.

C) Correct.



-Mike 

"Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.


"An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr

On Tuesday, April 28th, 2026 at 4:41 PM, Sarah Tarrant <[e-mail]> wrote:

> Hi Mike,
> 
> Thank you for the speedy response!
> 
> A) We will reference the updated sourcecode at https://github.com/cabo/kramdown-rfc when formatting the sourcecode types.
> 
> B) Since we are unable to work with markdown files that are not self-contained, we will use the xml file for processing during AUTH48 and publishing.
> 
> C) Just to clarify the GitHub usernames, is the following correct?
> 
>   ounsworth: you
>   janklaussner: Jan Klaussner
>   johngray-dev: John Gray
>   opencrypto: Massimiliano Pala
>   sfluhrer: Scott Fluhrer
> 
> Sincerely,
> Sarah Tarrant
> RFC Production Center
> 
> > On Apr 28, 2026, at 1:56 PM, Mike Ounsworth <[e-mail]> wrote:
> >
> > Sourcecode tags are now updated on
> >
> > https://github.com/lamps-wg/draft-composite-sigs/blob/main/draft-ietf-lamps-pq-composite-sigs.md
> >
> >
> > -Mike
> >
> > "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> >
> >
> > "An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr
> >
> > On Tuesday, April 28th, 2026 at 1:35 PM, Mike Ounsworth <[e-mail]> wrote:
> >
> >> I'm sorry. I hit SEND prematurely. I have not yet updated the version in github with sourcecode tags.
> >>
> >>
> >>
> >> -Mike
> >>
> >> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> >>
> >>
> >> "An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr
> >>
> >> On Tuesday, April 28th, 2026 at 1:25 PM, Mike Ounsworth <[e-mail]> wrote:
> >>
> >>> Hi Sarah,
> >>>
> >>>
> >>> A) Regarding the sourcecode
> >>>
> >>> I have updated <> with proper sourcecode tags.
> >>>
> >>>
> >>>
> >>> B) Regarding the markdown pilot
> >>>
> >>>> To make this draft work in kramdown-rfc, we would need the markdown file to be self-contained
> >>>
> >>> I'm not sure what you mean by this. "{::include" is a standard feature of kramdown-rfc; you can see it described here if you CTRL+F for "::include":
> >>>
> >>> https://github.com/cabo/kramdown-rfc
> >>>
> >>> The draft does build with standard kramdown-rfc, it's just not self-contained in one .md file, but instead a collection of .md and .json files.
> >>>
> >>> Well over 50% of the page count of the draft is generated by python scripts -- that's all the tables, test vectors, and IANA Considerations. We did it this way because the authors were making too many copy&paste errors -- it's things like, the measured numerical values in the tables wobble a little bit on each run of the test vectors, so if you're not super duper careful, you can get the various table out of sync with each other. So, I'm really hesitant to go back to manual copy&pasting into a self-contained .md file at this late stage now that the draft won't receive any more careful top-to-bottom review by the public.
> >>>
> >>> Another consequence of this is that it's possible that the RPC wants to make some editorial changes to the script-generated tables. Having the contents of the draft and the reference implementation get out-of-sync could cause other problems down the line when people are trying to validate their implementations against the reference implementation. So I suggest that if the RPC wants to make changes inside the /src folder, let the authors know and we can make the changes inside the python scripts and re-run them to generate new markdown and json files.
> >>>
> >>> I'm happy to spend time helping the RPC get this going, feel free to shoot me a meeting invite for a screenshare session.
> >>>
> >>>
> >>>
> >>> C) Regarding the AUTH48 in GitHub pilot
> >>> Sure. Let's try that.
> >>> Authors: ounsworth, janklaussner, johngray-dev, opencrypto, sfluhrer
> >>> Shepherd: russhousley
> >>>
> >>> -Mike
> >>>
> >>> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> >>>
> >>>
> >>> "An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr
> >>>
> >>> On Tuesday, April 28th, 2026 at 11:42 AM, Sarah Tarrant <[e-mail]> wrote:
> >>>
> >>>> Hi Mike,
> >>>>
> >>>> Thank you for your reply.
> >>>>
> >>>> I have some followup comments/discussion before moving ahead to EDIT state.
> >>>>
> >>>> A) Regarding the sourcecode:
> >>>> I believe it's always worthwhile to tag sourcecode! Feel free to send along notes on which elements should be marked as sourcecode as well as the types. Or, if you'd prefer, you can update a self-contained markdown file with the sourcecode types and send that to us.
> >>>>
> >>>> B) Regarding the markdown pilot:
> >>>> To make this draft work in kramdown-rfc, we would need the markdown file to be self-contained -- we can't use the markdown at the link you provided because of the "include" elements. It sounds, though, that working in markdown would benefit the authors in this case! Would you like to provide a self-contained markdown file?
> >>>>
> >>>> C) Regarding the AUTH48 in GitHub pilot:
> >>>> We would make the repos ourselves and include all necessary approvers at the time of AUTH48, but I appreciate the thoughts on using the existing repos! If you would like to have this document processed in GitHub during AUTh48, provide all author, AD, and/or document shepherd GitHub usernames.
> >>>>
> >>>> Sincerely,
> >>>> Sarah Tarrant
> >>>> RFC Production Center
> >>>>
> >>>>> On Apr 24, 2026, at 11:49 PM, Mike Ounsworth <[e-mail]> wrote:
> >>>>>
> >>>>> Hi Sarah,
> >>>>>
> >>>>> I will reply to the questions on behalf of the author team.
> >>>>>
> >>>>>
> >>>>> 1)
> >>>>> Abstract looks good.
> >>>>> Author's addresses look good, unless @Max Pala wants to change his affiliation to Wells Fargo? If he doesn't reply, you're probably good to leave it as OpenCA, which he still owns.
> >>>>> I think we've been good about keeping Contributors and Acknowledgements up to date. I leave it to your judgment if there's a better way to format that super long list of names.
> >>>>>
> >>>>>
> >>>>> 2) Style
> >>>>>
> >>>>> You're going to discover, if you haven't already, that this draft has an absolutely enormous normative references list. This draft is essentially compiling 20 years of cryptography RFCs into one mega draft. It has been an absolute roller coaster to make sure that our terminology and notation is consistent with the definitions and notations scattered across all of the references. Honestly, it's a lot. If RPC is changing stuff that feels style-y about the cryptographic parts, I'll be happy to help make sure it stays consistent with all the upstream definitions.
> >>>>>
> >>>>> We recieved an IESG COMMENT that the definitions in Section 1.1 look weird as capitals -- for example "ML-DSA" and "PKI" are acronyms and so make sense to be capitalized, but "COMPOSITE CRYPTOGRAPHIC ELEMENT" looks weird capitalized. I didn't make any change for that comment, but I would appreciate input.
> >>>>>
> >>>>> 3) References check
> >>>>>
> >>>>> This draft has a lot of references!
> >>>>>
> >>>>> idnits doesn't report any issues with downrefs or obsolete refs. I just did a manual scan and I don't see any references out-of-place. Idnits is wrong that [RFC5758] and [SEC1] are unused references; they are referenced from inside the tables in Appendix B.
> >>>>>
> >>>>> We reference X9.62_2005. Even if X9 has published a newer version, I think we want to reference the 2005 version because that's where we got the encoding from, and that's the version that everyone implements (as far as I know).
> >>>>>
> >>>>> [I-D.ietf-pquip-hybrid-signature-spectrums] and [I-D.ietf-pquip-pqc-engineers] are likely to have RFC numbers before this draft is published.
> >>>>>
> >>>>> All the other references look sane to me.
> >>>>>
> >>>>>
> >>>>> 4)
> >>>>> Contentious sections: sassy answer: basically the whole draft. Less sassy answer: there has been a lot of public attention on this draft (as evidenced by the length of the Acknowledgements section). In my opinion, this draft has been well-nit-picked both technically and grammatically. In particular, the Securtiy Considerations text has been carefully crafted to satisfy a number of parties who don't exactly agree on the security properties that this draft is providing.
> >>>>>
> >>>>> Sections that need to be removed.
> >>>>> The "About This Document" section right after the abstract.
> >>>>> I think you typically remove "IANA Considerations" (Section 8), right?
> >>>>>
> >>>>>
> >>>>> Are there any instances of repeated text/sections that should be edited the same way?
> >>>>> There is a fair amount of repetition across the document by the nature of the fact that it's defining 18 different cryptographic algorithms that are all similar-but-different to each other.
> >>>>>
> >>>>>
> >>>>> 5)
> >>>>> I believe that fixed-width font (code blocks / inline code), italics, and bolds are used consistently. But it's possible that we missed some. For example, I tried to use backticks, when referring to a variable or function from a code block, and not use them when speaking in prose; for example the function `ML-DSA.KeyGen` would be in backticks (fixed-width font) if refering to a listed function inside a code block, but writen as ML-DSA Keygen if referring to the the concept more generally. But I might not have been 100% consistent on this.
> >>>>>
> >>>>> 6) source code blocks
> >>>>> This draft contains two types of source code blocks: asn.1 and algorithm pseudo-code (which is in a python-like syntax that we sortof borrowed from RFC 9180 and sortof invented).
> >>>>>
> >>>>> Taking a quick skim, it looks like:
> >>>>>    •
> >>>>> The pseudocode blocks are un-tagged (which I believe is correct)
> >>>>>    • The asn.1 blocks in the body are correctly tagged.
> >>>>>    • Appendix C contains several dozen ASN.1 blocks that have not been tagged. Is it worth tagging them?
> >>>>>    • Appendix E is one giant JSON block. Is that worth tagging?
> >>>>>
> >>>>>
> >>>>>
> >>>>> 7) Would you like to participate in the RPC Pilot Test for editing in kramdown-rfc?
> >>>>> Yes please!
> >>>>> We make fairly extensive use of kramdown features such as tables and file includes. In fact, all of the tables (which is more than 50% of the draft by page count) are generated by a python program, output to markdown .md files, and then included into the draft using the kramdown {::include } feature. We did it this way after we got tired of introducing copy&paste errors across the different sections. So backporting diffs from the xml version into the kramdown version might prove to be complicated and working in kramdown will almost certainly make our lives easier 🙂
> >>>>>
> >>>>> Our github repo is here:
> >>>>> https://github.com/lamps-wg/draft-composite-sigs
> >>>>>
> >>>>>
> >>>>> 8) Would you like to participate in the RPC Pilot Test for completing AUTH48 in GitHub?
> >>>>>
> >>>>> I'm not opposed to this; I always like trying new things, but it sounds like your process requires us to create a new repo in the rfc-editor org. Given that our kramdown source is not a single .md file, but a collection of .md, .asn, and .json files that all get sucked into the document by {::include } commands, and the authors have been working exclusively with MT's github-based build tools for about a year, it might turn out to be complicated to move it to a new repo and get the kramdown building properly again (or it might not, I could be pleasantly surprised). Note that the python programs in /src are not strictly needed to build the draft, but if the RPC wants to make any changes to any of the tables that are generated by those scripts, then you'll have to copy the python stuff over to your repo and get it working, and I'm not sure that will be worth the effort.
> >>>>>
> >>>>> If you're willing to open Issues and PRs against our repo (above) that would likely be simpler for everyone. Like, PRs for text that you can edit directly, and Issues for anything that needs changes in the python or whatever, and we can change that.
> >>>>>
> >>>>> -Mike
> >>>>>
> >>>>> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> >>>>>
> >>>>> "An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr
> >>>>>
> >>>>> On Thursday, April 23rd, 2026 at 10:52 PM, Mike Ounsworth <[e-mail]> wrote:
> >>>>>> (adding my other email address — I'll reply to the questions tomorrow)
> >>>>>>
> >>>>>> ---
> >>>>>> Mike Ounsworth
> >>>>>> From: Sarah Tarrant <[e-mail]>
> >>>>>> Sent: Thursday, April 23, 2026 11:32 AM
> >>>>>> To: Mike Ounsworth <[e-mail]>; John Gray <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> >>>>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> >>>>>> Subject: [EXTERNAL] Document intake questions about <draft-ietf-lamps-pq-composite-sigs-19>
> >>>>>> Author(s),
> >>>>>>
> >>>>>> Congratulations, your document has been successfully added to the RFC Editor queue!
> >>>>>> The team at the RFC Production Center (RPC) is looking forward to working with you
> >>>>>> as your document moves forward toward publication. To help reduce processing time
> >>>>>> and improve editing accuracy, please respond to the questions below. Please confer
> >>>>>> with your coauthors (or authors of other documents if your document is in a
> >>>>>> cluster) as necessary prior to taking action in order to streamline communication.
> >>>>>> If your document has multiple authors, only one author needs to reply to this
> >>>>>> message.
> >>>>>>
> >>>>>> As you read through the rest of this email:
> >>>>>>
> >>>>>> * If you need/want to make updates to your document, we encourage you to make those
> >>>>>> changes and resubmit to the Datatracker. This allows for the easy creation of diffs,
> >>>>>> which facilitates review by interested parties (e.g., authors, ADs, doc shepherds).
> >>>>>> * If you feel no updates to the document are necessary, please reply with any
> >>>>>> applicable rationale/comments.
> >>>>>>
> >>>>>>
> >>>>>> Please note that the RPC team will not work on your document until we hear from you
> >>>>>> (that is, your document will remain in AUTH state until we receive a reply). Even
> >>>>>> if you don't have guidance or don't feel that you need to make any updates to the
> >>>>>> document, you need to let us know. After we hear from you, your document will start
> >>>>>> moving through the queue. You will be able to review and approve our updates
> >>>>>> during AUTH48.
> >>>>>>
> >>>>>> Please feel free to contact us with any questions you may have at
> >>>>>> [e-mail].
> >>>>>>
> >>>>>> Thank you!
> >>>>>> The RPC Team
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> 1) As there may have been multiple updates made to the document during Last Call,
> >>>>>> please review the current version of the document:
> >>>>>>
> >>>>>> * Is the text in the Abstract still accurate?
> >>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments
> >>>>>> sections current?
> >>>>>>
> >>>>>>
> >>>>>> 2) Please share any style information that could help us with editing your
> >>>>>> document. For example:
> >>>>>>
> >>>>>> * Is your document's format or its terminology based on another document,
> >>>>>> WG style guide, etc.? If so, please provide a pointer to that information
> >>>>>> (e.g., "This document's terminology should match DNS terminology in
> >>>>>> RFC 9499." or "This document uses the style info at
> >>>>>> <https://urldefense.com/v3/__https://httpwg.org/admin/editors/style-guide__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaj644jyg$>.").
> >>>>>> * Is there a general pattern of capitalization or formatting of terms that
> >>>>>> editors can follow (e.g., "Field names should have initial capitalization."
> >>>>>> or "Parameter names should be in double quotes." or "<tt/> should be used
> >>>>>> for token names." etc.)?
> >>>>>>
> >>>>>>
> >>>>>> 3) Please carefully review the entries and their URLs in the
> >>>>>> References section with the following in mind. Note that we will
> >>>>>> update as follows unless we hear otherwise at this time:
> >>>>>>
> >>>>>> * References to obsoleted RFCs will be updated to point to the current
> >>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322
> >>>>>> (RFC Style Guide).
> >>>>>>
> >>>>>> * References to I-Ds that have been replaced by another I-D will be
> >>>>>> updated to point to the replacement I-D.
> >>>>>>
> >>>>>> * References to documents from other organizations that have been
> >>>>>> superseded will be updated to their superseding version.
> >>>>>>
> >>>>>> Note: To check for outdated RFC and I-D references, you can use
> >>>>>> idnits <https://urldefense.com/v3/__https://author-tools.ietf.org/idnits__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaExskQZU$>. You can also help the
> >>>>>> IETF Tools Team by testing idnits3 <https://urldefense.com/v3/__https://author-tools.ietf.org/idnits3/__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaoThDYmc$>
> >>>>>> with your document and reporting any issues to them.
> >>>>>>
> >>>>>>
> >>>>>> 4) Is there any text that requires special handling? For example:
> >>>>>> * Are there any sections that were contentious when the document was drafted?
> >>>>>> * Are any sections that need to be removed before publication marked as such
> >>>>>> (e.g., Implementation Status sections (per RFC 7942)).
> >>>>>> * Are there any instances of repeated text/sections that should be edited
> >>>>>> the same way?
> >>>>>>
> >>>>>>
> >>>>>> 5) This document uses one or more of the following text styles.
> >>>>>> Are these elements used consistently?
> >>>>>>
> >>>>>> * fixed width font (<tt/> or `)
> >>>>>> * italics (<em/> or *)
> >>>>>> * bold (<strong/> or **)
> >>>>>>
> >>>>>>
> >>>>>> 6) This document contains sourcecode:
> >>>>>>
> >>>>>> * Does the sourcecode validate?
> >>>>>> * Some sourcecode types (e.g., YANG) require certain references and/or text
> >>>>>> in the Security Considerations section. Is this information correct?
> >>>>>> * Is the sourcecode type indicated in the XML? (See information about
> >>>>>> types: https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJca3NMVS5s$.)
> >>>>>>
> >>>>>>
> >>>>>> 7) Would you like to participate in the RPC Pilot Test for editing in kramdown-rfc?
> >>>>>> If so, please let us know and provide a self-contained kramdown-rfc file. For more
> >>>>>> information about this experiment, see:
> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcamVQTg2E$.
> >>>>>>
> >>>>>>
> >>>>>> 8) Would you like to participate in the RPC Pilot Test for completing AUTH48 in
> >>>>>> GitHub? If so, please let us know and provide all author, AD, and/or document
> >>>>>> shepherd GitHub usernames. For more information about this experiment, see:
> >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaSLB_o5E$.
> >>>>>>
> >>>>>>
> >>>>>> 9) Is there anything else that the RPC should be aware of while editing this
> >>>>>> document?
> >>>>>>
> >>>>>>> On Apr 23, 2026, at 9:21 AM, [e-mail] wrote:
> >>>>>>>
> >>>>>>> Author(s),
> >>>>>>>
> >>>>>>> Your document draft-ietf-lamps-pq-composite-sigs-19, which has been approved for publication as
> >>>>>>> an RFC, has been added to the RFC Editor queue
> >>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/current_queue.php__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJca_-8hwzk$>.
> >>>>>>>
> >>>>>>> If your XML file was submitted using the I-D submission tool
> >>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/submit/__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcazr_zszc$>, we have already retrieved it
> >>>>>>> and have started working on it.
> >>>>>>>
> >>>>>>> If you did not submit the file via the I-D submission tool, or
> >>>>>>> if you have an updated version (e.g., updated contact information),
> >>>>>>> please send us the file at this time by attaching it
> >>>>>>> in your reply to this message and specifying any differences
> >>>>>>> between the approved I-D and the file that you are providing.
> >>>>>>>
> >>>>>>> You will receive a separate message from us asking for style input.
> >>>>>>> Please respond to that message. When we have received your response,
> >>>>>>> your document will then move through the queue. The first step that
> >>>>>>> we take as your document moves through the queue is converting it to
> >>>>>>> RFCXML (if it is not already in RFCXML) and applying the formatting
> >>>>>>> steps listed at <https://urldefense.com/v3/__https://www.rfc-editor.org/pubprocess/how-we-update/__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcacy1T1Dc$>.
> >>>>>>> Next, we will edit for clarity and apply the style guide
> >>>>>>> (<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcawBEyluE$>).
> >>>>>>>
> >>>>>>> You can check the status of your document at
> >>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/current_queue.php__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJca_-8hwzk$>.
> >>>>>>>
> >>>>>>> You will receive automatic notifications as your document changes
> >>>>>>> queue state (for more information about these states, please see
> >>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/about/queue/__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaah77amI$>). When we have completed
> >>>>>>> our edits, we will move your document to AUTH48 state and ask you
> >>>>>>> to perform a final review of the document.
> >>>>>>>
> >>>>>>> Please let us know if you have any questions.
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>> The RFC Editor Team
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
> >>>>
> >>>>
> >>>>
> 
>