Draft Expired Registration Recovery Policy
1. Registrant at Expiration
1.1. A Registrant at Expiration ("RAE") is defined as the registered name holder who is eligible to renew a domain name registration immediately prior to its expiration.
1.2. If a domain name registration is modified pursuant to a term of the registration agreement authorizing the modification of registration data in relation to the expiration of the registration the RAE is the entity or individual identified as the registered name holder immediately prior to that modification. In all other cases of transfers of gTLD registrations between registrants, the registered name holder who receives the registration is the RAE.
2. Renewal of Registrations
2.1. Expiration Reminder Notices
2.1.1. Prior to the expiration of any gTLD registration, registrars must notify the registered name holder of the expiration at least two times. One of these notices must be sent approximately one month prior to expiration and one must be sent approximately one week prior to expiration. In the event the registration is transferred to a different registered name holder pursuant to a provision of the registration agreement and in relation to the expiration of the registration (as described in paragraph 1.2) these renewal notices must be transmitted instead to the RAE. Nothing in this policy is intended to preclude registrars from sending
additional notices, provided that at least two required notices are sent at the required times.
2.1.2. If a registration is not renewed by the RAE or deleted by the registrar, within five days after the expiration of the registration, the registrar must transmit at least one additional expiration notice to the RAE that includes instructions for renewing the registration.
2.1.3. Notifications of expiration may be presented in one or more languages, but must be provided in the language of the registration agreement and must be communicated in a manner, such as by email, that does not require affirmative action to receive the notification.
2.2. Post-Expiration Renewal
2.2.1. Subject to applicable consensus policies and provisions of the Registrar Accreditation Agreement ("RAA"), registrars may delete registrations at any time after they expire.
2.2.2. For registrations deleted within eight days of expiration: The existing DNS resolution path specified by the RAE must be interrupted by the registrar from expiration of the registration until its deletion, to the extent the applicable registry permits such interruptions.
2.2.3. For registrations deleted eight or more days after expiration: For the last eight consecutive days (after expiration) that the registration is renewable by the RAE, the existing DNS resolution path specified by the RAE must be interrupted by the registrar to the extent that the applicable registry permits such interruptions.
2.2.4. In interrupting the DNS resolution path of the registration, if the registrar directs web traffic to the domain name to a web page while the registration is still renewable by the RAE, that web page must conspicuously indicate that the domain name registration is expired and provide renewal instructions.
2.2.5. Beginning at the time of expiration and through the DNS resolution interruption period described in paragraphs 2.2.2 and 2.2.3, the RAE must be permitted by the registrar to renew the expired registration.
2.2.6. Upon renewal of the registration by the RAE, the registrar must restore the DNS resolution path set by the RAE immediately or as soon as is commercially reasonable.
3. Redemption Grace Period
3.1. With the exception of sponsored gTLD registries, all gTLD registries must offer a Redemption Grace Period ("RGP") of 30 days immediately following the deletion of a registration, during which time the deleted registration may be restored at the request of the RAE by the registrar that deleted it. Registrations deleted during a registry's add- grace period, if applicable, should not be subject to the RGP.
3.2. During the Redemption Grace Period, the registry must disable DNS resolution and prohibit attempted transfers of the registration. ICANN-approved bulk transfers and permitted partial bulk transfers are not subject to the prohibition of attempted transfers. The registry must also clearly indicate in its Whois result for the registration that it is in its Redemption Grace Period.
3.3. Registrars must permit the RAE to redeem a deleted registration during RGP (if RGP is offered by the respective registry).
4. Notice to Registrants of Fees and Procedures
4.1. Registrars must make their renewal fees, post-expiration renewal fees (if different), and redemption/restore fees reasonably available to registered name holders and prospective registered name holders at the time of registration of a gTLD name.
4.1.1. At a minimum, these fees must be clearly displayed on the registrar's website and a link to these fees must be included in the registrar's registration agreements. Registrars who do not offer or provide registrar services through a website must include the fees in their registration agreements.
4.1.2. Additionally, registrars must ensure that these fees are displayed on their resellers' websites.
4.2. Registrars must describe on their websites (if used) the methods used to deliver pre- and post-expiration notifications described in section 2 above.
4.2.1. This description should generally include communications channels/media that will be used and identification of the point of contact to which the notices will be transmitted (e.g., email to registered name holder, telephone call to administrative contact, postal mail to customer, etc.).
4.2.2. Registrars' registration agreements must include either a similar description of its notification methods or a link to the applicable page(s) on its website where this information is available.
4.2.3. Additionally, registrars must ensure that these communication methods are described on their resellers' websites.
4.3. In the event ICANN publishes registrant education materials addressing proper stewardship of domain names and renewal and redemption of gTLD registrations online, registrars must, after reasonable notice from ICANN, make this material (or similar material adapted by the registrar to its specific practices) available to registered name holders by:
4.3.1. including a link to this material in a communication sent to the registered name holder immediately following completion of the registration transaction and in all subsequent Whois data accuracy reminder notices, such as the annual notices required by the Whois Data Reminder Policy <http://www.icann.org/resources/registrars/consensus-policies/wdrp> ; and
4.3.2. displaying a link to this material on the websites through which registrations are offered, in a manner and location that is at least as clear and conspicuous as links to other documents and policies that must be posted by the registrar pursuant to its registrar accreditation agreement and incorporated consensus policies.
Introduction and Background:
At the request of ICANN's At-Large Advisory Committee, on 5 December 2008, ICANN published an Issues Report <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf> on the topic of Post-Expiration Domain Name Recovery. The Generic Names Supporting Organization Council ("GNSO") initiated a Policy Development Process in May 2009, which resulted in the submission of several policy and process recommendations <http://gnso.icann.org/en/resolutions/#201107> to the ICANN Board of Directors.
The ICANN Board approved the recommendations on 28 October 2011 <http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5>, directing staff to implement this policy.
The Expired Registration Recovery Policy is intended to help align registrant expectations with registrar practices by establishing certain minimum communications requirements, making renewal and redemption of registrations uniformly available in prescribed circumstances, and through the creation and promotion of registrant educational materials.
The Expired Registration Recovery Policy has been developed in consultation with an Implementation Review Team convened by the GNSO to ensure that the policy meets the letter and intent of the policy recommendations approved by the GNSO and adopted by the ICANN Board.
All registrars and registries are required to comply with this policy beginning .
Expiration Reminder Notices:
The policy recommendations by the GNSO recognize that some flexibility is required in the timing of pre-expiration renewal notices. As such, if the notices required to be sent approximately one month and one week prior to expiration described in
paragraph 2.1.1 are transmitted between 26-35 days and between 4-10 days prior to expiration, respectively, this would be considered compliant with the policy.
Paragraph 2.2.4 of the policy explains that registrars must include an expiration notice and renewal instructions if the registrar directs web traffic to the domain name to a web page while it is renewable by the RAE. To be clear, this requirement applies at any time during which the registration is renewable by the RAE, not just during the eight-consecutive-day period described in paragraphs 2.2.2 and 2.2.3. The renewal instructions required by this section need not be elaborate and could simply direct the RAE to the appropriate place on the registrar's website.
Paragraph 2.2.6 requires that registrars restore the DNS resolution path previously set by the
RAE immediately or within a commercially reasonable amount of time. The term "commercially reasonable" is intended in this instance to allow, for example, for situations in which manual intervention is required to restore the DNS resolution path or where a registrar cannot immediately restore the DNS resolution path because the post-expiration renewal occurred on a holiday or other non-business day.
Suggested Best Practices:
The GNSO recommends the following best practices for registrars:
If the post-expiration notifications described in paragraph 2.1.2 are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by post-expiration actions (such as an interruption of DNS resolution, as described in paragraphs 2.2.2 and 2.2.3), post-expiration notifications should be sent to some other contact point associated with the registered name holder if one exists.
Registrars should advise registered name holders to provide a secondary email point of contact that is not associated with the domain name itself so that in case of expiration, reminders can be delivered to this secondary email point of contact.
The notification method explanation required by paragraph 4.2 should include the registrar's email address from which notification messages are sent and a suggestion that registered name holders save this email address as a 'safe sender' to avoid notification emails being blocked by spam filter software.