1.	INTRODUCTION

There is perhaps no time more critical in the “life cycle” of a domain name more critical than its deletion. This moment is fraught with danger for the existing registrant who has come to use and depend on the domain, full of opportunity for prospective new registrants interested in the name, potentially costly for registrars facing the expiration of various grace periods, and technically challenging for registries facing a surge of interest in popular names.

1.1	Previous Discussion

Issues related to the deletion of domain names have already been discussed several times within the ICANN community.  Beginning in June of 2001, the deletion and subsequent reallocation of domain names within VeriSign’s com/net/org registry resulted in “add storms” that significantly impacted the performance of the registry, and resulted in connection limits on registrars as well as the separation of certain automated registration requests into a separate pool of connections.  Subsequently, VeriSign propsed a new “Waiting List Service” (WLS) for the reallocation of deleted names, first to the Registrars Constituency in December, 2001, then to ICANN in March, the WLS was evaluated by the Transfers Task Force in July, 2002, and then approved by the ICANN board in August, 2002.

In parallel to the discussion of the WLS, in February, 2002, ICANN proposed the creation of a “Redemption Grace Period”, to allow registrants to reclaim domain names deleted in error for up to thirty days after deletion.  The concept was endorsed by the ICANN board in March, 2002, and further explored by a technical steering group, which posted its report in June, 2002.  The ICANN board approved the Redemption Grace Period in June, 2002, and it was implemented by VeriSign in the .com and .net registries in January, 2003.

1.2	Genesis of the Deletes Task Force

Following discussion of the WLS by the Transfers Task Force, the Names Council determined that a number of broader issues related to the subject of the deletion of domain names existed, and should be explored in greater depth.  In order to identify the relevant issues, the Names Council ordered the creation of an issues group during its teleconference on September 12, 2002 .  The issues group posted its report on September 19, 2002, and identified four issue areas:  (1) uniform delete practice after domain name expiry by registrars, (2) deletion following a complaint on WHOIS accuracy, (3) registry delete process, and (4) reversal of renewal transactions.

On October 4, 2002 the Names Council voted unanimously to create a task force to formulate policy recommendations in the four topic areas identified by the issues paper, and the terms of reference for the task force was adopted by the Names Council at its Shanghai meeting on October 29, 2002.

1.3	Terms of Reference

The Deletes Task Force was chartered with the following Terms of Reference:

1. determine whether a uniform delete process by gtld registrars following expiry is desirable, and if so, recommend an appropriate process
2. determine whether a uniform delete process by gtld registrars following a failure of a registrant to provide accurate WHOIS information upon request is desirable, and if so, recommend an appropriate process
3. determine whether a uniform delete and re-allocation process by registries following receipt of a delete command from a registrar is desirable, and if so, recommend an appropriate process
4. determine whether a uniform process for reversing errors in renewal commands without requiring a delete operation is desirable, and if so, recommend an appropriate process

1.4	Overview of Recommendations

This report provides policy recommendations on the first two topic areas identified by the  issues paper and the task force’s Terms of Reference.  The task force also believes that further work needs to be pursued on the subject of a uniform registry reallocation policy, and notes that some interest has been indicated in the subject of warehousing of domain names by registrars.  With regards to the fourth issue, relating to the reversal of errors in the renew command, the task force believes that no alternations in current policy or practice are required at this time.

2.	FINDINGS ON EACH ISSUE

2.1	Uniform delete practice after domain name expiry by registrars
 
Although most domain names are renewed year to year, a significant number of registrations in the gTLD registries (numbering in thehundreds of thousands, if not millions, each year) are not renewed by the current registrant and are eligible for deletion. The reason a non-renewed name has to be affirmatively “deleted” (as opposed to lapsing on its own) is that the registry automatically renews a domain name for another year on the date it is scheduled to expire (and bills the associated registrar the annual registry fee). This automatic In current practice, if the registrant has failed to pay its renewal fee or otherwise indicated that it does not wish to renew the name, the registrar for that domain name has 45 days after the automatic renewal in which to send a “delete” command to the registry asking to have the domain name deleted. If the “delete” commend is sent within the 45 day window, the registrar is credited back the annual registry fee from the gTLD registry.
 
Given these facts, you would assume that when a registrant fails to renew a domain name, the registrar would make sure to delete the name within the 45 day window so the company would not be charged the registry fee. While that happens much of the time, it doesn’t always happen. In many cases, a registrar will decline or fail to issue the delete command within the 45-day window. This results in a domain name that is neither registered to any individual or company nor registerable by any individual or company through the majority of the registrars. This is not a rare phenomenon. At various times over the past year, the number of unregistered domain names held by registrars has been in the hundreds of thousands.
 
