1.1 Previous Discussion

Issues related to the deletion of domain names have 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 proposed 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, 2002. The WLS was evaluated by the DNSO’s 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

Following discussion of the WLS by the Transfers Task Force, the Names Council determined that a number of broader issues regarding 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, tasked with identifying the most important aspects of deletions for further study, 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 alterations in current policy or practice are required at this time.

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 are not renewed by the current registrant and are eligible for deletion. Currently, a non-renewed name has to be affirmatively “deleted” (as opposed to lapsing on its own) because 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). 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 to ensure a credit for the registry fee. However, in some cases, this does not occur, and a registrar will decline or fail to issue the delete command within the 45-day window. This results in a domain name that is perhaps not wanted by the existing registrant (and in some cases, not registered to any individual or company); at the same time, the name is not available for registration by any individual or company through the majority of the registrars.

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 the registrant has failed to renew. (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.

The task force also found that there is not a consistent policy between registrars in relation to domain names that lapse while a UDRP claim is underway.  Although it is usually possible for a third party to pay the renewal fee for a domain name, some cases may exist in which the original registrant may not wish to have the domain name renewed.  The ideal resolution to this would not result in additional expense by the registrar, (e.g. simply forcing the registrar to renew the domain name at their own expense) or the registry (to implement a unique variation on the Redemption Grace Period for such names).  The task force proposes a policy that will require the arbitration case manager to inform the complainant in the event that a domain name is likely to be deleted during the UDRP process.  The complainant will then have the opportunity to pay the renewal fee to prevent the domain name lapsing without obtaining any rights to the domain name unless successful in its UDRP complaint.

2.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.

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 registrants of such names to confirm and verify the current WHOIS information or provide new, verified WHOIS information in a manner consistent with current consensus policy on WHOIS data verification. The registrar should then provide a statement indicating that the data has been verified in accordance with the current prevailing requirements as part of the Registrar Restore Report submitted to the registry in conjunction with the registry redemption request.

2.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 zone file 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.

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 suggests the Names Council to either recharter the present task force to perform a more extensive analysis of this particular issue or consider other mechanisms to further study this issue.

2.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.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 received by the registrar from the registrant or someone acting on the registrant’s behalf 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 registrant, 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 both the complainant and respondent 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. In order to facilitate this process, registrars will provide the expiration date of the domain at the time it confirms the registration of the domain to the UDRP provider.

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 Auto-renew Grace Period in which to pay for the renewal of the domain name. If neither the complainant nor the original registrant pay for the renewal of domain name, it will be subject to deletion no later than the end of the Auto-renew Grace Period.

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. shall not effect this provision.

3.2.5 In the event that only the complainant pays for the renewal of the domain name, prior to the expiration of the Auto-renew Grace Period 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 registration information for the Whois record.

3.2.5.3 If the complaint is terminated prior to a panel decision being rendered, but after the domain name 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.

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.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 registration of the domain name.

2. The registrant purchases the domain name through fraud and the registrar assumes registration of the name to resell in order to minimize losses.

3. The registrar registers 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.

4.2 Enforcement mechanisms

During discussion of specific policy recommendations, various task force members raised the question of how these recommendations would be enforced. One of the greatest boons of these recommendations is that they provide greater consistency and transparency in the deletion process. If the recommendations are not uniformly and universally implemented, this consistency is undermined. Unfortunately, at present ICANN relies on what has been referred to in the domain name industry as the “nuclear threat” of deaccredidation and contract termination, with few more nuanced mechanisms to ensure compliance. The task force believes that credible enforcement mechanisms are an important component of the success of its recommendations and considered making specific enforcement suggestions as part of this report.

At the same time, the task force recognizes that other task forces are making their own new policy recommendations, and that there are existing elements of ICANN policy that would benefit equally from vigorous enforcement. The task force believes that the ICANN community would benefit from a consistent set of enforcement mechanisms, perhaps combined with a categorization scheme that types of violations could be identified with. (For example, lesser infractions might be considered type “B” violations, with less severe penalties than more serious type “A” violations.)

5.1 Registrars

Several of the policy recommendations may require some registrars to make minor modifications to their existing policies and practices. Additionally, the policy recommendations are likely to require changes in the Registry Registrar Agreements and Registry Accreditation Agreement as they are implemented. However, the recommendations are expected to have low technical impact and cost, with a high level of acceptance. The task force believes that all of its recommendations can be implemented within 180 days of their adoption.

5.2 Registries

The task force recommends that registries adopt the Redemption Grace Period. This recommendation represents continuing support for existing ICANN policy, and should not cause any incremental impact upon registries.

As indicated above, the task force’s policy recommendations are likely to require changes in the Registry Registrar Agreements, and may require some enforcement by registries. The recommendations are expected to have low technical impact and cost, with a high level of acceptance. The task force believes that all of its recommendations can be implemented within 180 days of their adoptions.

5.3 Registrants

The task force’s recommendation that registrars be required to delete domain names by the end of the relevant Renewal Grace Period should provide greater certainty about the treatment of their domain names, but may result in less time to renew the name in some cases. The recommendation to require conspicuous posting of deletion and auto-renewal policies, both at the time of registration and on the registrar’s website, should provide improved clarity and transparency for registrants.

The recommendation to require verification of WHOIS data prior to the redemption of a name deleted following a complaint on WHOIS data accuracy may make the redemption of such names a slightly more complicated proposition and could lead to the permanent loss of a domain name.

Registrants who restore names under the Redemption Grace Period will potentially face higher fees than they typically pay for registration and renewal. For example, VeriSign recently implemented the Redemption Grace Period for .com and .net at a cost of $85 in addition to the usual $6 registry fee. In cases of registrar error, the registrar will have the option of paying this fee instead of charging the registrant.

5.4 Other Internet Users

The task force recommendations that domain names be deleted by the end of the relevant Renewal Grace Period and that registrars conspicuously post deletion and auto-renew policies should provide Internet users with greater transparency into the deletion process.

The recommendation requiring verification of WHOIS data prior to the redemption of a name deleted following a complaint on WHOIS data accuracy should lead to a general improvement of the reliability of WHOIS data for Internet users.

5.5 UDRP Providers

The policy recommendations described in Section 3.2.1 of this report will require that UDRP Providers verify the expiration date of domain names subject to UDRP dispute and notify both complainants and respondents if the name is likely to expire during the course of the complaint. The task force has begun notifying UDRP providers of its proposed changes. Based on initial feedback from the providers, it appears that some providers may already be providing this notification, and that the requirement is unlikely to be burdensome.