Based on the desire from Scott Hollenbeck at the IETF-118 REGEXT meeting for
discussion on the list with the options defined in
draft-hollenbeck-regext-epp-delete-bcp, I’m posting this to discuss the “Allow
Explicit Delete of Domain with Restore Capability” option
(https://datatracker.ietf.org/doc/html/draft-hollenbeck-regext-epp-delete-bcp#section-5.7.3.4).
This option came out of the REGEXT thread between me and James Mitchell.
I’ve discussed the option with Registry and Resolution experts and it shows
promise in providing a balanced solution to the problem of deleting domains
that have linked child hosts without requiring the child hosts to be renamed.
The draft provides the description of the option, but I highlight below for
quick reference:
1. Allow the direct deletion of the parent domain example.com with the
linked child host ns1.example.com
2. The parent domain example.com will enter the RGP redemptionPeriod, the
resolution of example.com, and the resolution of name server ns1.example.com
will be removed, but the objects and the links in the registry database will
remain.
* For scalability, the disabling of the ns1.example.com resolution can
be done asynchronously.
3. If there are any issues with the deletion of the parent domain
example.com and cascading resolution issues with domains using ns1.example.com
as a name server, the deletion can be undone via the EPP restore command.
* For scalability, the re-enabling of the ns1.example.com resolution can
be done asynchronously.
4. Else, the parent domain example.com will eventually get purged at the end
of the pendingDelete, which will result in a cascading purge of the child hosts
and the name server links to other domains.
* For scalability, the purging of ns1.example.com and the name server
links can be done asynchronously.
I believe allowing for the non-destructive delete of the parent domain
example.com with restore capability during the RGP redemptionPeriod provides a
good balance of simplicity and protection from accidental or malicious
deletions in the Registry.
Thoughts?
--
JG
[cid87442*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
