Perhaps no time is more critical in the �life cycle� of a domain name 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 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 Task Force
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 (in the absence of certain extenuating circumstances) 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.� During the course of the task force�s work, VeriSign launched their implementation of the Redemption Grace Period.� Although a large number of registrants have been able to restore their domain names during the Redemption Grace Period, there has been some confusion relating to the relatively high cost of such redemptions, which can be several times more expensive than the usual cost of a domain name registration due to higher registry costs and additional administrative burdens.� To alleviate confusion by registrants, the task force recommends that registrars clearly define the fees associated with restoring a domain name during the Redemption Grace Period.
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 allow complainants to pay for the restoration or renewal of the domain name on the same terms that the existing registrant would be allowed to.� This policy gives the complainant 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. Under this proposed policy, the registrar may theoretically collect (potentially large) restoration fees from both the complainant and existing registrant for the same domain name restoration or renewal.� Although the task force believes that registrars may ultimately provide refunds where it seems appropriate rather than viewing this situation as a potential profit center, at some point in the future it may be worthwhile to review registrar practices in this regard to ensure fair treatment of both complainants and existing registrants.
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. However, ICANN has recently adopted policies proposed by the Whois Task Force that the Deletes Task Force believes should address these concerns, so no policy action is required at this time.
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 (RGP) 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 RGP, 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.
Recently, some confusion regarding expiration dates has arisen as a result of VeriSign's implementation of the RGP.�
In accordance the recommendations of the ICANN Redemption Grace Period Technical Steering Group, VeriSign began displaying the expiration date for domain names in the .com and .net registries in conjunction with their implementation of the RGP.� Like other gTLD registries, VeriSign performs a one year auto-renew on expired domains whether or not the registrar has received payment from the registrant. As a result, registrars have been receiving numerous inquiries from confused registrants who do not understand the seeming discrepancy between the expiry date of VeriSign and that of the registrar.
Many registrars have expressed support for the idea that if registries waited to automatically renew the domain name and advance the expiry date until the end of the 45 day grace period that this confusion could be avoided.� However, registries believe that other options may also exist and believe that some further study of the issue is required before a solution is implemented.� The task force is supportive of changes that decrease confusion by registrants, and believes that registries should be allowed to implement such a system if they elect to do so. � 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.
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 At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to consent that the registration be renewed within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration by the end of the auto-renew grace period (although registrars may choose to cancel the name earlier).� 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.
Extenuating circumstances are defined as: - UDRP action - valid court order - failure of a registrars renewal process (which does not include failure of a registrant to respond) - the domain name is used by a nameserver that provides DNS service to third parties (additional time may be required to migrate the records managed by the nameserver) - the registrant is subject to bankruptcy proceedings - payment dispute (where a registrant claims to have paid for a renewal, or a discrepancy in the amount paid) - billing dispute (where a registrant disputes the amount on a bill) - domain name subject to litigation in a court of competent jurisdiction - other circumstance as approved specifically by ICANN
Where a registrar chooses, under extenuating circumstances, to renew a domain name without the explicit consent of the registrant, the registrar must maintain a record of the extenuating circumstances associated with renewing that specific domain name for inspection by ICANN consistent with clauses 3.4.2 and 3.4.3 of the registrar accreditation agreement.
3.1.2 In the absence of extenuating circumstances (as definited in Section 3.1.1), a domain name must be deleted within 45 days of either the registrar or the registrant terminating a registration agreement. 3.1.3 These requirements retroactively apply to all existing domain name registrations beginning 180 days after the implementation of the policy. 3.1.4 Registrars shall provide notice to each new registrant describing the details of their deletion and auto-renewal policy including the expected time at which a non-renewed domain name would be deleted relative to the domain�s expiration date, or a date range not to exceed ten days in length. 3.1.5 If a registrar operates a website for domain name registration or renewal, details of its deletion and auto-renewal policies must be clearly displayed on the website. 3.1.6 If a registrar operates a website for domain registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee charged for the recovery of a domain name during the Redemption Grace Period.
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 which is the subject of a UDRP dispute is deleted or expires during the course of the dispute, a complainant in the UDRP dispute will have the option to renew or restore the name under the same commercial terms as the registrant.� If the complainant renews or restores the name, the name will be placed in Registrar HOLD and Registrar LOCK status, the WHOIS contact information for the registrant will be removed, and the WHOIS entry will indicate that the name is subject to dispute.� If the complaint is terminated, or the UDRP dispute finds against the complainant, the name will be deleted within 45 days.�� The registrant retains the right under the existing redemption grace period provisions to recover the name at any time during the Redemption Grace Period, and retains the right to renew the name before it is deleted.
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.
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.
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.
A number of outreach efforts have been performed to date.
6.1 Initial Outreach
� All task force activities have been documented on the public mailing list maintained at http://www.dnso.org/clubpublic/nc-deletes/Arc00/� and http://www.dnso.org/clubpublic/nc-deletes/Arc01/ .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 GNSO Council. � UDRP dispute resolution providers have been contacted to assess the impact of Recommendation 3.2.1
6.2 Public Comments
The initial report of the task force was published on the ICANN and GNSO website on February 12, 2003, and public comments on the report were accepted from February 12 until March 3.� A summary of the comments, and the task force�s responses are included below:
(1) In two separate messages ( first /second ), L. James Prevo comments on the high pricing on redeption grace period domain name renewals, calling the redeption fee "the worst case of consumer gouging I have ever seen in my life."
(2) "Krishna" writes to ask why the redeption grace period pricing was put into effect without prior notice to domain name registrants so they could "renew the domain name on time before the Redeption period comes into picture."
(3) Marcia Wells also writes to complain about the high pricing on redeption grace period renewals, calling the fees "exploitative and predatory."
TASK FORCE COMMENT ON 1, 2, and 3: Comments on the fee to recover domain names during the Redemption Grace Period are beyond the scope of the task force's work. The ICANN Board recently approved revisions to the Verisign Registry Contract, allowing the new pricing model. The Task Force has taken note of the pricing concerns, however, and will forward the comments above to the ICANN General Counsel, the GNSO's Registrars Constituency, and the GNSO's Registry Constituency.
(4) In separate messages ( first ,second ,third ), Marcia Wells makes a number of recommendations for consideration by the task force, including: (a) providing registrants a means to expressly disavow an intent to renew, thereby allowing the domain name to be cancelled early or deleted promptly upon expiration; (b) ensuring that registrars inform registrants of the fee they intend to charge for renewals during the redeption grace period; and (c) requiring registrars to provide timely and repeated notices to domain name registrants of the impending expiration of their domain names. Ms. Wells also commented that the Deletions Task Force "lacks representation in proportion to the impact of its recommendation."
TASK FORCE COMMENT ON 4: The Task Force was grateful for the many substantive suggestions contained in Ms. Wells' posts and took account of them in its deliberations and revisions to the Task Force document. Specifically, Ms. Wells' suggestion that "registrars inform registrants of the fee they intend to charge for renewals during the redeption grace period" is now included in the proposed recommendation. While the suggestion that registrars provide "timely and repeated notices to domain name registrants of the impending expiration of their domain names" is a good one, the Task Force members noted that a requirement for at least two notifications is currently included in the ICANN Registrar Accreditation Agreement.
(5) Danny Younger argues that Recommendation 3.1.2 is seriously flawed , as it allows a registrar discretion as to when a domain name may be deleted within the forty-five days following its expiration. He proposes a uniform policy whereby domain names are deleted only on the 45th day following expiration.
TASK FORCE COMMENT ON 5: Mr. Younger raises an issue that the Task Force discussed early in its deliberations. At its initial meetings, members of the Task Force appointed from constituencies composed of users raised the same issue as Mr. Younger. The registrars, however, made the point that given their various business models, some flexibility is needed during this grace period.� For example, registries bill the registrars for a renewed domain promptly on its renewal date and then credit the renewal fee back if the domain name is deleted within forty-five (45) days. While some registrars are willing and financially able to front the registry fee on behalf of a domain name registrant, not all registrars are in the same position. The registrars expressed the strong concern that requiring them to bear the registry fee would place an undue hardship on smaller registrars. Based primarily on this concern, the Task Force compromised on the discretionary window of 45 days, which will provide some uniformity and certainty while also allowing those registrars who wish to do so to avoid the registry renewal fee for domain names not renewed by the registrant.� In order to provide registrants with an understanding of their registrar�s deletion policies, however, the task force has recommended that registrars provide registrants with those policies, including a specific time after expiration at which names will be deleted.
(6) Brian Cute, writing on behalf of Network Solutions , believes that the recommendations of the task force will have a negative effect on domain name registrants who oftentimes benefit from registrar grace periods longer than 45 days. He suggests that the new rules would benefit prospective registrants of expiring domain names at the expense of existing registrants, which is the wrong emphasis.
TASK FORCE COMMENT ON 6: During its deliberations, the Task Force, including those members appointed from constituencies comprised of users and registrants, took account of the concerns raised by Network Solutions. On balance, the Task Force members believed that the greater certainty and uniformity required by the recommended rules outweighs the benefits described in Mr. Cute's contribution.
6.3 Implementation Committee
In response to concerns raised by ICANN�s General Counsel with regards to the initial version of this resport, the DNSO council created an implementation committee, chaired by Bruce Tonkin and consisting of representatives from both registries and registrars as well as members of the Deletes Task Force.
The implementation committee suggested a number of revisions to the task force�s policy recommendations in order to make them more practical to implement.� The task force has subsequently reviewed these proposed changes, and has agreed that they are positive refinements on the original recommendations.� As a result, the recommendations in this report have been modified to reflect the changes proposed by the implementation committee, with some minor changes proposed by members of the task force to improve clarity or to ensure that the original intent of the task force�s recommendations remains obvious.
The task force�s initial report was voted upon prior to its publication.� The report received supermajority approval from the members of the task force.� The following representatives voted in favor of the report: � Commercial and Business Users Constituency � General Assembly � GTLD Registries Constituency � Intellectual Property Interests Constituency � Internet Service and Connectivity Providers Constituency � Non-commercial Users Constituency � Registrars Constituency The following representatives abstained: � ccTLD Registries Constituency No dissenting votes were cast.
This final version of the report was also approved by a supermajority of the members of the task force.
Add Grace Period : A period of time (generally five days) provided by the registry after a domain name�s initial registration in which it can be deleted, resulting in a credit for the cost of the registration to the registrar.
Auto-renew Grace Period : A period of time (generally forty-five days) provided by the registry after a domain name is automatically renewed in which it can be deleted, resulting in a credit for the cost of the auto-renewal to the registrar.
Renew Grace Period : A period of time (generally five days) provided by the registry after a domain name is explicitly renewed by the registrar in which the name can be deleted, resulting in a credit for the cost of the renewal to the registrar.
Transfer Grace Period : A period of time (generally five days) provided by the registry after a domain name is transferred between registrars during which the new sponsoring registrar can delete the name, resulting in a credit for the cost of the transfer to the new registrar.
The timeline below represents the lifecycle of a typical domain name that is registered for a single year, and never renewed by the registrant.
As this timeline demonstrates, when the domain �expires� a year after being registered, it is automatically renewed by the registry.� At this point it enters the Auto-renew Grace Period, during which the registrar can delete the name and receive a full credit for the cost of the renewal.� By the end of the Auto-renew Grace Period, if the domain name has not been renewed by the registrant, the registrar must submit a deletion request for the name.� At that point, domain will enter the Redemption Grace Period, in which it may be restored if the deletion request has been made in error.� Only at the end of the Redemption Grace Period is the domain name permanently removed from the registry database and made a part of the pool of available names.� (The Redemption Grace Period does not apply to names deleted within the Add Grace Period, which extends through the first five days after the domain�s initial registration.)
|
1.INTRODUCTION: Deletes Task Force
Last Updated:
Date
