Return-Path: X-Original-To: auth48archive@mail2.ietf.org Delivered-To: auth48archive@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 89756E52FAB7 for ; Tue, 28 Apr 2026 15:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777416235; bh=93OXRUXDNkLfcVC4gXffzsm6mxFevIkYQUiwPJucnds=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=pZer6MT/lvbDE6OCmeyVX8VLnk7s0kllGuR/0FwzouVQe8QAdhq0O1MEvqMwwZ0N3 BIwnujXMovtjYNP2rt+HAqQxTOn0ntjgwcr1z2yjzvIGsa1zH7NUqpDMpKZVJ6SsHB kxXujPiQAWshgmPxqbCVFwUJ6DFKg+6FFL1RsUvU= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ounsworth.ca Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4rK2r46SF0V for ; Tue, 28 Apr 2026 15:43:54 -0700 (PDT) Received: from mail-24422.protonmail.ch (mail-24422.protonmail.ch [109.224.244.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E0BA8E52FAAF for ; Tue, 28 Apr 2026 15:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ounsworth.ca; s=protonmail; t=1777416231; x=1777675431; bh=zqqgvzHDtLyVYJXI+mCJNYEZYHkuQByl8aXkmSn7qIc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=UQeYG81IAu+D2TF6qkvMXWk1yhxKu4tXKE9hEnZrAQuMeFa4A8A1dDTWbRWt0K9Mp Br8XN0N7o8lXT/kKco/eHLhtlX80Vtqh4/jFCPpDc4f4iXNZ9gSLFyeCkab52hG0tu jYCX6bfNJIC7eA5K/fvUhG7kP+4R/ERll5VM/d78mN2abxefMxXRSRBuvMm8GNvCzB kqvXqRVOvyB5Ixp1Vg7YR55Z2Ja9ZvbjcTOcWx9/uVsf4BKAZzjtgA268Snzqv6uQs wPXVSZMVYxyx/xI3OTSuEh7DMYOX4+24cUqy+htkxnR9e57505JGVKWdei+6toXoMU bMIoKxP6BT83g== Date: Tue, 28 Apr 2026 22:43:49 +0000 To: Sarah Tarrant From: Mike Ounsworth Message-ID: In-Reply-To: <2CA89187-562C-47FA-B45D-23C8A5ADD0B4@staff.rfc-editor.org> References: <20260423152114.B901DC0004D7@rfcpa.rfc-editor.org> <92Bq3sWiTMQfw3tbAXTtEau-kBkGtHw4JCJltIJRKmMiwEp0HIvbn2d2Eoq435DNbI_CRbMpjsJ_MUCOrFH-YV9xoU8OKQ4ZsRLoDRuODVs=@ounsworth.ca> <2CA89187-562C-47FA-B45D-23C8A5ADD0B4@staff.rfc-editor.org> Feedback-ID: 61358882:user:proton X-Pm-Message-ID: b5871a79b718965c78dde62a533cc57bb715e743 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: XW5N5X5NPLJZXIEUQJY76KQHVG2JRREI X-Message-ID-Hash: XW5N5X5NPLJZXIEUQJY76KQHVG2JRREI X-MailFrom: mike@ounsworth.ca X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Mike Ounsworth , John Gray , "director@openca.org" , "jan.klaussner@bdr.de" , "sfluhrer@cisco.com" , "housley@vigilsec.com" , "debcooley1@gmail.com" , "rfc-editor@rfc-editor.org" , "auth48archive@rfc-editor.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_=5BEXTERNAL=5D_Document_intake_questions_about_?= =?utf-8?q?=3Cdraft-ietf-lamps-pq-composite-sigs-19=3E?= List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 recog= nize 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 -> xm= l, and then check that all of that still matches the edited xml. The goal i= s 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=C2=A0 "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.=E2=80=9D -- Niels Bo= hr On Tuesday, April 28th, 2026 at 4:41 PM, Sarah Tarrant wrote: > Hi Mike, >=20 > Thank you for the speedy response! >=20 > A) We will reference the updated sourcecode at https://github.com/cabo/kr= amdown-rfc when formatting the sourcecode types. >=20 > B) Since we are unable to work with markdown files that are not self-cont= ained, we will use the xml file for processing during AUTH48 and publishing= . >=20 > C) Just to clarify the GitHub usernames, is the following correct? >=20 > ounsworth: you > janklaussner: Jan Klaussner > johngray-dev: John Gray > opencrypto: Massimiliano Pala > sfluhrer: Scott Fluhrer >=20 > Sincerely, > Sarah Tarrant > RFC Production Center >=20 > > On Apr 28, 2026, at 1:56=E2=80=AFPM, Mike Ounsworth = wrote: > > > > Sourcecode tags are now updated on > > > > https://github.com/lamps-wg/draft-composite-sigs/blob/main/draft-ietf-l= amps-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.=E2=80=9D -- Niel= s Bohr > > > > On Tuesday, April 28th, 2026 at 1:35 PM, Mike Ounsworth 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.=E2=80=9D -- Nie= ls Bohr > >> > >> On Tuesday, April 28th, 2026 at 1:25 PM, Mike Ounsworth 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 featur= e of kramdown-rfc; you can see it described here if you CTRL+F for "::inclu= de": > >>> > >>> https://github.com/cabo/kramdown-rfc > >>> > >>> The draft does build with standard kramdown-rfc, it's just not self-c= ontained 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 s= cripts -- 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 l= ittle bit on each run of the test vectors, so if you're not super duper car= eful, you can get the various table out of sync with each other. So, I'm re= ally hesitant to go back to manual copy&pasting into a self-contained .md f= ile at this late stage now that the draft won't receive any more careful to= p-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 c= ontents of the draft and the reference implementation get out-of-sync could= cause other problems down the line when people are trying to validate thei= r implementations against the reference implementation. So I suggest that i= f the RPC wants to make changes inside the /src folder, let the authors kno= w 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 experienc= e all the mistakes that one can make in a very narrow field.=E2=80=9D -- Ni= els Bohr > >>> > >>> On Tuesday, April 28th, 2026 at 11:42 AM, Sarah Tarrant 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 sen= d along notes on which elements should be marked as sourcecode as well as t= he types. Or, if you'd prefer, you can update a self-contained markdown fil= e 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 prov= ided 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 approver= s at the time of AUTH48, but I appreciate the thoughts on using the existin= g 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=E2=80=AFPM, Mike Ounsworth 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 le= ave it as OpenCA, which he still owns. > >>>>> I think we've been good about keeping Contributors and Acknowledgem= ents up to date. I leave it to your judgment if there's a better way to for= mat that super long list of names. > >>>>> > >>>>> > >>>>> 2) Style > >>>>> > >>>>> You're going to discover, if you haven't already, that this draft h= as an absolutely enormous normative references list. This draft is essentia= lly compiling 20 years of cryptography RFCs into one mega draft. It has bee= n an absolute roller coaster to make sure that our terminology and notation= is consistent with the definitions and notations scattered across all of t= he references. Honestly, it's a lot. If RPC is changing stuff that feels st= yle-y about the cryptographic parts, I'll be happy to help make sure it sta= ys consistent with all the upstream definitions. > >>>>> > >>>>> We recieved an IESG COMMENT that the definitions in Section 1.1 loo= k weird as capitals -- for example "ML-DSA" and "PKI" are acronyms and so m= ake sense to be capitalized, but "COMPOSITE CRYPTOGRAPHIC ELEMENT" looks we= ird capitalized. I didn't make any change for that comment, but I would app= reciate 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 referenc= ed 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 t= he encoding from, and that's the version that everyone implements (as far a= s 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 e= videnced by the length of the Acknowledgements section). In my opinion, thi= s draft has been well-nit-picked both technically and grammatically. In par= ticular, the Securtiy Considerations text has been carefully crafted to sat= isfy 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), rig= ht? > >>>>> > >>>>> > >>>>> Are there any instances of repeated text/sections that should be ed= ited the same way? > >>>>> There is a fair amount of repetition across the document by the nat= ure of the fact that it's defining 18 different cryptographic algorithms th= at are all similar-but-different to each other. > >>>>> > >>>>> > >>>>> 5) > >>>>> I believe that fixed-width font (code blocks / inline code), italic= s, 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 func= tion from a code block, and not use them when speaking in prose; for exampl= e 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 Key= gen if referring to the the concept more generally. But I might not have be= en 100% consistent on this. > >>>>> > >>>>> 6) source code blocks > >>>>> This draft contains two types of source code blocks: asn.1 and algo= rithm 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: > >>>>> =E2=80=A2 > >>>>> The pseudocode blocks are un-tagged (which I believe is correct) > >>>>> =E2=80=A2 The asn.1 blocks in the body are correctly tagged. > >>>>> =E2=80=A2 Appendix C contains several dozen ASN.1 blocks that ha= ve not been tagged. Is it worth tagging them? > >>>>> =E2=80=A2 Appendix E is one giant JSON block. Is that worth tagg= ing? > >>>>> > >>>>> > >>>>> > >>>>> 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 an= d 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 e= rrors across the different sections. So backporting diffs from the xml vers= ion into the kramdown version might prove to be complicated and working in = kramdown will almost certainly make our lives easier =F0=9F=99=82 > >>>>> > >>>>> 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 completi= ng AUTH48 in GitHub? > >>>>> > >>>>> I'm not opposed to this; I always like trying new things, but it so= unds like your process requires us to create a new repo in the rfc-editor o= rg. Given that our kramdown source is not a single .md file, but a collecti= on 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 compl= icated to move it to a new repo and get the kramdown building properly agai= n (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 g= et 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) t= hat would likely be simpler for everyone. Like, PRs for text that you can e= dit directly, and Issues for anything that needs changes in the python or w= hatever, and we can change that. > >>>>> > >>>>> -Mike > >>>>> > >>>>> "Knowing is a barrier which prevents learning" -- Frank Herbert, Du= ne. > >>>>> > >>>>> "An expert is a person who has found out by his own painful experie= nce all the mistakes that one can make in a very narrow field.=E2=80=9D -- = Niels Bohr > >>>>> > >>>>> On Thursday, April 23rd, 2026 at 10:52 PM, Mike Ounsworth wrote: > >>>>>> (adding my other email address =E2=80=94 I'll reply to the questio= ns tomorrow) > >>>>>> > >>>>>> --- > >>>>>> Mike Ounsworth > >>>>>> From: Sarah Tarrant > >>>>>> Sent: Thursday, April 23, 2026 11:32 AM > >>>>>> To: Mike Ounsworth ; John Gray ; director@openca.org ; jan.klaussner@= bdr.de ; sfluhrer@cisco.com > >>>>>> Cc: housley@vigilsec.com ; debcooley1@gmail.= com ; rfc-editor@rfc-editor.org ; auth48archive@rfc-editor.org > >>>>>> Subject: [EXTERNAL] Document intake questions about > >>>>>> 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 belo= w. Please confer > >>>>>> with your coauthors (or authors of other documents if your documen= t is in a > >>>>>> cluster) as necessary prior to taking action in order to streamlin= e communication. > >>>>>> If your document has multiple authors, only one author needs to re= ply 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 rep= ly 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 do= cument will start > >>>>>> moving through the queue. You will be able to review and approve o= ur updates > >>>>>> during AUTH48. > >>>>>> > >>>>>> Please feel free to contact us with any questions you may have at > >>>>>> rfc-editor@rfc-editor.org. > >>>>>> > >>>>>> Thank you! > >>>>>> The RPC Team > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> 1) As there may have been multiple updates made to the document du= ring 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 edit= ing your > >>>>>> document. For example: > >>>>>> > >>>>>> * Is your document's format or its terminology based on another do= cument, > >>>>>> WG style guide, etc.? If so, please provide a pointer to that info= rmation > >>>>>> (e.g., "This document's terminology should match DNS terminology i= n > >>>>>> RFC 9499." or "This document uses the style info at > >>>>>> ."). > >>>>>> * Is there a general pattern of capitalization or formatting of te= rms that > >>>>>> editors can follow (e.g., "Field names should have initial capital= ization." > >>>>>> or "Parameter names should be in double quotes." or " 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 cur= rent > >>>>>> 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 b= e > >>>>>> 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 . You can also help the > >>>>>> IETF Tools Team by testing idnits3 > >>>>>> 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 w= as drafted? > >>>>>> * Are any sections that need to be removed before publication mark= ed 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 ( or `) > >>>>>> * italics ( or *) > >>>>>> * bold ( or **) > >>>>>> > >>>>>> > >>>>>> 6) This document contains sourcecode: > >>>>>> > >>>>>> * Does the sourcecode validate? > >>>>>> * Some sourcecode types (e.g., YANG) require certain references an= d/or text > >>>>>> in the Security Considerations section. Is this information correc= t? > >>>>>> * Is the sourcecode type indicated in the XML? (See information ab= out > >>>>>> types: https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/= wiki/doku.php?id=3Dsourcecode-types__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQo= U0Wa9Bo29KsbBCngwSd7_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-rf= c file. For more > >>>>>> information about this experiment, see: > >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/do= ku.php?id=3Dpilot_test_kramdown_rfc__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltrn-PNQo= U0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcamVQTg2E$. > >>>>>> > >>>>>> > >>>>>> 8) Would you like to participate in the RPC Pilot Test for complet= ing 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 experim= ent, see: > >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/do= ku.php?id=3Drpc-github-phase-0-pilot-test__;!!FJ-Y8qCqXTj2!bsw-H15Sdshfxltr= n-PNQoU0Wa9Bo29KsbBCngwSd7_HSWJV34X_6SKc_Qy86Fig_uNmEWsNpgo9LUPBtYEguJcaSLB= _o5E$. > >>>>>> > >>>>>> > >>>>>> 9) Is there anything else that the RPC should be aware of while ed= iting this > >>>>>> document? > >>>>>> > >>>>>>> On Apr 23, 2026, at 9:21=E2=80=AFAM, rfc-editor@rfc-editor.org wr= ote: > >>>>>>> > >>>>>>> Author(s), > >>>>>>> > >>>>>>> Your document draft-ietf-lamps-pq-composite-sigs-19, which has be= en approved for publication as > >>>>>>> an RFC, has been added to the RFC Editor queue > >>>>>>> . > >>>>>>> > >>>>>>> If your XML file was submitted using the I-D submission tool > >>>>>>> , 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 inpu= t. > >>>>>>> Please respond to that message. When we have received your respon= se, > >>>>>>> your document will then move through the queue. The first step th= at > >>>>>>> we take as your document moves through the queue is converting it= to > >>>>>>> RFCXML (if it is not already in RFCXML) and applying the formatti= ng > >>>>>>> steps listed at . > >>>>>>> Next, we will edit for clarity and apply the style guide > >>>>>>> (). > >>>>>>> > >>>>>>> You can check the status of your document at > >>>>>>> . > >>>>>>> > >>>>>>> You will receive automatic notifications as your document changes > >>>>>>> queue state (for more information about these states, please see > >>>>>>> ). 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 s= olely for the use of the individual or entity to whom they are addressed. I= f this message has been sent to you in error, you must not copy, distribute= or disclose of the information it contains. Please notify Entrust immediat= ely and delete the message from your system. > >>>> > >>>> > >>>> >=20 >