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
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 1/4/24, 8:14 AM, "regext on behalf of Hollenbeck, Scott"
<regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of
shollenbeck=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>> On Behalf Of
> 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>
> 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 <mailto:regext@ietf.org>
https://secure-web.cisco.com/1zJaa1Y1-1JO8IU1RKO_6EyAxcRzxPsdl5brDY6vOm9NddTayFtL1WWoKIDugi46bXfpUg5zrzgqqStFLtKd09nQSpsctfTqmyk87zqrUABcu1ucXesUA9zvkFInXbfgHZnerPH6x2ft8QxlOdvTaRBH1wIyoM8teu1kj2jKKfDcDgraAKaCw6k5pIxhpewc-EgDbbTrkfH0erNJ_RIBVP0FvrOV_Zmu7Ly7h_u5i2tSubPZo5OBvAdIx-BfGI4BsMB6DX01y8nKmz9SmE2CNa8KiH2GakzquQFkb5muBQrI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
<https://secure-web.cisco.com/1zJaa1Y1-1JO8IU1RKO_6EyAxcRzxPsdl5brDY6vOm9NddTayFtL1WWoKIDugi46bXfpUg5zrzgqqStFLtKd09nQSpsctfTqmyk87zqrUABcu1ucXesUA9zvkFInXbfgHZnerPH6x2ft8QxlOdvTaRBH1wIyoM8teu1kj2jKKfDcDgraAKaCw6k5pIxhpewc-EgDbbTrkfH0erNJ_RIBVP0FvrOV_Zmu7Ly7h_u5i2tSubPZo5OBvAdIx-BfGI4BsMB6DX01y8nKmz9SmE2CNa8KiH2GakzquQFkb5muBQrI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
