Hi Peter and Steve, The files have been updated per the nits pointed out by Peter.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc10026.xml https://www.rfc-editor.org/authors/rfc10026.txt https://www.rfc-editor.org/authors/rfc10026.html https://www.rfc-editor.org/authors/rfc10026.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc10026-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc10026-auth48diff.html (Final Review changes) https://www.rfc-editor.org/authors/rfc10026-auth48rfcdiff.html (Final Review changes side by side) We have now received all necessary approvals and consider Final Review complete: https://queue.rfc-editor.org/final-review/rfc10026/ Thank you for your attention and guidance during the Final Review process. We will move this document forward in the publication process at this time. Best regards, Alanna Paloma RFC Production Center > On Jul 17, 2026, at 12:59 PM, Peter Thomassen <[email protected]> wrote: > > Hi Alanna, > > Thanks. Three nits: > > - missing word: "records of DS automation decision" --> "records of each DS > automation decision" > > - Section 4.1 & Appendix A.1 (both): Along with the previous change, I had > suggested inserting a comma: "new set of records is published and" --> "new > set of records is published, and". -- If it was omitted intentionally, fine; > I just wanted to make it explicit that the proposed text contained one (for > structuring the long sentence / readability). > > - Suggested text in 4.2.2 had a typo (sorry): "the Child DNS operators to > send" --> "the Child DNS operator to send" > > With the above fixed, this is good to ship! > > Let me note that Steve Sheng is listed at > https://queue.rfc-editor.org/final-review/rfc10026/ as not having approved, > although he did today at 11:10am UTC. > > Best, > Peter > > > On 7/17/26 20:09, Alanna Paloma wrote: >> Hi Authors and Med, >> Med - Thank you for sending you preemptive approval as the AD. We’ve noted >> it here: >> https://queue.rfc-editor.org/final-review/rfc10026/ >> Authors - Thank you for your replies. The files have been updated >> accordingly. >> We ask that you review the updated files carefully and let us know if any >> further updates are needed. Note that we do not make changes once a document >> is published as an RFC. >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc10026.xml >> https://www.rfc-editor.org/authors/rfc10026.txt >> https://www.rfc-editor.org/authors/rfc10026.html >> https://www.rfc-editor.org/authors/rfc10026.pdf >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc10026-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc10026-auth48diff.html (Final Review >> changes) >> https://www.rfc-editor.org/authors/rfc10026-auth48rfcdiff.html (Final >> Review changes side by side) >> We will await final approval of the updated files from each author prior to >> moving this document forward in the publication process. >> Thank you, >> Alanna Paloma >> RFC Production Center >>> On Jul 17, 2026, at 6:36 AM, [email protected] wrote: >>> >>> Hi Alanna/Sandy, all, >>> >>> FWIW, I approve the changes proposed in #5. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Peter Thomassen <[email protected]> >>>> Envoyé : vendredi 17 juillet 2026 12:59 >>>> À : [email protected]; Steve Sheng <[email protected]> >>>> Cc : [email protected]; [email protected]; >>>> [email protected]; BOUCADAIR Mohamed INNOV/NET >>>> <[email protected]>; [email protected]; ops- >>>> [email protected] >>>> Objet : Re: Final Review: RFC-to-be 10026 (draft-ietf-dnsop-ds- >>>> automation) in XML >>>> >>>> >>>> [Re-sending with co-author Steve Sheng's email address corrected. >>>> Not sure why the original message went to his old address; the >>>> document actually has the current one. -- Steve, can you respond >>>> whether you approve of publication after the below fixes have been >>>> made? Thanks!] >>>> >>>> >>>> Dear RFC Editor, Alanna and Sandy, >>>> >>>> Thank you for the editing. >>>> >>>> With the below addressed, I approve of this RFC for publication. >>>> >>>> I've spotted the following things that I'd like to comment on. >>>> >>>> >>>> #1 You changed >>>> >>>> ORIGINAL >>>> both the registrar and the registry can effect >>>> >>>> CURRENT >>>> both the registrar and the registry can affect >>>> >>>> The intended meaning is in fact "effect" (bring about), not >>>> "affect" (influence). Can this please be changed back? >>>> >>>> >>>> #2 At "Readers are expected to be familiar with DNSSEC", please >>>> add RFC9975 (it wasn't published at the time of writing, but is a >>>> central component of the document and referenced in various >>>> places). >>>> >>>> >>>> #3 At "records of DS automation decisions, including", you changed >>>> data elements (timestamp, decision outcome) to plural. Let's keep >>>> singular, but change to "records of each DS automation decision, >>>> including". Also, "DS RRset application" is not correct, so please >>>> change back to "applied DS RRset". >>>> >>>> >>>> #4 "change in an SOA serial" is not correct. Please change back to >>>> "change in SOA serial", or "change of SOA serial", or "SOA serial >>>> change". >>>> >>>> >>>> #5 We received additional feedback that RFC9859 is mentioned in a >>>> few places but is not properly tied into the recommendations, so >>>> the related guidance is inappropriately disconnected. This is >>>> predominantly an editorial omission as RFC9859 didn't exist at the >>>> time of writing. I've consulted with the responsible AD for how to >>>> fix this, and we agreed on the following four adjustments (which >>>> are expected to receive Med's approval): >>>> >>>> ## Section 4.1 and Appendix A.1 >>>> >>>> OLD >>>> 2. Parent-side entities (such as registries) SHOULD reduce a >>>> DS >>>> record set's TTL to a value between 5-15 minutes when a >>>> new set >>>> of records is published and restore the previous (or, if >>>> unavailable, default) TTL value at a later occasion (but >>>> not >>>> before the previous DS RRset's TTL has expired). >>>> >>>> NEW >>>> 2. Parent-side entities (such as registries) SHOULD allow for >>>> effective rollback by reducing a DS record set's TTL to a >>>> value >>>> between 5-15 minutes when a new set of records is >>>> published, and >>>> restore the previous (or, if unavailable, default) TTL >>>> value at a >>>> later occasion (but not before the previous DS RRset's TTL >>>> has >>>> expired). >>>> Besides a prudent choice of TTL, prompt DS changes also >>>> require >>>> timely discovery of update requests. For recommended >>>> methods, >>>> see Section 4.2.2. >>>> >>>> ## Section 4.2.2 (changes title, adds a first paragraph) >>>> >>>> OLD >>>> 4.2.2. TTLs and Caching >>>> >>>> NEW >>>> 4.2.2. Timing, TTLs, and Caching >>>> >>>> For timely execution of DS provisioning requests, it is >>>> important to >>>> discover them reasonably quickly. The best way to do so is >>>> for the >>>> Child DNS operators to send an RFC 9859 notification to the >>>> parent >>>> (RFC 9859 Sections 4.1 and 4.2). In addition to publication >>>> of the >>>> relevant notification targets, this requires the advertised >>>> endpoint >>>> to actually listen (RFC 9859 Sections 3 and 4.3). By >>>> explicitly >>>> naming a responsible endpoint, this method also resolves >>>> potential >>>> contention between Registry and Registrar when the RRR model >>>> is used >>>> (see Section 7.2.3). Note that periodic scanning is a >>>> suboptimal >>>> alternative as it introduces policy-dependent delays and does >>>> not >>>> scale well for large zones. >>>> >>>> ## Section 5.1 and Appendix A.2 >>>> >>>> OLD >>>> 3. Child DNS operators SHOULD be notified of errors using a >>>> report >>>> query [RFC9567] to the agent domain as described in >>>> Section 4 of >>>> [RFC9859]. Notifications to humans (domain holder) will >>>> be >>>> performed in accordance with the communication preferences >>>> established with the parent-side entity. The same >>>> condition >>>> SHOULD NOT be reported unnecessarily frequently to the >>>> same >>>> recipient. >>>> >>>> NEW >>>> 3. Child DNS operators SHOULD be notified of errors using a >>>> report >>>> query [RFC9567] to the agent domain as described in >>>> Section 4 of >>>> [RFC9859]. Note that this requires listening to >>>> notifications >>>> and that appropriate notification targets are in place >>>> (RFC 9859 >>>> Section 3). >>>> Notifications to humans (domain holder) will be performed >>>> in >>>> accordance with the communication preferences established >>>> with >>>> the parent-side entity. The same condition SHOULD NOT be >>>> reported unnecessarily frequently to the same recipient. >>>> >>>> ## Section 7.1 and Appendix A.4 >>>> >>>> OLD >>>> the registry SHOULD publish the registrar's notification >>>> endpoint >>>> [RFC9859] (if applicable) and refrain from registry-side >>>> DS >>>> automation. >>>> >>>> NEW >>>> the registry SHOULD publish the registrar's notification >>>> endpoint >>>> [RFC9859] (if applicable) instead of their own and refrain >>>> from >>>> registry-side DS automation. >>>> >>>> Other feedback below. >>>> >>>> On 7/9/26 23:33, [email protected] wrote: >>>>> While reviewing this document during Final Review, 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www. >>>>> rfc- >>>> editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com% >>>>> >>>> 7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5 >>>> d20% >>>>> >>>> 7C0%7C0%7C639198827405437888%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >>>> GkiO >>>>> >>>> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >>>> yfQ% >>>>> >>>> 3D%3D%7C0%7C%7C%7C&sdata=CO1jMc45GOaWav99DNx%2FXpUsPtCqw44zxVEfItG >>>> kdTA >>>>> %3D&reserved=0. --> >>>> >>>> DNS >>>> DS # in the title already, but in () >>>> >>>>> 2) <!--[rfced] Should the citation to Section 5 be updated to >>>> Section >>>>> 5.1 to be more specific? >>>>> >>>>> Original: >>>>> Any failures - such as a missing DNSKEY due to improper >>>> rollover timing >>>>> ([RFC6781], Section 4.1), or changed algorithm requirements >>>> - can >>>>> then be communicated in line with Section 5, without >>>> altering or >>>>> removing the existing DS RRset. >>>>> --> >>>> >>>> Sure. >>>> >>>>> 3) <!--[rfced] Should instances of "DNSSEC security" be updated >>>> to >>>>> read simply "DNSSEC" to avoid redundancy (if expanded, "DNSSEC >>>>> security" would read "DNS Security security"). Please review and >>>> let us know if any updates are needed. >>>>> >>>>> Original: >>>>> ... in non-technical language, such as >>>>> "DNSSEC security for your domain has been enabled and will >>>> be >>>>> maintained automatically" >>>>> ... >>>>> DNSSEC security guarantees and associated >>>>> benefits are no longer in effect. >>>>> --> >>>> >>>> No. >>>> >>>> Rationale: Most people consider "DNSSEC" the proper noun of the >>>> technology. Consider a different technology, e.g., VPN, where >>>> these would read "VPN security has been enabled" and "VPN security >>>> guarantees". That's reasonable phrasing, and when people read >>>> "DNSSEC", they don't think of the expansion. >>>> >>>>> 4) <!--[rfced] It's unclear how "further" fits into this >>>> sentence. May >>>>> we remove it? >>>>> >>>>> Original: >>>>> DS automation by the registry further is consistent with >>>> Section 2.3 >>>>> of [RFC5731], which explicitly notes that an EPP server >>>> (registry) >>>>> may override status values set by an EPP client (registrar), >>>> subject >>>>> to local server policies. >>>>> >>>>> Perhaps: >>>>> DS automation by the registry is consistent with Section 2.3 >>>>> of [RFC5731], which explicitly notes that an EPP server >>>> (registry) >>>>> may override status values set by an EPP client (registrar), >>>> subject >>>>> to local server policies. >>>>> --> >>>> >>>> The section lists arguments for the technical recommendation, and >>>> this is a "further" argument (in case a reason would have >>>> formulated the potential related objection in their head). >>>> However, the word is not needed to make the point, so I'll leave >>>> it to your editorial preference. >>>> >>>>> 5) <!--[rfced] It is unclear how "either" fits into this >>>> sentence. May >>>>> we remove it? >>>>> >>>>> Original: >>>>> However, it is not expected to be >>>>> harmful as either DS RRset will allow for the validation >>>> function to >>>>> continue to work, as ensured by Recommendation 1b of Section >>>> 4. >>>>> >>>>> Perhaps: >>>>> However, it is not expected to be >>>>> harmful as the DS RRset will allow for the validation >>>> function to >>>>> continue to work, as ensured by Recommendation 1b of Section >>>> 4. >>>>> --> >>>> >>>> The previous sentence talks about DS flapping: two different >>>> RRsets could be processed in an alternating fashion. The section >>>> is about whether that is a problem. In the context at hand, both >>>> RRsets are functional, so it is not a problem "either DS RRset >>>> works". Replacing "either" by "the" is not correct. >>>> >>>> Many reviewers have not flagged this as a problem, so I'd suggest >>>> to leave as is, in particular as it's only part of the analysis >>>> and not normative. If you feel strongly that this is very >>>> confusing, feel free to suggest an alternative that better conveys >>>> the intended meaning (but again, I think it's fine). >>>> >>>>> 6) <!--[rfced] Throughout the text, the following terminology >>>> appears >>>>> to be used inconsistently. Please review these occurrences and >>>> let us >>>>> know if/how they may be made consistent. >>>>> >>>>> Parent vs. parent >>>>> Child vs. child >>>>> --> >>>> >>>> Those all look fine. >>>> >>>>> 7) <!-- [rfced] FYI - We have added expansions for the following >>>>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). >>>> Please >>>>> review each expansion in the document carefully to ensure >>>> correctness. >>>>> >>>>> DNS-Based Authentication of Named Entities (DANE) >>>>> --> >>>> >>>> OK. >>>> >>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion >>>> of the >>>>> online Style Guide >>>>> >>>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fwww >>>>> .rfc- >>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 >>>>> >>>> C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f >>>> 2651 >>>>> >>>> 1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405470572% >>>> 7CUn >>>>> >>>> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>> AiOi >>>>> >>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x5g6 >>>> h0rW >>>>> 8DkCwzPvWHWXNWYYe8b6fXsP0EskPbIu%2BPQ%3D&reserved=0> >>>>> 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. >>>>> --> >>>> >>>> OK. >>>> >>>> Best, >>>> Peter >>>> >>>> >>>>> Thank you. >>>>> Alanna Paloma and Sandy Ginoza >>>>> RFC Production Center >>>>> >>>>> >>>>> On Jul 9, 2026, at 2:30 PM, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Final Review for RFC-to-be 10026 <draft-ietf-dnsop-ds- >>>> automation> >>>>> >>>>> Your document is now available for Final Review (previously >>>> 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; >>>> see >>>>> the Unavailable Authors section >>>>> >>>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fauthors.ietf.org%2Frfc-publication-process%23unavailable- >>>> authors&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d779 >>>> 3645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >>>> 7C639198827405492069%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >>>> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >>>> 3D%3D%7C0%7C%7C%7C&sdata=u1ybJxNgsq9h8Wn7iTSZmWrAmGDsioP2Qf6SYGc3k >>>> jw%3D&reserved=0). >>>>> >>>>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> trustee.ietf.org%2Flicense- >>>> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d779364 >>>> 5abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 >>>> 39198827405508580%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs >>>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >>>> 3D%7C0%7C%7C%7C&sdata=lX2vF40hvM5PYEWU7pYMAtGWeM8a3cDs%2B35eDXgNKB >>>> A%3D&reserved=0). >>>>> >>>>> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>> Fauthors.ietf.org%2Frfcxml- >>>> vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d >>>> 7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >>>> C0%7C639198827405524771%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >>>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >>>> fQ%3D%3D%7C0%7C%7C%7C&sdata=%2B1oOd%2BlXx%2BNyZWzY7aQZbfUhWrYQQUdU >>>> Fnn11XcC%2BSM%3D&reserved=0>. >>>>> >>>>> * 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 an archival >>>> mailing list >>>>> to preserve discussion about the document while in the >>>> RPC editorial >>>>> queue; it is not an active discussion list: >>>>> >>>>> * More info: >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> mail >>>>> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>>> 4Q9l2USxIAe6P >>>>> >>>> 8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d77936 >>>> 45ab >>>>> >>>> ccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391 >>>> 9882 >>>>> >>>> 7405545160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >>>> wLjA >>>>> >>>> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 >>>> C%7C >>>>> >>>> &sdata=Uc%2F9AcFdQV6xjlEk9R%2FzK97InDnw9XnkrxFYhUYyEsg%3D&reserved >>>> =0 >>>>> >>>>> * The archive itself: >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> mail >>>>> >>>> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 >>>> Cmoh >>>>> >>>> amed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C9 >>>> 0c7a >>>>> >>>> 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405563252%7CUnknown >>>> %7CT >>>>> >>>> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 >>>> zMiI >>>>> >>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xRqCTSLwr2yf3 >>>> qbE3 >>>>> nq%2Bejr87gabELYeahRK8V1%2FiUQ%3D&reserved=0 >>>>> >>>>> * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www.rfc- >>>> editor.org%2Fauthors%2Frfc10026.xml&data=05%7C02%7Cmohamed.boucada >>>> ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4 >>>> 0bfbc48b9253b6f5d20%7C0%7C0%7C639198827405580395%7CUnknown%7CTWFpb >>>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=46nhBRIW7zwI% >>>> 2B%2F8st3PMh1YqoKFMm8CxOp%2B5ny1CUvA%3D&reserved=0 >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www.rfc- >>>> editor.org%2Fauthors%2Frfc10026.html&data=05%7C02%7Cmohamed.boucad >>>> air%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b >>>> 40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405597712%7CUnknown%7CTWFp >>>> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >>>> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AWqGZCZLKRqb >>>> uJ5UIMGtmjVOADAe65iqUkMT6jEz4Xk%3D&reserved=0 >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www.rfc- >>>> editor.org%2Fauthors%2Frfc10026.pdf&data=05%7C02%7Cmohamed.boucada >>>> ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4 >>>> 0bfbc48b9253b6f5d20%7C0%7C0%7C639198827405613287%7CUnknown%7CTWFpb >>>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hL1VfG9z%2B5h >>>> ax5CbhUSwEfZlrARQD7cZdk9aDWGTkr8%3D&reserved=0 >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www. >>>>> rfc- >>>> editor.org%2Fauthors%2Frfc10026.txt&data=05%7C02%7Cmohamed.boucada >>>>> >>>> ir%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20af34b4 >>>> 0bfb >>>>> >>>> c48b9253b6f5d20%7C0%7C0%7C639198827405629650%7CUnknown%7CTWFpbGZsb >>>> 3d8e >>>>> >>>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>>> iTWF >>>>> >>>> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w6BXbzY1d1zCHYujO3FoB5phl >>>> m2Xc >>>>> cWU7mOsX35E12o%3D&reserved=0 >>>>> >>>>> Diff file of the text: >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www.rfc-editor.org%2Fauthors%2Frfc10026- >>>> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4d7 >>>> 793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >>>> 0%7C639198827405645620%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >>>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >>>> Q%3D%3D%7C0%7C%7C%7C&sdata=8dHlCJz1%2FuOoGtXepRMDg1%2BqGLQrMgBbZYm >>>> yzaD9PfM%3D&reserved=0 >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www. >>>>> rfc-editor.org%2Fauthors%2Frfc10026- >>>> rfcdiff.html&data=05%7C02%7Cmohame >>>>> >>>> d.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7 >>>> a20a >>>>> >>>> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405662628%7CUnknown%7C >>>> TWFp >>>>> >>>> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >>>> IsIk >>>>> >>>> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9qjloCAuISz6960P >>>> 6tDg >>>>> LP1s9JioVEElldxLeg7X2I4%3D&reserved=0 (side by side) >>>>> >>>>> Diff of the XML: >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> www. >>>>> rfc-editor.org%2Fauthors%2Frfc10026- >>>> xmldiff1.html&data=05%7C02%7Cmoham >>>>> >>>> ed.boucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c >>>> 7a20 >>>>> >>>> af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405684125%7CUnknown%7 >>>> CTWF >>>>> >>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM >>>> iIsI >>>>> >>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b9bBfZ%2Bg%2BLq >>>> F3yM >>>>> Xz4clZA6Og%2BSCfUIl%2FayDZYZMhCM%3D&reserved=0 >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> Details on the status of your Final Review are here: >>>>> >>>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> queu >>>>> e.rfc-editor.org%2Ffinal- >>>> review%2Frfc10026%2F&data=05%7C02%7Cmohamed.b >>>>> >>>> oucadair%40orange.com%7C5c2fb4d7793645abccde08dee3f26511%7C90c7a20 >>>> af34 >>>>> >>>> b40bfbc48b9253b6f5d20%7C0%7C0%7C639198827405703161%7CUnknown%7CTWF >>>> pbGZ >>>>> >>>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>>> kFOI >>>>> >>>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MF2jXMT1AB1KhFR9tYe >>>> lw1i >>>>> pvngq%2BhH9dhpDcP1%2Bq%2Fw%3D&reserved=0 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC 10026 (draft-ietf-dnsop-ds-automation) >>>>> >>>>> Title : Operational Recommendations for DNSSEC >>>> Delegation Signer (DS) Automation >>>>> Author(s) : Steve Sheng, >>>>> Peter Thomassen >>>>> WG Chair(s) : Benno Overeinder, Ondřej Surý >>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>> >>>> -- >>>> Like our community service? 💛 >>>> Please consider donating at >>>> >>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>> desec.io%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5c2fb4 >>>> d7793645abccde08dee3f26511%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0% >>>> 7C0%7C639198827405717094%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO >>>> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo >>>> yfQ%3D%3D%7C0%7C%7C%7C&sdata=Hxwq%2BQeqPahgVO%2FdhAv1YmE2AZvj94Oma >>>> gjTC4wNhPM%3D&reserved=0 >>>> >>>> deSEC e.V. >>>> Möckernstraße 74 >>>> 10965 Berlin >>>> Germany >>>> >>>> Vorstandsvorsitz: Nils Wisiol >>>> Registergericht: AG Berlin (Charlottenburg) VR 37525 >>> >>> ____________________________________________________________________________________________________________ >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >>> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >>> modified, changed or falsified. >>> Thank you. > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
