[nc-deletes] Draft recommendations
I suppose in the spirit of some of the other task forces out there, we ought
to have a whole lot more text, and indeed we'll probably add some. The
following text constitutes, essentially, a first draft at the
recommendations section of the report. I may get a chance to add some of
the other stuff tomorrow.
I think I've highlighted the areas of general agreement, and in brackets
you'll find placeholders for the issues in which there is still some
remaining discussion to be had. I'm certainly open to feedback,
wordsmithing, etc. on the existing text, as well.
Issue 1: As indicated in the issues paper, the status quo presents an
environment in which users may not always understand the deletion process
applied to their domain name. While recognizing the need for registrars to
pursue their own business models, the task force recommends that certain
baseline policies be adopted by all registrars. Specifically:
1. Domain names must be deleted if a paid renewal has not been processed by
the end of the auto-renew grace period (generally forty-five days after the
domain's initial expiration). As a mechanism for enforcing this
requirement, registries may elect to delete names for which an explicit
renew command has not been received prior to the expiration of the grace
2. Registrars should provide a summary of their deletion policy, as well as
an indication of any auto-renewal policy that they may have, at the time of
3. Registrars should provide their deletion and auto-renewal policies in a
conspicuous place on their websites.
<<<<<Under discussion: whether or not registrars should be required to not
delete a name for a portion of the grace period.>>>>>
A special case exists for names that expire during the course of a UDRP
dispute. In order to prevent the name from lapsing and being re-allocated
during the dispute, the task force proposes the following:
<<<<<Insert finalized UDRP policy here.>>>>>
Issue 2: Many of the problems raised within the issues paper are already
under consideration by the Whois task force. In order to avoid overlap
between the two task forces, the Deletes Task force determined that:
1. The scope of the Whois Task Force is to determine under what
circumstances a domain name should be deleted for reasons relating to the
domain's Whois data.
2. The scope of the Deletes Task Force is to determine what happens to a
domain name once it has been deleted for reasons relating to the domains'
In most respects, a name deleted for reasons relating to inaccuracy of Whois
data is treated identically to a name deleted for any other reason.
However, it is important to prevent registrants from using the Redemption
Grace Period to simply re-instate names once they have been deleted, without
providing accurate Whois information. In order to prevent this, the task
force recommends that registrars require that registrants of such names
provide new, verified Whois information. This new data should be provided
as part of the documentation to the registry in conjunction with the request
for the name's redemption.
Issue 3: The task force believes that the recently adopted Redemption Grace
Period not only provides registrants with crucial protection in the event of
inadvertent deletion or misunderstanding of deletion policy, but also
provides significant transparency into the deletion process as lists of
names to be purged from the registry's system are published on a regular
basis. The task force feels that the Redemption Grace Period provides an
adequate level of consistency and transparency in terms of registry deletion
policy, and does not recommend any other specific steps be adopted at this
<<<<<I'm holding off on re-allocation until we have some more
Issue 4: The task force has found that this issue is primarily technical in
nature. Although both the RRP and EPP protocols lack an "undo" function
that would allow for the direct reversal of a renewal without deleting these
domains, registries generally have administrative procedures in place that
allow for such transactions to be reversed out-of-band. As a result, the
task force sees no need to take action on this issue.
In the event that registries or registrars desire this capability to be
added to the EPP protocol, the task force believes that these changes are
best pursued through technical fora such as the IETF.