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 review >>>>>>> --------------------- >>>>>>> >>>>>>> Please review the following aspects of your document: >>>>>>> >>>>>>> * RFC Editor questions >>>>>>> >>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>> that have been included in the XML file as comments marked as >>>>>>> follows: >>>>>>> >>>>>>> <!-- [rfced] ... --> >>>>>>> >>>>>>> These questions will also be sent in a subsequent email. >>>>>>> >>>>>>> * Changes submitted by coauthors >>>>>>> >>>>>>> Please ensure that you review any changes submitted by your >>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>> agree to changes submitted by your coauthors. >>>>>>> >>>>>>> * Content >>>>>>> >>>>>>> Please review the full content of the document, as this cannot >>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>> - IANA considerations updates (if applicable) >>>>>>> - contact information >>>>>>> - references >>>>>>> >>>>>>> * Copyright notices and legends >>>>>>> >>>>>>> Please review the copyright notice and legends as defined in >>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>> (TLP – https://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 changes >>>>>>> ------------------ >>>>>>> >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>> include: >>>>>>> >>>>>>> * your coauthors >>>>>>> >>>>>>> * [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 publication >>>>>>> -------------------------- >>>>>>> >>>>>>> To approve your RFC for publication, please reply to this email stating >>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>> >>>>>>> >>>>>>> Files >>>>>>> ----- >>>>>>> >>>>>>> The files are available here: >>>>>>> https://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 progress >>>>>>> ----------------- >>>>>>> >>>>>>> The 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 Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9980 (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]