From the perspective of a registrant, this presents a conundrum. A domain name that a company wants to register may not be currently registered by anyone else but, at the same time, it’s not eligible for a new registration. The prospective registrant for such a name is left with no information on how to proceed or even any idea of when the domain name might be deleted (some domain names have been held by registrars for years). In some instances, whois information from the original registrant remains in the whois database, even though that registrant no longer wishes to own the domain name.
 
To solve these and other associated problems, the task force recommends that registrars should be required to delete domain names that a customer has failed to renew before the end of the renewal grace period. (ICANN’s new 30-day “redemption grace period” would apply to all such deletions.)  Additionally, in order to provide registrants with a complete understanding of registrars' deletion and renewal policies, the task force recommends that registrars inform registrants of those policies at the time of registration, and maintains them in a conspicuous place on their website.
 
2.2	ISSUE #2: Deletion following a complaint on WHOIS accuracy

The current ICANN Registrar Accreditation agreement requires registrars to maintain the accuracy of WHOIS information, and to require a registrant to update inaccurate information.  Recent pressure on registrars to comply with the clause above in response to complaints about the accuracy of WHOIS data, may have the unintended consequence that it could be exploited by those that want to obtain a domain name from a current registrant.
 
Given that registrars often have trouble contacting registrants at the time of domain name renewal due to a registrant not maintaining up-to-date contact information, the 15 day period may be inadequate and out of proportion to typical 45 day grace periods available during the renewal process following expiry.
 
Much of this problem is 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' Whois data.
 
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.  The registrar should then provide a statement indicating that the data has been verified in conjunction with the request for the name’s redemption.
 
2.3	ISSUE #3: Registry delete process
 
Currently, when a registrar issues a delete command to a registry, registry operators have various methods for actually deleting the name. As a result, registrants have developed various approaches for predicting when deleted names will actually become available for registration - although this isn't an exact science. Typically some registrants (or registrars/resellers on their behalf) scan changes in the zonefile for an early warning that a domain name is about to be deleted. They then send repeated add commands to the registry when they believe that the name may become available.  Over time this has led to performance issues for both the registry operator and registrars, as many commands are executed to try to obtain a deleted name. This current situation leads to two possible issues to address.
 
Registrars and internet users have suggested that they would like to see a uniform process for the actual deletion of a domain name.  In this process they would like to see the registry operator periodically publish a list of names that are scheduled for deletion, and an exact time or time range when the deletion will occur.
 
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, along with the existing Add 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 time. A possible implementation would be as follows:
 
i.	If the domain is within an Add Grace Period when a delete is issued, then it will be deleted immediately. If the domain is within an Add Grace Period and a Renew Grace Period (i.e. it is explicitly renewed within the Add Grace Period), then it will be deleted immediately.
ii.	If a domain name is deleted within any other Grace Period, the registrar will receive an immediate credit and the domain name will be immediately placed in the Redemption Grace Period.
iii.	If the domain is deleted outside of any Grace Period, a successful delete request should always place the domain name in the Redemption Grace Period.
iv.	Registries must implement the Redemption Grace Period as defined in the Technical Steering Group's proposal of June 7, 2002 found at:
  http://www.icann.org/bucharest/redemption-topic.htm
 
Once names are deleted, the process by which they are re-allocated is currently resource-intensive and may seem to be inequitable.  VeriSign, the only gTLD registry currently processing a significant number of deletions and subsequent re-registration of domain names, proposed a "Waiting List Service" in March, 2002, in which potential registrants would be offered the opportunity to subscribe to a waiting list for a particular domain name.  In the event that the name were deleted while the waiting list subscription remained active, the domain would not simply return to the pool of available names, but would be automatically registered by the waiting list subscriber.  Although this service was given provisional approval by the ICANN board in August, 2002, it has still not been implemented by VeriSign.  There may also be alternative approaches to the reallocation process that are fairer, less resource-intensive, or both, than the current reallocation mechanism.  Unfortunately, these alternatives are not necessarily well defined and there is very little real-world experience with any reallocation mechanism, so the task force has been unable to make specific evaluations or recommendations to date.
 
The task force believes that there is significant interest in further study of uniform reallocation of deleted names. However, the task force does not believe that this issue can be satisfactorily resolved within the time frame of our original charter. The task force requests that upon acceptance of its initial report, the Names Council recharters the task force to perform a more extensive analysis of this particular issue.
 
2.4	ISSUE #4: Reversal of renewal transactions
 
In order to correct errors in billable transactions, the various registries provide certain grace periods in which these transactions can be reversed and the cost of the transaction credited back to the registrar.  For example, registries generally provide registrars with a 5 day "add grace period" in which a name registered in error can be deleted, causing a full credit for the domain's registration to be provided to the registrar.
 
Unfortunately, the situation is somewhat more complicated in the area of renew transactions.  Because both the RRP and EPP protocols lack an "undo" function, a registrar that performs an accidental renew command has no way to directly reverse the transaction.  The domain name can be deleted, resulting in a credit for the renewal, but for domains that must remain active, this is not an acceptable solution.
 
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.

