GNSO Council Deletes Task Force
Final Report
22 March 2003
| | GNSO Council Deletes Task Force 22 March 2003 |
Perhaps no time is more critical in the “life cycle” of a domain namethan 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.
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 wellas the separation of certain automated registration requests into a separate pool of connections. Subsequently, VeriSign proposed a new “Waiting ListService” (WLS) for the reallocation of deleted names, first to the RegistrarsConstituency 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 upto 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.
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 creationof 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 issuespaper, and the terms of reference for the task force was adopted by theNames Council at its Shanghai meeting on October 29, 2002 .
The Deletes Task Force was chartered with the following Terms of Reference:
determine whether a uniform delete process by gtld registrars following expiry is desirable, and if so, recommend an appropriate process
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
determine whether a uniform delete and re-allocation process by registries following receipt of a delete command from a registrar is desirable, andif so, recommend an appropriate process
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
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 thesubject of a uniform registry reallocation policy, and notes that some interesthas 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 therenew command, the task force believes that no alterations in current policyor practice are required at this time.
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 currentpractice, if the registrant has failed to pay its renewal fee or otherwiseindicated that it does not wish to renew the name, the registrar for thatdomain 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 backthe 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 somecases, this does not occur, and a registrar will decline or fail to issuethe delete command within the 45 day window. This results in a domain namethat is perhaps not wanted by the existing registrant (and in some cases,not registered to any individual or company); at the same time, the nameis not available for registration by any individual or company through themajority 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 byanyone 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 onhow 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 recommendsthat registrars inform registrants of those policies at the time of registration, and maintains them in a conspicuous place on their website. During thecourse of the task force's work, VeriSign launched their implementationof the Redemption Grace Period (RGP) within the .com and .net registries. Although a large number of registrants have been able to restore theirdomain names during the RGP, there has been some confusion relating to therelatively high cost of such redemptions, which can be several times moreexpensive than the usual cost of a domain name registration due to higherregistry costs and additional administrative burdens. To alleviate confusionby registrants, the task force recommends that registrars clearly definethe fees associated with restoring a domain name during the Redemption GracePeriod.
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 isunderway. Although it is usually possible for a third party to pay the renewalfee for a domain name, some cases may exist in which the original registrantmay not wish to have the domain name renewed. The ideal resolution to thiswould not result in additional expense by the registrar, (e.g. simply forcingthe registrar to renew the domain name at their own expense) or the registry(to implement a unique variation on the Redemption Grace Period for suchnames). The task force proposes a policy that will require the arbitrationcase manager to inform the complainant in the event that a domain name islikely to be deleted during the UDRP process. The complainant will thenhave the opportunity to pay the renewal fee to prevent the domain name lapsingwithout obtaining any rights to the domain name unless successful in itsUDRP complaint.
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 bythose that want to obtain a domain name from a current registrant.
Much of this problem is already under consideration by the Whois taskforce.
In order to avoid overlap between the two task forces, the Deletes Task Force determined that:
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.
The scope of the Deletes Task Force is to determine what happensto 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 taskforce recommends that registrars require registrants of such names to confirmand 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 aspart of the Registrar Restore Report submitted to the registry in conjunctionwith the registry redemption request.
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 ontheir behalf) scan changes in the zone file for an early warning that a domainname is about to be deleted. They then send repeated add commands to theregistry when they believe that the name may become available. Over timethis 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 currentsituation 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 listof names that are scheduled for deletion, and an exact time or time rangewhen 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 eventof inadvertent deletion or misunderstanding of deletion policy, but alsoprovides significant transparency into the deletion process as lists of namesto 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 registrydeletion policy, and does not recommend any other specific steps be adoptedat this time.
Recently, some confusion regarding expiration dates has arisen as a result of VeriSign's implementation of the RGP.
In accordance with the recommendations of the ICANN Redemption Grace Period Technical Steering Group, VeriSign began displaying the expiration datefor domains in the .com and .net registries in conjunction with their implementation of the RGP. Like other gTLD registries, VeriSign performs a one year auto-renewal 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 discrepancybetween the expiry date provided by 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 expirationdate until the end of the 45 day grace period that this confusion could beavoided. However, registries believe that other options may also exist andwould like to see some further study of the issue 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 iscurrently resource intensive and may seem to be inequitable. VeriSign, theonly gTLD registry currently processing a significant number of deletionsand subsequent re-registration of domain names, proposed a "Waiting ListService" in March, 2002, in which potential registrants would be offeredthe opportunity to subscribe to a waiting list for a particular domain name. In the event that the name were deleted while the waiting list subscriptionremained active, the domain would not simply return to the pool of availablenames, but would be automatically registered by the waiting list subscriber. Although this service was given provisional approval by the ICANN boardin August, 2002, it has still not been implemented by VeriSign. There mayalso 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 thereis very little real worldexperience with any reallocation mechanism, so thetask force has been unable to make specific evaluations or recommendationsto date.
The task force believes that there is significant interest in furtherstudy of uniform reallocation of deleted names. However, the task force doesnot believe that this issue can be satisfactorily resolved within the timeframe of our original charter. The task force suggests the Names Councilto either recharter the present task force to perform a more extensive analysisof this particular issue or consider other mechanisms to further study thisissue.
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 areaof 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 allowfor such transactions to be reversed out-of-band. As a result, the taskforce 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 relatedto Issue #1 have been separated into two sections; the first pertains touniform deletion practices for all domain names, while the second outlinespolicy recommendations specific to names subject to a pending UDRP dispute.
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 theexpiration 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, unlessthe 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. This policy should include the expected time at whicha 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 Registrars must provide their deletion and auto-renewal policies in a conspicuous place on their websites.
3.1.6 Registrars should provide, both at the time of registration andin a conspicuous place on their website, the fee charged for the recoveryof a domain name during the Redemption Grace Period.
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 priorto 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 ratefor renewals.
3.2.3 In the event that the complainant paid the renewal fee prior tothe domain name’s expiration, the original registrant will have up to thirtydays after the end of the relevant registry’s Auto-renew Grace Period inwhich to pay for the renewal of the domain name. If neither the complainantnor the original registrant pay for the renewal of domain name, it will besubject 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 theregistrar will:
3.2.5.1 Place the name on REGISTRAR HOLD and REGISTRAR LOCK, with theresult 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 willbe 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 domainname will be deleted.
3.2.7 In all other cases, the registrar shall comply with the outcomeof the UDRP dispute in accordance with its regular policies.
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 verifiedin conjunction with the request for the name’s redemption. The same rulesthat apply to verification of WHOIS data for regular domain names followinga complaint will apply to deleted names.
In the task force’s discussion of registrars’ deletion practices, thesubject of warehousing of domain names by registrars was raised. Three specificmodes of warehousing were identified:
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 domainname.
The registrant purchases the domain name through fraud and the registrar assumes registration of the name to resell in order to minimize losses.
The registrar registers the domain in its own name outright.
The task force believes that its current set of recommendations dealswith the first scenario described above. The other scenarios are not clearlysubject to the task force’s terms of reference, and have not been fully exploredby 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.
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 providegreater 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. Thetask force believes that credible enforcement mechanisms are an importantcomponent of the success of its recommendations and considered making specificenforcement 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 existingelements 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, lesserinfractions might be considered type “B” violations, with less severe penaltiesthan more serious type “A” violations.)
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 RegistryRegistrar 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 allof 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 requiresome enforcement by registries. The recommendations are expected to havelow technical impact and cost, with a high level of acceptance. The taskforce believes that all of its recommendations can be implemented within180 days of their adoptions.
The task force’s recommendation that registrars be required to deletedomain names by the end of the relevant Renewal Grace Period should providegreater certainty about the treatment of their domain names, but may resultin less time to renew the name in some cases. The recommendation to require conspicuous posting of deletion and auto-renewal policies, both at the timeof 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 theredemption of a name deleted following a complaint on WHOIS data accuracymay make the redemption of such names a slightly more complicated propositionand 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.
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 nameis likely to expire during the course of the complaint. The task force has begun notifying UDRP providers of its proposed changes. Based on initialfeedback from the providers, it appears that some providers may already beproviding this notification, and that the requirement is unlikely to be burdensome.
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/ and http://www.dnso.org/clubpublic/nc-deletes/Arc01/ .
Task force members have circulated draft recommendations to theirvarious constituencies.
The draft recommendations and status of the task force’s work hasbeen communicated to the GNSO Council.
UDRP dispute resolution providers have been contacted to assess the impact of Recommendation 3.2.1.
Additionally, the initial report of the task force was published on the ICANN and GNSO web sites 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 redemption grace perioddomain name renewals, calling the redemption fee "the worst case of consumergouging I have ever seen in my life."
(2) "Krishna" writes to ask why the redemption grace period pricing was put into effect without priornotice to domain name registrants so they could "renew the domain name ontime before the Redemption period comes into picture."
(3) Marcia Wells also writes to complain about the high pricing on redemption grace period renewals, calling thefees "exploitative and predatory."
TASK FORCE COMMENT ON 1, 2, and 3:
Comments on the fee to recover domain names during the Redemption GracePeriod 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 willforward the comments above to the ICANN General Counsel, the GNSO's RegistrarsConstituency, 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 registrantsa means to expressly disavow an intent to renew, thereby allowing the domainname to be canceled early or deleted promptly upon expiration; (b) ensuringthat registrars inform registrants of the fee they intend to charge for renewalsduring the redemption grace period; and (c) requiring registrars to providetimely and repeated notices to domain name registrants of the impending expirationof 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 containedin Ms. Wells' posts and took account of them in its deliberations and revisionsto the Task Force document. Specifically, Ms. Wells' suggestion that "registrarsinform registrants of the fee they intend to charge for renewals during theredemption grace period" is now included in the proposed recommendation.While the suggestion that registrars provide "timely and repeated noticesto 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 leasttwo 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 deletedwithin the forty-five days following its expiration. He proposes a uniformpolicy 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 earlyin its deliberations. At its initial meetings, members of the Task Forceappointed from constituencies composed of users raised the same issue asMr. Younger. The registrars, however, made the point that given their variousbusiness models, some flexibility is needed during this grace period. Forexample, registries bill the registrars for a renewed domain promptly onits renewal date and then credit the renewal fee back if the domain nameis deleted within forty-five (45) days. While some registrars are willingand financially able to front the registry fee on behalf of a domain nameregistrant, not all registrars are in the same position. The registrars expressedthe strong concern that requiring them to bear the registry fee would placean undue hardship on smaller registrars. Based primarily on this concern,the Task Force compromised on the discretionary window of 45 days, whichwill provide some uniformity and certainty while also allowing those registrarswho wish to do so to avoid the registry renewal fee for domain names notrenewed by the registrant. In order to provide registrants with anunderstanding of their registrar's deletion policies, however, the task forcehas 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 negativeeffect on domain name registrants who oftentimes benefit from registrar graceperiods longer than 45 days. He suggests that the new rules would benefitprospective registrants of expiring domain names at the expense of existingregistrants, which is the wrong emphasis.
TASK FORCE COMMENT ON 6:
During its deliberations, the Task Force, including those membersappointed from constituencies comprised of users and registrants, took accountof the concerns raised by Network Solutions. On balance, the Task Force membersbelieved that the greater certainty and uniformity required by the recommendedrules outweighs the benefits described in Mr. Cute's contribution.
7.1 Initial Report
The task force's initial report was voted upon prior to itspublication. The report received supermajority approval from the membersof 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.
7.2 FINAL REPORT
This report was voted on prior to 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.
Add Grace Period : A period of time (generally five days)provided by the registry after a domain name’s initial registration in whichit can be deleted, resulting in a credit for the cost of the registrationto the registrar.
Auto-renew Grace Period : A period of time (generallyforty-five days) provided by the registry after a domain name is automaticallyrenewed in which it can be deleted, resulting in a credit for the cost ofthe auto-renewal to the registrar.
Renew Grace Period : A period of time (generally fivedays) provided by the registry after a domain name is explicitly renewedby the registrar in which the name can be deleted, resulting in a creditfor the cost of the renewal to the registrar.
Transfer Grace Period : A period of time (generally fivedays) provided by the registry after a domain name is transferred betweenregistrars 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 life cycle of a typical domainname that is registered for a single year, and never renewed by the registrant.
As this timeline demonstrates, when the domain “expires” a yearafter being registered, it is automatically renewed by the registry. At thispoint it enters the Auto-renew Grace Period, during which the registrar candelete the name and receive a full credit for the cost of the renewal. Bythe end of the Auto-renew Grace Period, if the domain name has not beenrenewed by the registrant, the registrar must submit a deletion requestfor 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 permanentlyremoved from the registry database and made a part of the pool of availablenames. (The Redemption Grace Period does not apply to names deleted withinthe Add Grace Period, which extends through the first five days after thedomain’s initial registration.)