Hi Scott, My apologies that this feedback comes after you've requested WGLC! I had been meaning to review the document properly and got caught out. I have a couple of minor points and one somewhat less minor.
Full disclosure to the WG: I was an occasional participant in the SSAC group from which Scott's efforts arose. I did contribute something to the report but the last I checked my minor contributions had been removed, so I have no skin in this game :) Section 3.1: the last paragraph describes how allowing host objects to exist after deletion of their superordinate domain object invites hijacking. This is correct, but it would also constitute orphan glue, which I think is worth mentioning, perhaps with a reference to SSAC 048. Section 3.2 discusses how servers that implicitly delete subordinate host objects in response to requests to delete a domain objects can create a data inconsistency condition. This is true, but in my experience from my time at $DAYJOB[-1], where we did this, we never received any complaints from registrars in all the time those complaints would have reached my desk (which was a long time). I think the current text should stand, but I would suggest adding that the potential impact of this inconsistency appears to be small. Onto my less minor point. Section 6.1 describes what the document considers to be the Best Current Practice. However, Section 6.2 then lists two "Best Proposed Practices", with no context on how those relate to the practice in the preceding section. Are they "runners up"? Are they proposeed "Best Practices"? If a registry implements the practices in 6.2.1 or 6.2.2, do they then not need to implement 6.2? I would recommend adding some context here. If 6.2.1 and 6.2.2 are Best Practices, they belong in 6.1. If they aren't, then their relationship to what's in 6.1 needs some clarification. Otherwise I think this document does a good job of explaining the issues and outlining the solution(s) (best, slightly less best, or otherwise). Cheers, G. > On 9 May 2024, at 15:56, Hollenbeck, Scott > <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > >> -----Original Message----- >> From: internet-dra...@ietf.org <internet-dra...@ietf.org> >> Sent: Tuesday, May 7, 2024 10:51 AM >> To: i-d-annou...@ietf.org >> Cc: regext@ietf.org >> Subject: [EXTERNAL] I-D Action: draft-ietf-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-ietf-regext-epp-delete-bcp-02.txt is now available. It >> is a >> work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. >> >> 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-ietf-regext-epp-delete-bcp-02.txt >> Pages: 20 >> Dates: 2024-05-07 >> >> 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 also >> includes guidance for 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] With this update the editors believe this draft is ready for working > group last call. Please say otherwise if you disagree. > > Scott > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