3.	RECOMMENDATIONS

As indicated above, specific policy recommendations are limited to two of the four issues identified within the original Issues Paper: Issue #1 (Uniform delete practice after domain name expiry by registrars) and Issue #2 (Deletion following a complaint on WHOIS accuracy).  Recommendations related to Issue #1 have been separated into two sections; the first pertains to uniform deletion practices for all domain names, while the second outlines policy recommendations specific to names subject to a pending UDRP dispute.

3.1	Uniform deletion practice after domain name expiry by registrars

3.1.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 period.
3.1.2	Domain names must be deleted within 45 days of the expiration of the registration agreement between the registrar and registry, unless the agreement is renewed.
3.1.3	These requirements retroactively apply to all existing domain name registrations beginning 180 days after the adoption of the policy.
3.1.4	Registrars must 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 registration.
3.1.5	Registrars must provide their deletion and auto-renewal policies in a conspicuous place on their websites.

3.2	Registrar deletion practice after domain name expiry for domain names subject to a pending UDRP dispute

3.2.1	In the event that a domain the subject of a UDRP dispute is likely to expire during the course of the dispute, the dispute resolution provider will notify the complainant of the impending expiration either at the time the dispute is filed, or no later than 30 days prior to the expiration of the domain.
3.2.2	In such an event, the complainant will have the option to pay for a one year renewal at the sponsoring registrar's current prevailing rate for renewals.
3.2.3	In the event that the complainant paid the renewal fee prior to the domain name’s expiration, the original registrant will have up to thirty days after the end of the relevant registry’s renewal grace period in which to pay for the renewal of the domain name.
3.2.4	In the event that both the registrant and the complainant pay for the renewal, the name will be renewed on behalf of the original registrant in accordance with the registrar's usual policy, and any renewal fee paid by the complainant will be refunded.  The order in which the payments are received shall not effect this provision.
3.2.5	In the event that only the complainant pays for the renewal of the domain name, the registrar will:
3.2.5.1	Place the name on REGISTRAR HOLD and REGISTRAR LOCK, with the result that the name will no longer resolve in the DNS.
3.2.5.2	Modify the Whois entry for the domain name to indicate that the name is the subject to a UDRP dispute, and to remove all specific ownership information for the Whois record.
3.2.5.3	If the complaint is terminated prior to a verdict being rendered, but after the domain reaches this state, the domain name will be deleted.
3.2.6	Where only the complainant paid the renewal fee for a domain name the subject of a UDRP action and the complainant’s UDRP case fails, if the relevant registry’s normal renewal grace period has expired, the domain name will be deleted.
3.2.7	In all other cases, the registrar shall comply with the outcome of the UDRP dispute in accordance with its regular policies.  No provision of this policy should be taken to override the decision in the UDRP dispute.

3.3	Deletion following a complaint on WHOIS accuracy

3.3.1	The Redemption Grace Period will apply to names deleted due to a complaint on WHOIS accuracy.  However, prior to allowing the redemption in such a case, the registrar must update the registration with verified WHOIS data and provide a statement indicating that the data has been verified in conjunction with the request for the name’s redemption.  The same rules that apply to verification of WHOIS data for regular domain names following a complaint will apply to deleted names.

4.	OTHER ISSUES

4.1	Domain name warehousing

In the task force’s discussion of registrars’ deletion practices, the subject of warehousing of domain names by registrars was raised.  Three specific modes of warehousing were identified:

(1)	The registrant allows the domain name to lapse, but registrar fails to delete the domain name during the grace period, resulting in a paid renewal to the registry.  The registrar subsequently assumes ownership of the domain name.
(2)	The registrant purchases the domain name through fraud and the registrar assumes ownership of the name to resell in order to minimize losses.
(3)	The registrar purchases the domain in its own name outright.

The task force believes that its current set of recommendations deals with the first scenario described above.  The other scenarios are not clearly subject to the task force’s terms of reference, and have not been fully explored by this group, nor have any policy recommendations been made in their regard.  The Names Council may wish to explore these issues separately, or recharter this task force to explore one or both of these scenarios.

5.	IMPACT OF RECOMMENDATIONS

Registrars
Registries
Registrants
UDRP Providers

6.	OUTREACH EFFORTS

A number of outreach efforts have been performed to date:

•	All task force activities have been documented on the public mailing list maintained at http://www.dnso.org/clubpublic/nc-deletes/Arc00/
•	Task force members have circulated draft recommendations to their various constituencies.
•	The draft recommendations and status of the task force’s work has been communicated to the Names Council.

Additional outreach efforts will begin with the publication on this report.  The task force will welcome public comments, which will be considered prior to the publication of a final report.  Constituencies will also be encouraged to submit formal comments to the task force during this time.