How do I approve the RFC as the author? On Wed, Oct 1, 2025 at 3:20 PM Sarah Tarrant <[email protected]> wrote: > > Hi Orie, > > Thank you for the approval! It's been noted at: > https://www.rfc-editor.org/auth48/rfc9873 > > Sincerely, > Sarah Tarrant > RFC Production Center > > > On Oct 1, 2025, at 8:16 AM, Orie <[email protected]> wrote: > > > > I approve these changes. > > > > OS > > > > On Wed, Oct 1, 2025 at 8:08 AM Sarah Tarrant > > <[email protected]> wrote: > > Hi Scott and *Orie, > > > > *AD Orie - Could you please verify that the following update to BCP14 > > language is approved? > > > > "employ" updated to "MUST employ" (parallel structure with "MUST NOT > > depend") in: > > > > Original: > > The XML namespace prefix "addlEmail" is used for the namespace > > "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > > NOT depend on it and instead employ a proper namespace-aware XML > > parser and serializer to interpret and output the XML documents. > > > > Current: > > The XML namespace prefix "addlEmail" is used for the namespace > > "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > > NOT depend on it and instead MUST employ a proper namespace-aware > > XML parser and serializer to interpret and output the XML documents. > > > > Also viewable at: https://www.rfc-editor.org/authors/rfc9873-auth48diff.html > > ---- > > > > Scott - Thank you for your reply. We have updated accordingly and have no > > further questions. > > > > Please review the document carefully to ensure satisfaction as we do not > > make changes once it has been published as an RFC. Contact us with any > > further updates or with your approval of the document in its current form. > > We will await approvals from each author prior to moving forward in the > > publication process. > > > > The updated files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9873.txt > > https://www.rfc-editor.org/authors/rfc9873.pdf > > https://www.rfc-editor.org/authors/rfc9873.html > > https://www.rfc-editor.org/authors/rfc9873.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9873-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9873-auth48diff.html (AUTH48 changes > > only) > > > > Note that it may be necessary for you to refresh your browser to view the > > most recent version. > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9873 > > > > Thank you, > > Sarah Tarrant > > RFC Production Center > > > > > > > On Sep 25, 2025, at 7:19 AM, Hollenbeck, Scott > > > <[email protected]> wrote: > > > > > >> -----Original Message----- > > >> From: [email protected] <[email protected]> > > >> Sent: Wednesday, September 24, 2025 8:18 PM > > >> To: [email protected]; Gould, James <[email protected]>; Hollenbeck, > > >> Scott <[email protected]> > > >> Cc: [email protected]; [email protected]; > > >> [email protected]; > > >> [email protected]; [email protected]; [email protected] > > >> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9873 > > >> <draft-ietf-regext-epp-eai-27> > > >> for your review > > >> > > >> Caution: This email originated from outside the organization. Do not > > >> click links > > >> or open attachments unless you recognize the sender and know the content > > >> is > > >> safe. > > >> > > >> 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://secure- > > >> web.cisco.com/1ZsR3tGYN7sGtmWyn9l95Z7TcV61KEXYrZeD_Mpd713QOiokMKt > > >> mX-DTM9CMYXKJTnWO2JMly51l2wU5UiVy29IY8elM6XJQB6r- > > >> qOcS0EFbqisRIwH1gJ62BjM6ddzDPy5eRGJb2fxYehs3pt1-UZMvSKWzD- > > >> JdACt2khJb5zW3oXNOfGhGvuNQBtKIfwCZ9FIEuSfmtsusZcvlPeujOupeOro2fm4D > > >> w3M6Hgc7a5rPuPj4qd1Xe2_vvdNXktC8z4pyF2vdg8_gD8OF5z___rWwS90cbYIyf > > >> sbuGZZsvGro/https%3A%2F%2Fwww.rfc-editor.org%2Fsearch --> > > >> > > >> > > >> 2) <!-- [rfced] Should "employ" be updated to "MUST employ" (parallel > > >> structure with "MUST NOT depend")? Or is the current correct? > > >> > > >> Original: > > >> The XML namespace prefix "addlEmail" is used for the namespace > > >> "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > > >> NOT depend on it and instead employ a proper namespace-aware XML > > >> parser and serializer to interpret and output the XML documents. > > >> > > >> Perhaps: > > >> The XML namespace prefix "addlEmail" is used for the namespace > > >> "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > > >> NOT depend on it and instead MUST employ a proper namespace-aware > > >> XML parser and serializer to interpret and output the XML documents. > > >> --> > > > > > > [SAH] The proposed update is correct. > > > > > >> 3) <!-- [rfced] This sentence is a bit hard to follow because of the many > > >> commas. We added parentheses rather than commas around the "defined in" > > >> phrases and added "to support" before "U-label" in this sentence. Please > > >> let us > > >> know any concerns. > > >> > > >> Original: > > >> [RFC6531] extends the > > >> Mailbox, Local-part and Domain ABNF rules in [RFC5321] to support > > >> "UTF8-non-ascii", defined in Section 3.1 of [RFC6532], for the local- > > >> part and U-label, defined in Section 2.3.2.1 of [RFC5890], for the > > >> domain. > > >> > > >> Current: > > >> [RFC6531] extends the > > >> Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support > > >> "UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local- > > >> part and to support U-label (defined in Section 2.3.2.1 of [RFC5890]) > > >> for the > > >> domain. > > >> --> > > > > > > [SAH] The proposed update is fine. > > > > > >> 4) <!-- [rfced] Should "that support" here be updated to just "support"? > > >> Is is > > >> another meaning intended? > > >> > > >> Original: > > >> * Any address included in an extension is intended to be an > > >> additional address that's associated only with the primary > > >> <contact:email> address, and that support for any other additional > > >> email addresses MUST explicitly describe how the additional > > >> addresses are associated with the existing addresses. > > >> > > >> Perhaps: > > >> * Any address included in an extension is intended to be an > > >> additional address that is associated only with the primary > > >> <contact:email> address, and support for any other additional > > >> email addresses MUST explicitly describe how the additional > > >> addresses are associated with the existing addresses. > > >> --> > > > > > > [SAH] The proposed update is fine. > > > > > >> 5) <!-- [rfced] In the first bulleted list in Section 4.2.1, the list > > >> items all begin > > >> with a verb except for the following one. How may we update this one to > > >> create > > >> parallel structure? > > >> > > >> Original: > > >> * Storage of email properties that support internationalized > > >> characters. > > >> > > >> Perhaps: > > >> * Store email properties that support internationalized > > >> characters. > > >> > > >> Or: > > >> * Maintain storage of email properties that support internationalized > > >> characters. > > >> --> > > > > > > [SAH] I prefer "Store email properties". Please make that change. > > > > > >> 6) <!-- [rfced] This document includes 8 figures. For each of them, the > > >> text > > >> introducing the figure and the figure title are almost identical. We > > >> suggest > > >> removing the intro text and keeping the figure title to avoid > > >> redundancy. Let us > > >> know your thoughts. > > >> > > >> Example: > > >> > > >> The following is an example <info> contact response using the > > >> <addlEmail:addlEmail> extension with no alternate email address: > > >> ... > > >> Figure 1: Example <info> Contact Response Using the > > >> <addlEmail:addlEmail> Extension with No Alternate Email Address > > >> --> > > > > > > [SAH] The proposed update is fine. > > > > > >> 7) <!-- [rfced] Should the title of Section 5.1.3 be updated from "Query > > >> Command" > > >> to just "Command" for consistency with the other titles in this section? > > >> > > >> Original: > > >> 5.1. EPP Query Commands > > >> 5.1.1. EPP <check> Command > > >> 5.1.2. EPP <info> Command > > >> 5.1.3. EPP <transfer> Query Command > > >> > > >> Perhaps: > > >> 5.1. EPP Query Commands > > >> 5.1.1. EPP <check> Command > > >> 5.1.2. EPP <info> Command > > >> 5.1.3. EPP <transfer> Command > > >> --> > > > > > > [SAH] Please keep the text as-is. The current text is consistent with the > > > core EPP RFCs and helps distinguish query commands from transform > > > commands. > > > > > >> 8) <!-- [rfced] How may we update "an object mapping like [RFC5733]" > > >> in these sentences? Is the intended meaning "an object mapping like the > > >> one > > >> described in [RFC5733]" or something else? > > >> > > >> Original: > > >> This extension defines additional elements to extend the EPP <create> > > >> command of an object mapping like [RFC5733]. > > > > > > [SAH] Please use this: "This extension defines additional elements to > > > extend the EPP <create> command described in [RFC5733]." > > > > > >> ... > > >> In addition to the EPP > > >> command elements described in an object mapping like [RFC5733], the > > >> command MUST contain a child <addlEmail:addlEmail> element > > >> (Section 3) for the client to set an alternate email address. > > > > > > [SAH] Please use this: "In addition to the EPP command elements described > > > in [RFC5733]..." > > > > > >> This extension defines additional elements to extend the EPP <update> > > >> command of an object mapping like [RFC5733]. > > > > > > [SAH] Please use this: "This extension defines additional elements to > > > extend the EPP <update> command described in [RFC5733]." > > > > > >> In addition to the EPP > > >> command elements described in an object mapping like [RFC5733], the > > >> command MUST contain a child <addlEmail:addlEmail> element > > >> (Section 3) for the client to set or unset an alternate email > > >> address. > > >> > > > [SAH] Please use this: "In addition to the EPP command elements described > > > in [RFC5733]..." > > > > > >> Perhaps: > > >> This extension defines additional elements to extend the EPP <create> > > >> command of an object mapping like the one described in [RFC5733]. > > >> ... > > >> In addition to the EPP > > >> command elements described in an object mapping > > >> (like the one in [RFC5733]), the > > >> command MUST contain a child <addlEmail:addlEmail> element > > >> (Section 3) for the client to set an alternate email address. > > >> ... > > >> This extension defines additional elements to extend the EPP <update> > > >> command of an object mapping like the one described in [RFC5733]. > > >> ... > > >> In addition to the EPP > > >> command elements described in an object mapping > > >> (like the one in [RFC5733]), the > > >> command MUST contain a child <addlEmail:addlEmail> element > > >> (Section 3) for the client to set or unset an alternate email > > >> address. > > >> --> > > > > > > [SAH] See above. > > > > > >> 9) <!-- [rfced] Should this sentence be updated to include "XML > > >> schemas"? We > > >> ask because we see this in other RFCs (e.g., RFCs 9167, 9095, 9022). > > >> > > >> Original: > > >> This document uses URNs to describe XML namespaces conforming to a > > >> registry mechanism described in RFC 3688 [RFC3688]. > > >> > > >> Perhaps: > > >> This document uses URNs to describe XML namespaces and XML schemas > > >> conforming to a > > >> registry mechanism described in [RFC3688]. > > >> --> > > > > > > Yes, please make that change. > > > > > >> 10) <!-- [rfced] Would including a citation for "IDNA2008" be helpful for > > >> readers? Perhaps to [RFC5895]? Also, how may we clarify what the > > >> domain-part > > >> should conform to? > > >> > > >> Original: > > >> The domain-part of these SMTPUTF8 email addresses SHOULD > > >> conform to IDNA2008. > > >> > > >> Perhaps: > > >> The domain-part of these SMTPUTF8 email addresses SHOULD > > >> conform to the guidelines in IDNA2008 [RFC5895]. > > >> --> > > > > > > Please cite RFC 5891. It describes the protocol for label syntax. > > > > > >> 11) <!-- [rfced] May we revise "of the code points allowed by IDNA Rules > > >> and > > >> Derived Property Values" in one of the following ways? > > >> > > >> Original: > > >> To reduce the risk of the use of invalid domain names in email > > >> addresses, registries SHOULD validate the domain name syntax in > > >> provided email addresses and validate whether the domain name > > >> consists of the code points allowed by IDNA Rules and Derived > > >> Property Values (https://secure-web.cisco.com/1QFzD_XnkNpfB- > > >> WjBVrf6PbAKJWlemKY6666-LVqc7AP5Hw8Yx4- > > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > > >> > > >> Perhaps: > > >> To reduce the risk of the use of invalid domain names in email > > >> addresses, registries SHOULD validate the domain name syntax in > > >> provided email addresses and validate whether the domain name > > >> consists of the code points listed in the "IDNA Rules and Derived > > >> Property Values" registry (https://secure-web.cisco.com/1QFzD_XnkNpfB- > > >> WjBVrf6PbAKJWlemKY6666-LVqc7AP5Hw8Yx4- > > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > > >> > > >> Or: > > >> To reduce the risk of the use of invalid domain names in email > > >> addresses, registries SHOULD validate the domain name syntax in > > >> provided email addresses and validate whether the domain name > > >> consists of the allowed code points, i.e., those allocated in the > > >> "IDNA Rules and Derived Property Values" registry > > >> (https://secure-web.cisco.com/1QFzD_XnkNpfB-WjBVrf6PbAKJWlemKY6666- > > >> LVqc7AP5Hw8Yx4- > > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > > >> --> > > > > > > [SAH] I like the first option. Please use it. > > > > > >> 12) <!-- [rfced] Would you like the references to be alphabetized or > > >> left in their > > >> current order? > > >> --> > > > > > > [SAH] Alphabetized, please. > > > > > >> 13) <!-- [rfced] We note inconsistencies in the terms below throughout > > >> the text. > > >> Should these be uniform? If so, please let us know which form is > > >> preferred. > > >> > > >> command-response extension > > >> command and response extension > > > > > > [SAH] Please use "command-response extension". > > > > > >> local-part > > >> localpart > > > > > > [SAH] Please use "local-part". > > > > > >> ASCII alternate email address > > >> alternate ASCII email address > > > > > > [SAH] Please use "alternate ASCII email address". > > > > > >> all-ASCII > > >> ASCII-only > > >> --> > > > > > > [SAH] Please use "ASCII-only". > > > > > >> 14) <!-- [rfced] FYI - We have added expansions for the following > > >> abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). > > >> Please review each expansion in the document carefully to ensure > > >> correctness. > > >> > > >> Registration Data Access Protocol (RDAP) > > >> --> > > > > > > [SAH] That's fine. > > > > > >> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >> online > > >> Style Guide <https://secure- > > >> web.cisco.com/1EpIBqSv2djqdFD93a4O8wDFONc_xXs77r5iDr0IxJH8rDbwRjGoJ > > >> Cttj7vhViX3oclmCBN1EBVn4Cx5U39cniNr2HwK4Jtx3vPzraPFY91-kDXjPan4fiBO- > > >> wbUcxyruUWBvQ_g6vEc6XjiZtCnubr9ameNHduVMbuqjbj24CK38hS5D9qWtPpZ > > >> _POtDEVL7q3flhYzM6HphC30lVgRmEb1e_u3KTGplalMRcXxLtU60y8- > > >> 499SM5GeTzO_a9uMCavuMOD4EjxPB2zLIx21bzV9ypOMqI9ocH- > > >> KuQGo_E18/https%3A%2F%2Fwww.rfc- > > >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_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. > > >> > > >> For example, please consider whether "natively" should be updated: > > >> > > >> Original: > > >> The Extensible Provisioning Protocol (EPP) does not natively support > > >> internationalized email addresses because the specifications for > > >> these addresses did not exist when the EPP was developed. > > >> --> > > > > > > [SAH] Please change "natively" to "inherently". > > > > > >> Thank you. > > >> > > >> Sarah Tarrant and Rebecca VanRheenen > > >> RFC Production Center > > >> > > >> > > >> > > >> On Sep 24, 2025, at 5:13 PM, [email protected] wrote: > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2025/09/24 > > >> > > >> 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://secure- > > >> web.cisco.com/1SMDEezwBs_KZJJS2lPui3tlV6zSuw5ZvQ1TnfVZbL1Qf_u63P0Ga3 > > >> VZTkSEix5kzgiysmVi- > > >> IiLgRQXPaoG9L6Vhr3DKws29IBfIBcG3sz3PgP8KNnKlQrz7qRpbveCanQ6- > > >> 8LvlVsGgra58UI8f3rMJT7FLgH8_ud3H7_xaW- > > >> ucDI1QFSFApgC2SnmVB4ZmqOw7_E8XqVLYePO6VNkDDincRKqArlvlo5TQsl7uek > > >> Qf5rsE5eUC0NpRoZO4a- > > >> EivKv0B0SbDCSVoRzfzLVlUP9MblIKIkAbAs3r5dGi6fE/https%3A%2F%2Fwww.rfc- > > >> editor.org%2Ffaq%2F). > > >> > > >> 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://secure- > > >> web.cisco.com/1Bl31SM1PL4FeEsFoc62h3C3DZpYU_IynOdIK- > > >> SfwKLER5l3jPbClR9XUIRg_lC6t4yDqwn8Bp9AAl7LPeSgTstqXAQkg- > > >> P5SkVRwr9QwMWzSfNfRsBG-fWEmr_X-bmB7RqxbE7aH_rHEMVCxmwFNo- > > >> 4As95V9ueztFUlgBundjmgegmctF3- > > >> ilF07DsHDwM7rEJdJ4bw7WI6dJ2gvurt4oNgeZ7CZAbZbIgDRFYTQygl2YfQa4zzMH > > >> sKIv90QwAgL5VpVhD2YjbXksucJ5EyVzS27esGVQ8jqKhwNb8O94pSQI5EE_6GIb_A > > >> rpfDt49h/https%3A%2F%2Ftrustee.ietf.org%2Flicense-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://secure- > > >> web.cisco.com/12sdMCyHc7pYxvWwY3NeiV7uSCsLjOnFg7gn_PjezxAM92Fuy7J1 > > >> _F1-vcETGHeLM2IJt-VYY6oueRl_eXCFG7W1bNgz- > > >> QH32qh7M0NOOf07XlQZnfba5u3HkZOi7WeechNWZGVbwd5qzUkmH9SlfLEki8f > > >> xa5j9AYzZ1r3VgOZXTQMzU2zYWnosLdia3j7e1dwDX6S0tStUO8cdG6aI0jAAYX1y6 > > >> kTQY-Q0685DWZerGmpNAblDgCTsGP- > > >> SIbPgOdUmGOFIrLB2h0pZwXmiChyq7BfVoJJK- > > >> _cqcOvg41doCzNd0ZFekRt0dmpFpFuJ5/https%3A%2F%2Fauthors.ietf.org%2Frfcx > > >> ml-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://secure- > > >> web.cisco.com/1gGvT3G5FYK57VrPulrNDqWgIFnNxCUISnWKiGSbYV93FiR- > > >> aUI3DTXRzujqd6sXms-JhMeQGeiL4h83UuqtTtovSVALbLVxzL- > > >> sSNlEgmCcPPeUFK2R9kaeoXGVHXI0oTfbXXGrAluayAmaDzYqyu- > > >> bY8ZfDoW5TQwT-- > > >> Gi421h1Mav8peZSjuJEsrNN8PoySQyzJTFqlOcboUy80ggm5_l0iYiU6bmoEFN5pDf > > >> Q9-REZm- > > >> HyKmuu5s_iG1oB9HOp0JGG3Znw8VxYscoJPneEsmKbfMH9rLnrq0iw3W75g- > > >> P7Uq6iRyUwhl_Q8gzbThC/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg > > >> %2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc > > >> > > >> * The archive itself: > > >> https://secure- > > >> web.cisco.com/1dMdiH4Ww9O4fozg6fIQm7NNVrz2FVKAwv3nf_hiHjA5SvUY1V > > >> QexD6yblQ4hETrHjUXBEzo2N- > > >> SdALsf7NF7ynbZOEQfzHiqSsS50ImtUQ2K_qZR8MxSC8YXrUCSiyr8RES61c- > > >> p4G9m1mmSMa8qifaZcZxRoc0OEk9Fb6_TJun73nWBrSAaSeGRQ7mFN3qveba0t > > >> ZRJnDLbd873bv0yO2wyE_Iw39gy9WxoqDfDywniWugsZVZ8JdfRIO8KUu-akmTi- > > >> feWnnFSr32bqQXURBJ9hChgWadWD_fjmL8zfw6Pxuxx2dRV2PTlIk1NurDI/https% > > >> 3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F > > >> > > >> * 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://secure- > > >> web.cisco.com/15cD5SQVJ0QC9wMhyG4ZfCEMC6og4GtyFRUl2Y1xGFDkWfhQc > > >> gVHwvx1FdfvelF- > > >> ZsY1ROjyOpdFI5ZE8sezuKzG9UNvq5CQX5EfKc4vmPumnxsldAa_gqZEeEDjG9WrH > > >> KXm- > > >> S9R0KPjuBiCIG5EdxLI00bzn53sOrizFWlCtFQt7rWQyZqegdh8hUT6wrn50cBz10zV > > >> 4QG_3ciCH44xkhl3ZtjyVoH2IuFl- > > >> 3wC69lCjwUsmDpf8HasQntep5JfnwlQPIlHzNtPeDj60K8EHXJ5nfYYzDKnaD9k1As > > >> 6yu9Q/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873.xml > > >> https://secure- > > >> web.cisco.com/1aov7ozWUKJ1e6UvJbaH4OgFj1UEOjpa8sFyeMdG8DXzV5Uxxu7 > > >> r0ACwFZZXAooJ8EhPzi2KXC4pmmy78BOHw3I097APdKGy4_virvaP_MeQEFMkm > > >> d672cCAmBRGZ7LpdPmZVyLslYT03- > > >> Br94vcg2RpVyOBhrRLb4y1zHn8K0CnE7IkQizdDWQhr_w- > > >> cQmdTuMm6mWbExRelrBSc8hSUyYyAWswM1X6mwMWpXuD9pq7k9HyLneKM > > >> Nx87yuHq- > > >> 6Sa8CJh8iWBMojWchMBD9lON6ytaaNAXXsyrlDY4ks7jd4/https%3A%2F%2Fww > > >> w.rfc-editor.org%2Fauthors%2Frfc9873.html > > >> https://secure- > > >> web.cisco.com/16_b4T6_KXjXOwtSaJakSbTczCe0RTR2wg6Nwl0VelEjvmXEbeT- > > >> 4YxNhRErMKd3W1evOMpeHJLiFuU- > > >> Lbe1pipqiRVerLBy5XUwO2LtmF5CaSZDICxYLXESmZvmeGyY8tI5Iyx9a5tKbiPCnu7 > > >> - > > >> oRvYwP4eFpI7oSs_8pPwSrawZixeVdbzLRQ72FbpMdE7EsFsHd3neFyCIzUE2Mc5Ht > > >> m0V4p_xWaqDiJsClOjGxWyKjxKsIwzmsY9UCXFsjkmUo37NkVFMROtQIZYe4hpER > > >> Va3afDJAIqySgFhKgPoux4/https%3A%2F%2Fwww.rfc- > > >> editor.org%2Fauthors%2Frfc9873.pdf > > >> https://secure- > > >> web.cisco.com/17q74dIkjQHVpNQdfQWmyXQoPSxUIEpY4FkePbIB3268WY6KrQr > > >> Hw6FMffUTXUMTD0m2Wjmsnnnh52RbiWQXbb96nCvJ8XwHSxofqXrJ3LAgVON4 > > >> 3naAJLvLBKjjS06vSVmzUfPnIOv8Wk57QjSEnZlWB23_7VAUzYt8OrIhVhDZPpKSW8 > > >> 71OCB4kF2PAjj7C_ySXHb3dgBTfOwckVWVzNbwssHvoOJAUjTXBxmyLOGusi3ycx0 > > >> qltp2JGokZ3qRVrkUH2rsiZCJ4M__cUTDzShtFH4WbYl- > > >> Y7T729cJGlGQ/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873.txt > > >> > > >> Diff file of the text: > > >> https://secure-web.cisco.com/1vF1CXnVPqrBUQzQUqOOruKVFpG- > > >> O0sGXtCZYiT2PgPHkSVLGNLzZs7y8PXH3dOSaQpLHdb5IPh_er_2MLvoGGWyn8zX > > >> d8yKJBNUaH7D6zLNm248V- > > >> QFmDm3ilvP5wwr4SQ8o5wVdJEtvLXMingYI0WmKr575QZT9TzokKEq3n9Kyx7dtX > > >> eXBy_LmJa5j_PxZiRyixlZ9Y9yXQC1jKmY9xSfx_XvCEnpVBAA0anCCdTi6HjBAz1PY > > >> pF71lr9OiWBAClSNyXn0jKIJ69ZokmHmMcOiZXFOHvJUc7qU7wOcZK8/https%3A > > >> %2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873-diff.html > > >> https://secure- > > >> web.cisco.com/1suXYshBTkNkJVTMrtcBxfUXNlWG9KQY0lsao8oq66aUVIOhtLA5i > > >> PGvJZaYmbLnlEpeQ_-i7LgLRtGWoDchy_- > > >> ZHyHg4CNEyAs1ZNXBFmLmVm3ebwTUlRDQ3H- > > >> pT0I4ezGr2dNSV2UZxPcEOeFnXoH0UPyjR4TK5sa-fye7- > > >> qP_B328TNAmmU4uwiq0ocSq82xZqIlJ4jV_Xv5mKQv0wIDcQlFydj- > > >> FVw4HGQcHNqhxnvmPtJe7O13R1zhdbGwUOBHDTq4qLxHzJCKalDb03lJGe9w9U > > >> HG07coX7ycIgcyU/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873- > > >> rfcdiff.html (side by side) > > >> > > >> Alt-diff of the text (allows you to more easily view changes where text > > >> has been > > >> deleted or moved): > > >> https://secure- > > >> web.cisco.com/1Vy0YPAxThzplZn_o_brqIxPoxZW5_MFoK7DMQfBEb9K- > > >> CEIhaAQYGtbmS6cyqCyNfZ4Xg7VlnWQz4ya9E43ym93Kd2QC_FTqsi7IN7510Oatc > > >> gBDiNrTksxYwcbFKIQRdGn86erG04CLa9Dfqc5YDuGaIdc9GcZO5dk7xAW_MegJY > > >> kvzrQydifJVLSQt4a1qKill9tZlJ7k5O04xNo_S4ztploVGiNYYMAama5ZVjAmjmNp0 > > >> M5Dx1- > > >> L7o73JbYZZx4u24fmqXP5qqsPUjV7DfpPVHLFdzob_scqsqVzJ3JM/https%3A%2F%2 > > >> Fwww.rfc-editor.org%2Fauthors%2Frfc9873-alt-diff.html > > >> > > >> Diff of the XML: > > >> https://secure-web.cisco.com/1RnKtMmFg3ckDhh_j3PP- > > >> WWG5v3GhhUboraAr5dxNBF- > > >> m40DBOQ0pIj7WXcoBsSWLJyGlah1ZRjisxJcXuJmCXijBMn7aqzNvHjz1RPqTdFgIG > > >> nXQCpz_LIxWENC9VYJpr1eAw40kiZp5Wf9zgf5ng0JMmLNhaaFSSNjzapO7uuJbth > > >> 3HKBRh69a4nBkZzEhvERhbBhDR- > > >> L3UCBGVuFF6SA5cUoHiGomIFFjOZYUM09mEmZmaRC69pjOXGci8owkoToPOr4Y > > >> nu_KZetx-_YwSfLLC-oJFhU0ko8yuM8HmINk/https%3A%2F%2Fwww.rfc- > > >> editor.org%2Fauthors%2Frfc9873-xmldiff1.html > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> https://secure- > > >> web.cisco.com/1F3mmFN6jW2rMOmMHTNhUXaDWBFn0lFosMJGtrpiJYQtPcez > > >> OJDQKPSkM7NupCQ1RVWSOng81kXXsATb8xcqGIJz6CE99tywd6mAbKgC6ercJFrt > > >> bL6Fo549k1zRlj5fHNYlNI8dAL8Rwnwfg17SEz- > > >> oR3i_t2Rh4gkwz20YL8BViQoBj76fUBwtnnfzbxAzrV4f8ZJFkDA0wOOyZNtNfbq0dt > > >> E6FO70tqtwoqTRbgTMGonmtucP0n-ltzn-M44vVUGR3KNGwaT1dI5ek- > > >> Lbj7Bth9Az-BXgJ4QL1wF_Agjk/https%3A%2F%2Fwww.rfc- > > >> editor.org%2Fauth48%2Frfc9873 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC9873 (draft-ietf-regext-epp-eai-27) > > >> > > >> Title : Additional Email Address Extension for the Extensible > > >> Provisioning > > >> Protocol (EPP) > > >> Author(s) : D. Belyavsky, J. Gould, S. Hollenbeck > > >> WG Chair(s) : James Galvin, Antoin Verschuren, Jorge Cano > > >> Area Director(s) : Andy Newton, Orie Steele > > > > > >
-- SY, Dmitry Belyavsky -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
