Jim, For 3.1.1, we will discuss the inclusion of the glue policies section. It might make sense to move it to a focused informational draft. For 5.2.1, that’s a good point on the renaming issue. We can add it in the next draft. For 6.2.1, we can rewrite the best proposed practices to more clearly refer back to specific practices above.
Thanks! Bill On 1/4/24, 9:55 AM, "regext on behalf of regext-requ...@ietf.org <mailto:regext-requ...@ietf.org>" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of regext-requ...@ietf.org <mailto:regext-requ...@ietf.org>> wrote: Message: 3 Date: Thu, 4 Jan 2024 14:54:56 +0000 From: "Gould, James" <jgo...@verisign.com <mailto:jgo...@verisign.com>> Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-regext-epp-delete-bcp-02.txt Message-ID: <e490aa3b-5148-44c5-bee9-b6387b871...@verisign.com <mailto:e490aa3b-5148-44c5-bee9-b6387b871...@verisign.com>> Content-Type: text/plain; charset="utf-8" Scott, I support adoption of the draft since it's important for the community to resolve this in a consistent manner. Below is my feedback to the changes in -02: 1. Section 3.1.1 ?Impact of Glue Policies? * I believe this section is interesting, but I don?t see the correlation of the glue policies with the deleting of domain and host objects. * The word ?publish? means that the server would still collect the glue, but the glue would not be published in DNS? i. There is a chicken and egg scenario when it comes to host and domain management in EPP, where the domain (example.com) needs to be created first, then the child host (ns3.example.com) needs to be created following the registries glue policy (inclusion of glue as an internal host), and then the host can be linked to the parent domain (example.com) as a delegating name server (in-bailiwick name server). ii. This means that all internal hosts would include the glue and it would be the glue policy that determines what glue gets published in DNS. We require glue for all .COM and .NET hosts and we removed the inclusion of the cross-zone glue (.NET glue for a .COM domain and vice-versa) as an example of a similar glue policy change. * The existence of the glue records is not the rationale to prohibit the deletion of domain objects with linked subordinate host objects. It is the associated with referential integrity of the registry database and reducing the risk of impacts of a domain deletion. We need to also consider the unhappy case where an active domain with thousands of delegating child hosts is deleted by accident or maliciously. The glue policy is not correlated to the number of child hosts created and the number of links made to those child hosts as delegating name servers. * The last sentence ?The more restrictive glue policy can reduce the need for deleting host objects? needs further explanation, since I don?t see the correlation. 1. Section 5.2.1 ?Renaming to Reserved TLD? * An additional detriment for this practice is the lack of cleanup of unresolvable name servers in the EPP server. This applies to all the renaming practices since the unresolvable child hosts are being moved aside instead of getting deleted to support the deletion of the parent domain. 2. Section 6.2.1 ?Safe Host Deletion? * I assume that this matches with the practice in section 5.7.3.4 ?Allow Explicit Delete of Domain with Restore Capability?, since it states, ?Hosts would be deleted with restore capability?. My recommendation is to move section 5.7.3.4 ?Allow Explicit Delete of Domain with Restore Capability? as a sibling of section 5.7 ?Allow Explicit Delete of Host Objects? and directly reference it in Section 6.2.1. I view ?Allow Explicit Delete of Domain with Restore Capability? as a viable practice to support the primary use case of deleting an unused parent domain with linked child hosts and support the additional accidental or malicious use case of deleting an active domain with many linked child hosts with full restore capability. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <mailto:jgo...@verisign.com> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com <mailto:jgo...@verisign.com>> 703-948-3271 12061 Bluemont Way Reston, VA 20190 ?On 1/4/24, 8:14 AM, "regext on behalf of Hollenbeck, Scott" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> on behalf of shollenbeck=40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org> <mailto:40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org>>> wrote: 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. > -----Original Message----- > From: I-D-Announce <i-d-announce-boun...@ietf.org > <mailto:i-d-announce-boun...@ietf.org> <mailto:i-d-announce-boun...@ietf.org > <mailto:i-d-announce-boun...@ietf.org>>> On Behalf Of > internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > <mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> > Sent: Thursday, January 4, 2024 8:11 AM > To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> > <mailto:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>> > Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-epp-delete-bcp- > 02.txt > > 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. > > Internet-Draft draft-hollenbeck-regext-epp-delete-bcp-02.txt is now > available. > > Title: Best Practices for Deletion of Domain and Host Objects in the > Extensible Provisioning Protocol (EPP) > Authors: Scott Hollenbeck > William Carroll > Gautam Akiwate > Name: draft-hollenbeck-regext-epp-delete-bcp-02.txt > Pages: 19 > Dates: 2024-01-04 > > Abstract: > > The Extensible Provisioning Protocol (EPP) includes commands for > clients to delete domain and host objects, both of which are used to > publish information in the Domain Name System (DNS). EPP includes > guidance concerning those deletions that is intended to avoid DNS > resolution disruptions and maintain data consistency. However, > operational relationships between objects can make that guidance > difficult to implement. Some EPP clients have developed operational > practices to delete those objects that have unintended impacts on DNS > resolution and security. This document describes best practices to > delete domain and host objects that reduce the risk of DNS resolution > failure and maintain client-server data consistency. [SAH] FYI, folks. We've updated the draft to address feedback received during and after IETF-118. Now the question is, "what next?". Is this a draft that regext would consider adopting? I'd like to think that there's very little work to do with it if we as a community agree with the "best practice" recommendations. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
