Hi Paul, Authors, (Taking over for Megan temporarily as she is offline for the rest of this week.)
Paul - Thank you for your response! We have noted your approval here: https://queue.rfc-editor.org/final-review/rfc9980/. Authors - As all of our queries have been resolved, we will begin preparing this document for publication. Thank you for your time! Best, Madison Church RFC Production Center > On Jun 16, 2026, at 8:52 AM, Paul Wouters > <[email protected]> wrote: > > > On Mon, Jun 15, 2026 at 11:07 PM Megan Ferguson > <[email protected]> wrote: > ADs, > > Just in case this is pending me as the then-AD at the time, > > > Just a friendly reminder that this document is ready to go once we hear back > from the AD on the following: > > > On Jun 1, 2026, at 9:12 AM, Megan Ferguson <[email protected]> > > wrote: > > > > Now we believe we just need AD input to wrap things up. > > > > *AD - Please weigh in on question 8 and the authors’ updates to resolve > > question 12 (copied below for convenience): > > > >>>> 8) <!--[rfced] [AD] The authors submitted a query about possible > >>>> downrefs suggested by IDNITs (see list below). This is not generally > >>>> something the RPC advises on. Upon conference between AD and authors, > >>>> please let us know if any updates/changes are necessary. > >>>> > >>>> Checking references for intended status: Proposed Standard > >>>> > >>>> (See RFCs 3967 and 4897 for information about using normative > >>>> references > >>>> to lower-maturity documents in RFCs) > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-203' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-204' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-205' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'IANA-OPENPGP' > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 3394 > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 7748 > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 8032 > >>>> > >>>>> From the authors: "We listed those references as normative as they > >>>> contain the algorithmic specifications needed. > >>>> > >>>> We would appreciate guidance from the RFC Editor Team if this should > >>>> be handled differently." > > The downrefs are fine. > >>>> > >>>> —> > > > > From Falko: > >> as I understand question 8, we still need to address the "downref" > >> problems: > >> - normative references to the FIPS specs: Can these simply be kept? > >> - normative reference to IANA registry: What is the right way here? > >> - normative references to "Informational" RFCs: It seems to me those need > >> some kind of annotation if we want to keep them as normative references. > >> But I don't understand the procedure. Can you point out the possible > >> options here? > > No need for any changes. > > > > > > And for question 12 (inclusive language): > >> 12) We did not find any issues regarding inclusive language. The word > >> 'traditional' is used in line with the definition of 'traditional > >> cryptographic algorithms' in RFC 9794. For clarity, we suggest to add this > >> term in Section 1.1.1. We propose the following change. We also believe > >> there should be a comma before the "and", please feel free to remove it if > >> that is wrong. > >> > >> Section 1.1.1 > >> > >> OLD: > >> Specifically, the terms "multi-algorithm", "composite" and "non-composite" > >> are used in correspondence with the definitions therein. > >> > >> NEW: > >> Specifically, the terms "multi-algorithm", "composite", "non-composite", > >> and "traditional" are used in correspondence with the definitions therein. > > That looks fine to me. > > Once we hear back some AD guidance on the above, we believe the document > will be ready to move forward in the publication process. > > No issues with the proposed Section 1.1.1 change and no issues with the > downrefs. Looks good to go. > > > Paul > > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9980.txt > > https://www.rfc-editor.org/authors/rfc9980.pdf > > https://www.rfc-editor.org/authors/rfc9980.html > > https://www.rfc-editor.org/authors/rfc9980.xml > > > > The diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9980-diff.html (comprehensive) > > https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > > > > https://www.rfc-editor.org/authors/rfc9980-auth48diff.html (Final Review > > changes only) > > https://www.rfc-editor.org/authors/rfc9980-auth48rfcdiff.html (side by > > side) > > > > https://www.rfc-editor.org/authors/rfc9980-alt-diff.html (to see IANA > > table/list changes) > > https://www.rfc-editor.org/authors/rfc9980-alt-rfcdiff.html (side by > > side) > > > > The Final Review status page for this document is viewable here: > > https://www.rfc-editor.org/auth48/rfc9980 > > > > Thank you. > > > > Megan Ferguson > > RFC Production Center > > > > > >> On May 30, 2026, at 2:25 PM, Aron Wussler <[email protected]> wrote: > >> > >> Hi Megan, > >> > >> I also reviewed and approve the document. > >> > >> Cheers, > >> Aron > >> > >> -- > >> Aron Wussler > >> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > >> > >> > >> On Friday, 29 May 2026 at 23:11, Megan Ferguson > >> <[email protected]> wrote: > >> > >>> Stavros, Johannes, and Falko, > >>> > >>> Thank you for your replies. > >>> > >>> We have updated as suggested by Falko (thank you for spotting that!) and > >>> reposted the files. > >>> > >>> We have also recorded your approvals of the document in its current form. > >>> We will assume your approval stands even if a coauthor submits further > >>> changes unless we hear objection at that time. Once we have approval from > >>> Aron and AD approval, this document should be ready to move forward in > >>> the publication process. > >>> > >>> The files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9980.txt > >>> https://www.rfc-editor.org/authors/rfc9980.pdf > >>> https://www.rfc-editor.org/authors/rfc9980.html > >>> https://www.rfc-editor.org/authors/rfc9980.xml > >>> > >>> The diff files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9980-diff.html (comprehensive) > >>> https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > >>> > >>> https://www.rfc-editor.org/authors/rfc9980-auth48diff.html (Final Review > >>> changes only) > >>> https://www.rfc-editor.org/authors/rfc9980-auth48rfcdiff.html (side by > >>> side) > >>> > >>> https://www.rfc-editor.org/authors/rfc9980-lastdiff.html (last version to > >>> this) > >>> https://www.rfc-editor.org/authors/rfc9980-lastrfcdiff.html (side by side) > >>> > >>> https://www.rfc-editor.org/authors/rfc9980-alt-diff.html (to see IANA > >>> table/list changes) > >>> https://www.rfc-editor.org/authors/rfc9980-alt-rfcdiff.html (side by side) > >>> > >>> The Final Review status page for this document is viewable here: > >>> https://www.rfc-editor.org/auth48/rfc9980 > >>> > >>> Thank you. > >>> > >>> Megan Ferguson > >>> RFC Production Center > >>> > >>>> On May 29, 2026, at 1:28 AM, Stavros Kousidis <[email protected]> > >>>> wrote: > >>>> > >>>> Hi Megan, > >>>> > >>>> Looks good for me, too. > >>>> > >>>> Thank you all > >>>> Stavros > >>>> > >>>> > >>>> Am 29. Mai 2026 07:50:59 MESZ schrieb Johannes Roth > >>>> <[email protected]>: > >>>> Hi Megan, > >>>> > >>>> Thanks for the quick action. I reviewed the document and it looks good > >>>> to me (aside from the comma issue that Falko mentioned). > >>>> > >>>> Best, > >>>> Johannes > >>>> > >>>> On 27.05.2026 18:59, Megan Ferguson wrote: > >>>> Hi Aron and *AD, > >>>> > >>>> [*AD - please respond regarding question #8 and review/approve the > >>>> author’s suggested text to resolve question #12]. > >>>> > >>>> Thanks for the reply and guidance. We have updated as requested. > >>>> > >>>> Note that we made the further change of removing “of RFC 9980” from the > >>>> Reference column of the IANA Considerations table (now list). This > >>>> matches the method of referencing most commonly seen in recently > >>>> published RFCs; please let us know any objections. Note that these > >>>> changes are best viewed in the “alt diff” files below. > >>>> > >>>> Please review the files carefully as we do not make changes once the > >>>> document is published as an RFC. > >>>> > >>>> The files have been posted here (please refresh): > >>>> https://www.rfc-editor.org/authors/rfc9980.txt > >>>> https://www.rfc-editor.org/authors/rfc9980.pdf > >>>> https://www.rfc-editor.org/authors/rfc9980.html > >>>> https://www.rfc-editor.org/authors/rfc9980.xml > >>>> > >>>> The diff files have been posted here (please refresh): > >>>> https://www.rfc-editor.org/authors/rfc9980-diff.html (comprehensive) > >>>> https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9980-auth48diff.html (Final Review > >>>> changes only) > >>>> https://www.rfc-editor.org/authors/rfc9980-auth48rfcdiff.html (side by > >>>> side) > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9980-alt-diff.html (to see IANA > >>>> table/list changes) > >>>> https://www.rfc-editor.org/authors/rfc9980-alt-rfcdiff.html (side by > >>>> side) > >>>> > >>>> The Final Review status page for this document is viewable here: > >>>> https://www.rfc-editor.org/auth48/rfc9980 > >>>> > >>>> Thank you. > >>>> > >>>> Megan Ferguson > >>>> RFC Production Center > >>>> > >>>> On May 27, 2026, at 5:11 AM, Aron Wussler <[email protected]> wrote: > >>>> > >>>> Hi Megan, > >>>> > >>>> thanks for the thorough editing. We provide our answers and our > >>>> suggested changes in the following. > >>>> > >>>> 1) We suggest the following key words: pgp, pqc, encryption, digital > >>>> signature, post-quantum > >>>> > >>>> 2) We agreed to the following change: > >>>> > >>>> Section 1 > >>>> > >>>> OLD: > >>>> Namely, these are ML-KEM [FIPS-203] as a Key Encapsulation Mechanism > >>>> (KEM), a KEM being a modern building block for public key encryption, > >>>> and ML-DSA [FIPS-204] as well as SLH-DSA [FIPS-205] as signature > >>>> schemes. > >>>> > >>>> NEW: > >>>> ML-KEM [FIPS-203] was selected as a Key Encapsulation Mechanism (KEM). > >>>> A KEM is a modern building block for public key encryption. > >>>> ML-DSA [FIPS-204] and SLH-DSA [FIPS-205] were selected as signature > >>>> schemes. > >>>> > >>>> 3) We would like to leave these sentences in their current places. They > >>>> clarify technical details of the algorithm choices, and thus do not > >>>> belong into the terminology section. > >>>> > >>>> 4) We agreed to the following change: > >>>> > >>>> Section 4.3.1 > >>>> > >>>> OLD: > >>>> Note that like in the case of the algorithms X25519 and X448 > >>>> specified in [RFC9580], for the ML-KEM composite schemes, in the case > >>>> of a v3 PKESK packet, the symmetric algorithm identifier is not > >>>> encrypted. > >>>> > >>>> NEW: > >>>> Note that for the ML-KEM composite schemes, in the case of a v3 PKESK > >>>> packet, the symmetric algorithm identifier is not encrypted. > >>>> This follows the construction of X25519 and X448 specified in [RFC9580]. > >>>> > >>>> 5a) We agree to the proposed change to use a definitions list. > >>>> > >>>> 5b) Indeed, the entries for ID 30 and ID 31 should be references to > >>>> Section 5. The reference for ID 35 and 36 should be to Section 4. > >>>> > >>>> 6) We agree to the proposed change. > >>>> > >>>> 7) We agree to the proposed change. > >>>> > >>>> 8) We defer to the AD for this item. > >>>> > >>>> 9) We do not mind wrapping here. Feel free to change the tag or manually > >>>> add a newline to resolve this. > >>>> > >>>> 10a) The abbreviation extensions seem fine to us. > >>>> > >>>> 10b) That is correct, you may update the document to use "Module > >>>> Learning with Errors" as expansion for "MLWE". > >>>> > >>>> 10c) No objections. > >>>> > >>>> 10d) We prefer to remove "(PK)" and "(SK)" from Table 8 in Section 6.1. > >>>> > >>>> 11a) We prefer to use "sentence case" for the term, that is, capitalize > >>>> the first word only in titles and beginning of sentences. As far as we > >>>> can see, the only inconsistent spelling is in Section 2.1 in the > >>>> parenthesis "(Algorithm IDs 31 and 36)". We prefer this to be adjusted > >>>> to sentence case. > >>>> > >>>> Section 2.1 > >>>> > >>>> OLD: > >>>> (Algorithm IDs 31 and 36) > >>>> > >>>> NEW: > >>>> (algorithm IDs 31 and 36) > >>>> > >>>> 11b) The list looks fine to us. > >>>> > >>>> 12) We did not find any issues regarding inclusive language. The word > >>>> 'traditional' is used in line with the definition of 'traditional > >>>> cryptographic algorithms' in RFC 9794. For clarity, we suggest to add > >>>> this term in Section 1.1.1. We propose the following change. We also > >>>> believe there should be a comma before the "and", please feel free to > >>>> remove it if that is wrong. > >>>> > >>>> Section 1.1.1 > >>>> > >>>> OLD: > >>>> Specifically, the terms "multi-algorithm", "composite" and > >>>> "non-composite" are used in correspondence with the definitions therein. > >>>> > >>>> NEW: > >>>> Specifically, the terms "multi-algorithm", "composite", "non-composite", > >>>> and "traditional" are used in correspondence with the definitions > >>>> therein. > >>>> > >>>> > >>>> Kind regards, > >>>> Aron, on behalf of all authors > >>>> > >>>> > >>>> -- > >>>> Aron Wussler > >>>> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > >>>> > >>>> > >>>> On Wednesday, 20 May 2026 at 15:43, Megan Ferguson > >>>> <[email protected]> wrote: > >>>> > >>>> Hi Aron, > >>>> > >>>> Thanks for the heads up! We appreciate your collaboration so our mail > >>>> exchange is easier to follow. > >>>> > >>>> We’ll look for your reply once you get things ironed out. > >>>> > >>>> Megan Ferguson > >>>> RFC Production Center > >>>> > >>>> On May 20, 2026, at 2:20 AM, Aron Wussler <[email protected]> wrote: > >>>> > >>>> Hi Megan, > >>>> > >>>> We're already drafting internally an answer which we all agree to - > >>>> sorry if this is taking longer than expected. > >>>> > >>>> Cheers, > >>>> Aron > >>>> > >>>> -- > >>>> Aron Wussler > >>>> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930 > >>>> > >>>> > >>>> On Tuesday, 19 May 2026 at 19:36, Megan Ferguson > >>>> <[email protected]> wrote: > >>>> > >>>> Authors and *AD, > >>>> > >>>> [*AD - please see question 8 in our mail below] > >>>> > >>>> Just a reminder that this document awaits your attention. > >>>> > >>>> Please review both emails sent thus far (AUT48 instructions as well as > >>>> document-specific questions) and let us know how to proceed on any > >>>> issues as well as any changes you might like to request upon completion > >>>> of your review of the document. > >>>> > >>>> Thank you. > >>>> > >>>> Megan Ferguson > >>>> RFC Production Center > >>>> > >>>> On May 8, 2026, at 2:50 PM, [email protected] wrote: > >>>> > >>>> All, > >>>> > >>>> *AD - please review question #8 below. Please note also that we assume > >>>> AD approval of the change between versions -16 and -17 as it was > >>>> submitted by Paul. > >>>> > >>>> Authors - While reviewing this document during AUTH48, please resolve > >>>> (as necessary) the following questions, which are also in the source > >>>> file. > >>>> > >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>>> the title) for use on https://www.rfc-editor.org/search. --> > >>>> > >>>> > >>>> 2) <!--[rfced] This sentence is difficult to parse please rephrase (and > >>>> perhaps consider breaking up into multiple sentences). > >>>> > >>>> Original: > >>>> Namely, these are ML-KEM [FIPS-203] as a Key Encapsulation Mechanism > >>>> (KEM), a KEM being a modern building block for public key encryption, > >>>> and ML-DSA [FIPS-204] as well as SLH-DSA [FIPS-205] as signature > >>>> schemes. > >>>> > >>>> --> > >>>> > >>>> > >>>> 3) <!--[rfced] Would it make sense to include the following sentences > >>>> from the subsections of 5.1 and Section 6 in the Terminology > >>>> section? > >>>> > >>>> Original: > >>>> Throughout this specification EdDSA refers to the PureEdDSA variant > >>>> defined in [RFC8032]. > >>>> > >>>> Original: > >>>> Throughout this specification ML-DSA refers to the default pure and > >>>> hedged version of ML-DSA defined in [FIPS-204]. > >>>> > >>>> Original: > >>>> Throughout this specification SLH-DSA refers to the default pure and > >>>> hedged version of SLH-DSA defined in [FIPS-205]. > >>>> > >>>> --> > >>>> > >>>> > >>>> 4) <!--[rfced] How may we rephrase to avoid the stacked "in the case"? > >>>> Perhaps breaking this sentence up would be helpful? > >>>> > >>>> Original: > >>>> Note that like in the case of the algorithms X25519 and X448 > >>>> specified in [RFC9580], for the ML-KEM composite schemes, in the case > >>>> of a v3 PKESK packet, the symmetric algorithm identifier is not > >>>> encrypted. > >>>> --> > >>>> > >>>> > >>>> 5) <!--[rfced] We had the following questions related to the table in the > >>>> IANA Considerations section: > >>>> > >>>> a) The table of IANA values is very difficult to read and, now that > >>>> some edits have been made to the text, exceed our 72-character line > >>>> length limit. > >>>> > >>>> We suggest updating to a definitions list for readability. This > >>>> update would appear as seen here: > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9980alt.txt > >>>> > >>>> b) We see links to specific tables in the various "Format" columns. > >>>> Please review as ID 30 (for example) mentions Tables 6 and 7 (which > >>>> are in Sections 5.1.1 and 5.1.2, respectively), while the Reference > >>>> column is pointing to Section 5.2. If this is not as expected, please > >>>> review each entry and let us know if/how to update. > >>>> > >>>> c) Please note that we will communicate any updates we've made to the > >>>> text in the IANA table to IANA for corresponding updates at > >>>> https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-public-key-algorithms > >>>> once AUTH48 completes (and the text is stable). > >>>> > >>>> > >>>> --> > >>>> > >>>> > >>>> 6) <!-- [rfced] [NIST-PQC] Please review. The date provided for this > >>>> reference does not match any of the dates provided at this > >>>> reference's URL. At the bottom of the page the dates listed are > >>>> "Created January 03, 2017, Updated December 11, 2025". > >>>> > >>>> Also, the authors used in this reference entry are not listed on this > >>>> page (with the exception of Dustin Moody who is listed in the > >>>> "Contacts" section). > >>>> > >>>> Is there another page this reference was meant to point to? > >>>> > >>>> If this is the correct URL we recommend the following update: > >>>> > >>>> > >>>> Current: > >>>> [NIST-PQC] Chen, L., Moody, D., and Y. Liu, "Post-Quantum Cryptography > >>>> Standardization", December 2016, > >>>> <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>. > >>>> > >>>> Perhaps: > >>>> [NIST-PQC] NIST, "Post-Quantum Cryptography Standardization", December > >>>> 2025, > >>>> <https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization>. > >>>> > >>>> --> > >>>> > >>>> > >>>> 7) <!-- [rfced] [NISTIR-8413] FYI: We've updated the date for this > >>>> reference from September 2022 to July 2022. Note that the version from > >>>> September was withdrawn and replaced by an updated version in July > >>>> 2022: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf. We > >>>> also updated the series number from "NIST IR 8413" to "NIST IR > >>>> 8413-upd1". --> > >>>> > >>>> > >>>> 8) <!--[rfced] [AD] The authors submitted a query about possible > >>>> downrefs suggested by IDNITs (see list below). This is not generally > >>>> something the RPC advises on. Upon conference between AD and authors, > >>>> please let us know if any updates/changes are necessary. > >>>> > >>>> Checking references for intended status: Proposed Standard > >>>> > >>>> (See RFCs 3967 and 4897 for information about using normative references > >>>> to lower-maturity documents in RFCs) > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-203' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-204' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-205' > >>>> > >>>> - Possible downref: Non-RFC (?) normative reference: ref. 'IANA-OPENPGP' > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 3394 > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 7748 > >>>> > >>>> ** Downref: Normative reference to an Informational RFC: RFC 8032 > >>>> > >>>> From the authors: "We listed those references as normative as they > >>>> contain the algorithmic specifications needed. > >>>> > >>>> We would appreciate guidance from the RFC Editor Team if this should > >>>> be handled differently." > >>>> > >>>> --> > >>>> > >>>> > >>>> 9) <!--[rfced] Please have a look at the line wrap issue in Appendix > >>>> A.4.3. Now that the text is in <tt> to format it as fixed width, it > >>>> seems not to be able to wrap to fit within the 72-character limit.--> > >>>> > >>>> > >>>> 10) <!--[rfced] We had the following questions/comments related to > >>>> abbreviation use throughout the document: > >>>> > >>>> a) We have expanded abbreviations on first use. Please review these > >>>> expansions for accuracy. > >>>> > >>>> b) The document expands MLWE as "Learning with Errors problem in > >>>> module lattices (MLWE)". We believe the abbreviation stands for > >>>> "Module Learning with Errors". Please let us know if/how to update. > >>>> > >>>> c) We have updated the expansion of SEIPD to match RFC 9580. Please > >>>> let us know any objections. > >>>> > >>>> Original: > >>>> Symmetrically Encrypted and Integrity Protected Data > >>>> > >>>> Current: > >>>> Symmetrically Encrypted Integrity Protected Data > >>>> > >>>> d) We see PK and SK are introduced in Section 6.1, but are not used > >>>> elsewhere in the text. Would you like to introduce them sooner and > >>>> use them throughout? Or perhaps remove them from Section 6.1? > >>>> --> > >>>> > >>>> > >>>> 11) <!--[rfced] We had the following questions/comments about > >>>> terminology use throughout the document: > >>>> > >>>> a) We see both algorithm ID and Algorithm ID. Please let us know if/how > >>>> these should be made uniform. > >>>> > >>>> b) Please review the list of terms that appear in <tt> (for special > >>>> marking) for consistency and let us know if any updates are necessary. > >>>> You can find the list at: > >>>> > >>>> https://www.rfc-editor.org/authors/draft-ietf-openpgp-pqc-17ttsorted.txt > >>>> > >>>> --> > >>>> > >>>> > >>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>> online > >>>> Style Guide > >>>> <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. > >>>> > >>>> In addition, please consider whether "traditional" should be updated for > >>>> clarity. > >>>> While the NIST website > >>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > >>>> indicates that this term is potentially biased, it is also ambiguous. > >>>> "Tradition" is a subjective term, as it is not the same for everyone. > >>>> > >>>> --> > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> Megan Ferguson > >>>> RFC Production Center > >>>> > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2026/05/08 > >>>> > >>>> 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://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 reviewPlease 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://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://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 changesTo submit changes, please reply to this email using > >>>> ‘REPLY ALL’ as all > >>>> the parties CCed on this message need to see your changes. The parties > >>>> include: > >>>> > >>>> * your coauthors > >>>> > >>>> * [email protected] (the RPC team) > >>>> > >>>> * other document participants, depending on the stream (e.g., > >>>> IETF Stream participants are your working group chairs, the > >>>> responsible ADs, and the document shepherd). > >>>> > >>>> * [email protected], which is a new archival mailing list > >>>> to preserve AUTH48 conversations; it is not an active discussion > >>>> list: > >>>> > >>>> * More info: > >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>> > >>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>> If needed, please add a note at the top of the message that you > >>>> have dropped the address. When the discussion is concluded, > >>>> [email protected] will be re-added to the CC list and > >>>> its addition will be noted at the top of the message. > >>>> > >>>> You may submit your changes in one of two ways: > >>>> > >>>> An update to the provided XML file > >>>> — OR — > >>>> An explicit list of changes in this format > >>>> > >>>> Section # (or indicate Global) > >>>> > >>>> OLD: > >>>> old text > >>>> > >>>> NEW: > >>>> new text > >>>> > >>>> You do not need to reply with both an updated XML file and an explicit > >>>> list of changes, as either form is sufficient. > >>>> > >>>> We will ask a stream manager to review and approve any changes that seem > >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, > >>>> and technical changes. Information about stream managers can be found in > >>>> the FAQ. Editorial changes do not require approval from a stream manager. > >>>> > >>>> > >>>> Approving for publicationTo 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. > >>>> > >>>> > >>>> FilesThe files are available here: > >>>> https://www.rfc-editor.org/authors/rfc9980.xml > >>>> https://www.rfc-editor.org/authors/rfc9980.html > >>>> https://www.rfc-editor.org/authors/rfc9980.pdf > >>>> https://www.rfc-editor.org/authors/rfc9980.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9980-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9980-rfcdiff.html (side by side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9980-xmldiff1.html > >>>> > >>>> > >>>> Tracking progressThe details of the AUTH48 status of your document are > >>>> here: > >>>> https://www.rfc-editor.org/auth48/rfc9980 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC EditorRFC9980 (draft-ietf-openpgp-pqc-17) > >>>> > >>>> Title : Post-Quantum Cryptography in OpenPGP > >>>> Author(s) : S. Kousidis, J. Roth, F. Strenzke, A. Wussler > >>>> WG Chair(s) : Stephen Farrell, Daniel Kahn Gillmor > >>>> > >>>> Area Director(s) : Deb Cooley, Christopher Inacio > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
