ADs, 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." >>>> >>>> —> > > 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? > > > 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. > > Once we hear back some AD guidance on the above, we believe the document will > 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-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]
