(Resending due to IETF list delivery issues noted today) Thanks, Gavin. Notes below.
> -----Original Message----- > From: Gavin Brown <gavin.br...@icann.org> > Sent: Thursday, May 9, 2024 11:01 AM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: regext@ietf.org > Subject: [EXTERNAL] Re: [Ext] [regext] Re: 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. > > 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. [SAH] OK, agreed. > 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. [SAH] OK, agreed. > 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. [SAH] The context is given in the Section title and the included back references. They're proposed best practices. The back-referenced text that describes each practice notes that they haven't been observed in operation. We could add something like "The practices in this section are described as "best practices" because they address the operational risk and have been observed in operation" to 6.1 and "The practices in this section are described as "proposed best practices" because they address the operational risk and haven't been observed in operation" to 6.2. Would that help? Scott _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
