Scott, Thank you very much for the explanation. I will change the review to READY. Linda -----Original Message----- From: Hollenbeck, Scott <shollenbeck@xxxxxxxxxxxx> Sent: Tuesday, December 3, 2024 6:29 AM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; gen-art@xxxxxxxx Cc: draft-ietf-regext-epp-delete-bcp.all@xxxxxxxx; last-call@xxxxxxxx; regext@xxxxxxxx Subject: RE: Genart last call review of draft-ietf-regext-epp-delete-bcp-08 > -----Original Message----- > From: Linda Dunbar via Datatracker <noreply@xxxxxxxx> > Sent: Monday, December 2, 2024 12:56 PM > To: gen-art@xxxxxxxx > Cc: draft-ietf-regext-epp-delete-bcp.all@xxxxxxxx; last-call@xxxxxxxx; > regext@xxxxxxxx > Subject: [EXTERNAL] Genart last call review of > draft-ietf-regext-epp-delete- > bcp-08 > > 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. > > Reviewer: Linda Dunbar > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > For more information, please see the FAQ at > > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsec > ure-web.cisco.com%2F1md90TGXXQYUlPuZT2sb-&data=05%7C02%7Clinda.dunbar% > 40futurewei.com%7Cf3d87f236fa7494bae5208dd13a6d2e1%7C0fee8ff2a3b240189 > c753a1d5591fedc%7C1%7C0%7C638688329478007912%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6ExAt%2B%2FiNBxm%2FRVj7gc517c > %2FdaAXmsurZi4lyPqpMXY%3D&reserved=0 > F_TP98xEFrpqe9VulBV-qDBQ5UpLswRb_ZWFJnk2Gb5NxRnAxnZuX2erkF- > wnLgtCiVWblGlxfUxjL7fhonm9IfY_yAnikIJ4gFvpw3OrIJR0GFOniZKpY_8KRUS > 3_1khf7uJ1bATZ3VlbzFPVA1zwWW07qiQ3saWejX8DdLduVJ7JfGl6326hBQc > 2IMfw8HygYfq-Lqd0s7jqELYyj3vmfVA- > 1Fw6A2ah4lqMdsiDvn_wGgZOrx6SBdOY- > au7z8RyNgloYAXy0qQwlQbuk8D1VAn- > G5XAfzttaICU74alN8/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen > %2FGenArtFAQ>. > > Document: draft-ietf-regext-epp-delete-bcp-08 > Reviewer: Linda Dunbar > Review Date: 2024-12-02 > IETF LC End Date: 2024-11-28 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document thoroughly explores the impacts of deletion > practices and the unintended consequences for DNS resolution. > > Major issues: > > Minor issues: The document highlights multiple renaming approaches but > does not always clarify the scenarios where these approaches are most > suitable. For example, in Section 5.1.3.4 ("Renaming to Sacrificial > Name Server Host Objects Maintained by the Client"), it mentions that clients "MAY" > rename to sacrificial hosts, but the risks of domain hijacks are still > substantial without strict maintenance. [SAH] Thanks for the review, Linda. Section 5 (the analysis section) exists to describe the practices, their risks, and their benefits. It's not intended to describe where they're suitable because the recommendations are given in Section 6. Any practice that isn't described as a best practice in Section 6 is NOT RECOMMENDED. > Nits/editorial comments: > > Section 4 (Page 6): Do you mean "ns1.domain2.example" in the following > sentence? > "Host object "ns1.domain1.example" is associated with domain object > "domain2.example" by ClientY." [SAH] No, the text is correct as written. It's a case of a second client using a host object that was registered by a first client. In simpler terms, this is basically what happens when you register a domain name with a registrar, and you specify name servers for your domain that exist in a different domain that's managed by a second registrar. Scott -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
