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*image001.png@01D960C5.C631DA40]

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/>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to