Hi Dimitry, To approve, just reply that you approve :)
Thank you, Sarah Tarrant RFC Production Center > On Oct 5, 2025, at 10:14 AM, Dmitry Belyavsky <[email protected]> wrote: > > 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]
