DELETES ISSUE PAPER
The Deletes Issue Paper has been prepared by a small team comprising:
Ross Wm. Rader
Jordyn A. Buchanan
Recent policy development activity in relation to studying transfers in the transfers task force, providing advice on the Verisign Wait List Service proposal, and in considering the redemption grace period proposal has highlighted a range of issues associated with current delete processes within the gtlds.
The ICANN Registrar Accreditation agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm ) contains the following clause:
"3.7.5 Registrar shall register Registered Names to Registered Name Holders only for fixed periods. At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to pay a renewal fee within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration. In the event that ICANN adopts a specification or policy concerning procedures for handling expiration of registrations, Registrar shall abide by that specification or policy."
The above clause leaves open a deadline for deleting a name (and hence making it available for registration by others) after a domain name is not renewed.
For the com/net/org registry, the registry operator auto-renews domain names at the expiry date of a domain. There is then a 45 day grace period following the expiry date, when a registrar may delete a name, and be credited for the renewal fee. Most registrars tend to explicitly delete names before the end of the 45 day period, although some do not, and often names are retained within the registry for an indeterminate period of time for various reasons. Sometimes names are withheld from the market for periods beyond a few months.
Lack of consistent practice in this area may, amongst other things, cause substantial potential confusion among registrants.
"2.3 Auto-Renew Grace Period The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this circumstance the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days."
The .biz and .info agreements have similar provisions.
In contrast the .name agreement (http://www.icann.org/tlds/agreements/name/registry-agmt-appc-5-02jul01.htm) states:
"The .name Registry Operator does not support an Auto-Renew Grace Period. Upon the expiration of the term of a domain name registration or SLD E-mail address registration, the registration is cancelled unless its term has been explicitly extended by the sponsoring registrar."
Some registrars choose to undelegate a domain name (ie remove it from the zonefile) so that a registrants email and web services may be suspended. This often assists in contacting a registrant that has failed to renew a domain name. Other registrars may delete the name without further warning if the name is not renewed.
Some registrars choose not to delete a name even if it has not been renewed, if there is a dispute (for example UDRP) process underway. There may be other circumstances where a registrar may not want to delete the domain name after expiry, even though the renewal has not been paid.
The end result of the above situation is consumers do not have a consistent environment for the process of deleting a name. This applies to consumers that have a domain name that is expired (they have no idea how long they have to attempt to renew the name before it is deleted), and those consumers that desire an existing domain name that is no longer in use (they have no idea when the name may become available).
Lack of consistent practice in these areas may, amongst other things, cause substantial confusion among registrants.
A possible policy action is to consider a uniform delete process amongst gtld registries and registrars.
The ICANN Registrars Accreditation agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm) requires registrars to maintain the accuracy of WHOIS information, and to require a registrant to update inaccurate information. Note clause 184.108.40.206 states:
"220.127.116.11 A Registered Name Holder's willful provision of inaccurate or unreliable information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration shall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for cancellation of the Registered Name registration."
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. The introduction of the proposed Wait List Service may make this a more attractive option.
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.
A possible policy action is to review steps that should be taken by a registrar to contact a registrant that has not maintained accurate contact information, which may include a period where the name is first undelegated before it is deleted, and may include a delete period that corresponds to grace periods allowed in issue (1) above.
After a registrar issues a delete command to a registry, registry operators have various methods for actually deleting a name. Registrants have also developed various approaches for predicting when the name 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.
Some registrars 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. In addition, some registries would like to see a standard method for the addition of names, such as a round-robin queue system, to help alleviate problems from add storms, and to provide an equitable manner of domain name reallocation. This may result in a fairer market for obtaining these names, and may ensure that the "add" storm is confined to a small segment of time.
A possible policy action is to determine a uniform process for a registry to delete and reallocate names that ensures that the market is equally informed of the names about to be available, and schedule for when the names are available.
With reference to the Renew/Extend grace period of the .com Registry agreement: http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm (similar wording is in the .biz, .info and .name agreements)
If an error is made during a renew operation, the operation can only be reversed and the registrar provided with a credit for the renewal, by deleting the domain name registration.
Given that mistakes can happen, it may be prudent to create a facility that would allow for renewal commands to be reversed (within a specific time period after the initial transaction perhaps) that wouldn't require the deletion and corrective re-registration of the domain name.
Lack of consistent practice in this area may, amongst other things, cause a registrant to inadvertently lose their domain name registration.
© DNSO Secretariat