[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/en/announcements/announcement-2-06jun08-en.htm ICANN Opens Public Comment Period for Draft/Interim Terminated Registrar Transition Procedure 6 June 2008 0.1 In consultation with the community, ICANN has developed this draft/interim procedure for managing transition of gTLD domain name registrations from a de-accredited registrar to an accredited gaining registrar. This process is currently being used by ICANN staff to facilitate transition of gTLD registrations of de-accredited registrars and is being posted until 7 July 2008 for public comment for further refinement. Along with ICANN’s Registrar Data Escrow, Registry Failover, and Contractual Compliance programs, this procedure is intended to enhance protection of registrants. A graphical representation of this procedure is also posted at http://www.icann.org/registrars/drt-procedure-flowchart-06jun08.pdf [PDF, 21K]. 0.2 Comments regarding this draft/interim procedure may be posted by email to dtr-procedure-2008@icann.org until 7 July 2008 and viewed at http://forum.icann.org/lists/dtr-procedure-2008/. Following conclusion of this public comment period, the resulting procedure will be revised as appropriate and submitted to the ICANN Board of Directors for adoption and fully implemented upon approval. 1. Introduction 1.1 Upon the termination or expiration of a registrar’s Registrar Accreditation Agreement (RAA), the registrations sponsored by the de-accredited registrar must be transitioned to a competent accredited registrar. In the past, such transitions have generally been accomplished through a “bulk transfer,” as described in Part B of the Inter-Registrar Transfer Policy <http://www.icann.org/transfers/policy-12jul04.htm>, and have required the cooperation of the “losing” (de-accredited) registrar because the losing registrar was the sole source of registration data necessary to identify registration rights in the affected domain names. 1.2 With the implementation of the Registrar Data Escrow (RDE) program <http://www.icann.org/announcements/announcement-2-09nov07.htm> ICANN will have greater ability to enable a transition of names, even where the de-accredited registrar is not cooperative in a bulk transfer. Although the RDE program is currently still being implemented across all registrars, this process is intended to be used by ICANN to facilitate the transition of registrations of terminated registrars whether the necessary registration data is immediately available to ICANN or not. 1.3 This draft/interim process is currently being used by ICANN staff in facilitating the transition of registrations from two recently de-accredited registrars. It was developed from learning by staff in previous registrar de-accreditations (including both voluntary and involuntary terminations) and with input provided by the community at the Registrar Termination workshop hosted in Delhi, India at the February 2008 ICANN meeting. (Transcript, presentation slides, and summary of participant comments available at: http://delhi.icann.org/node/53.) Through the workshop in Delhi, community members provided several well-considered ideas for addressing particular scenarios that could be encountered upon the de-accreditation of a registrar. Although many of suggestions have been incorporated into this draft/interim procedure, some of the suggestions are not currently implementable due to existing policy limitations or a need for further development of long-term solutions. It is anticipated that, after this procedure has been finalized and approved, it will be periodically reevaluated and adapted as warranted by ICANN’s experience with its use. 2. Draft/Interim Terminated Registrar Transition Procedure 2.1 The Terminated Registrar Transition Procedure generally does not become operative until a registrar’s RAA has been finally terminated because the RAA gives registrars certain rights to, for example, cure a breach after ICANN issues a notice of breach and contest a termination through arbitration. Nevertheless, before the procedure is initiated, ICANN will have taken steps to help ensure as smooth a transition as possible, by conducting an assessment of the availability of registration data (either through the registrar data escrow program or otherwise) and working with registries to ensure registrations are not deleted due to the actions or inaction of a de-accredited registrar. 2.2 Under Part B of the Inter-Registrar Transfer Policy (the “Policy”), the sponsorship of all gTLD registrations of one registrar may be transferred in bulk to another registrar (a “bulk transfer”) where a registrar is no longer accredited as a registrar and ICANN approves the bulk transfer. Under the Policy, the bulk transfer can only be effected where the gaining registrar is accredited and operational (with a registry-registrar agreement in force) for the respective TLD(s) and where ICANN certifies to the registry operator that “the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or imminent business failure of a Registrar.” 3. Voluntary Bulk Transfers 3.1 When a registrar’s RAA is terminated or not renewed, it may often be in the best interests of registrants and at-large users of the Internet for ICANN to permit the de-accredited registrar to designate a “gaining registrar” to receive a bulk transfer of its names. Such a transition could help minimize customer confusion while ensuring that the gaining registrar receives as much customer and registration data from the losing registrar as possible. Moreover, a voluntary transition generally involves the least amount of friction. 3.2 In some cases, however, a voluntary transition is not possible or practical because either the losing registrar is uncooperative or because its designation of a gaining registrar would not serve the community interest. By way of example, a proposed transfer might not be in the community’s interest if the gaining registrar is not in good standing with its ICANN obligations or where the losing registrar appears to be using the termination of its RAA as a vehicle for avoiding its obligations to ICANN or its customers by transferring the registrations to an affiliated registrar without satisfying the outstanding obligations. 3.3 While recognizing the potential benefits of a voluntary bulk transfer, the Terminated Registrar Transition Procedure employs a balancing of interests in the decision to approve or not approve a proposed voluntary bulk transfer. The considerations in this decision include, without limitation: whether the gaining registrar is in good-standing with its ICANN obligations, whether the gaining registrar is operational and experienced in managing the affected TLDs, whether there is a relationship between the losing registrar and gaining registrar that could allow abuse or gaming of the proposed bulk transfer, whether the losing registrar would continue to manage the registrations as a reseller for the gaining registrar or otherwise be involved in the management of the names and customers, and whether, as a result of the bulk transfer, obligations to ICANN and the losing registrar’s customers are likely to be satisfied. 3.4 In weighing all considerations, ICANN may either approve the voluntary bulk transfer by announcing the approval to the registrars and involved registries, or deny the requested transfer, by giving the losing registrar another opportunity to name a gaining registrar or proceeding to designate a gaining registrar without deference to the losing registrar’s suggestion. If ICANN approves the voluntary transfer, the approval could be conditioned on satisfaction of certain conditions (e.g., payment of outstanding ICANN invoices or registry fees). Failure by the registrars to satisfy the approval condition(s) could result in the withdrawal of ICANN’s approval of the transfer, leaving ICANN to select a gaining registrar itself. 4. Involuntary Bulk Transfers 4.1 The RAA provides ICANN a license to use or transfer registrar data to provide registrar services upon termination of a registrar’s accreditation agreement. Where a de-accredited registrar does not cooperate with ICANN’s transition efforts or ICANN does not approve the proposed gaining registrar in a voluntary bulk transfer, ICANN must select a gaining registrar to manage the orphaned registrations. During the terminated registrar workshop in Delhi, some participants suggested options for transition that would parcel out registrations across multiple registrars. Although such alternatives might be necessary in the event no one registrar is operational in all affected TLDs or when other challenges make a single bulk transfer impractical, one bulk transfer is the preferred course of action, to avoid potentially confusing registrants and to minimize complications in the transfer process. 5. Availability of Registration Data 5.1 In order to effect a transfer of registrations from one registrar to another, the gaining registrar must be provided with at least basic registration data in order to be able to identify registrants and process registration updates, such as renewals, contact changes, and nameserver updates. Outside the RDE program, a handful of tools are available that would help permit identification of registrants where a de-accredited registrar does not cooperate with a bulk transfer. 5.2 When a voluntary bulk transfer is not possible, ICANN must assess the extent to which registration data is available to it (or more accurately, to the potential gaining registrar). Because such data could come from a variety of sources, its completeness and integrity will need to be analyzed by ICANN to determine whether to proceed to selection of a gaining registrar or whether other courses of action must be considered. 5.3 If registration data is unavailable or deemed unreliable, ICANN may: 5.3.1 initiate litigation or arbitration to obtain registration data to facilitate a transfer through this procedure; 5.3.2attempt to collect Whois / registration data from non-authoritative sources; 5.3.3 allow the de-accredited registrar to continue limited operations to be able to service existing customer needs (by processing renewals and updates but not new registrations, for example); 5.3.4 negotiate an arrangement with the de-accredited registrar to obtain its cooperation with a bulk transfer; 5.3.5 allow registrations to expire on their expiration date; 5.3.6 instruct registries to delete names (in limited and unique situations, such as, for example, where it appears the names are all test-registrations with no beneficial owner); or 5.3.7 pursue more than one of these potential options or a different alternative altogether. 5.4 If ICANN is satisfied with the availability and quality of registration data, it will proceed to the Gaining Registrar Selection Process. 6. Gaining Registrar Selection Process 6.1 The first step in the selection of a gaining registrar by ICANN is a solicitation of statements of interest through the posting of a Request for Information (RFI) at http://www.icann.org and distribution through the Registrar Constituency. The RFI will request that applicants submit an application within a time frame of approximately one week. The responses should include details about the applicant-registrar’s qualifications, such as ability to technically manage the transition of registrations and capacity to provide competent customer service to new registrants. (An example of an RFI recently posted pursuant to this procedure is available at: http://www.icann.org/en/announcements/announcement-06jun08-en.htm.) 6.2 In reviewing the RFI responses, ICANN will determine whether a formal Request for Proposals (RFP) or auction process is necessary to select a gaining registrar. This determination is largely based on the feasibility of negotiating with the registrars who responded to the RFI. That is, if only a few statements of interest were received or if all but a few were apparently unqualified to act as gaining registrar, ICANN may elect to engage the qualified bidders in direct negotiations to select the gaining registrar. If, however, direct negotiations are impractical or if no statements of interest are received, ICANN may initiate an RFP or auction as appropriate. Regardless of whether an RFI, RFP, or auction is utilized, the gaining registrar selection criteria are the same. The gaining registrar should: 6.2.1 be able to quickly transition registrations and customer information into its registrar operations to be able to provide timely service to the newly acquired registrants; 6.2.2 be able to demonstrate prior experience in managing a portfolio of registrations/customers comparable to those of the de-accredited registrar; 6.2.3 have available sufficient customer service staff to timely respond to customer service requests during and following the bulk transfer; 6.2.4 be accredited and operational in all applicable gTLDs and in good-standing under its RAA; 6.2.5 have experience in and knowledge of bulk transfer procedures; 6.2.6 have documented procedures in place to resolve potential disputes of domain name control or registration rights; 6.2.7 be experienced as a customer-facing / “retail” registrar business (if applicable); 6.2.8 have experience in managing second-level internationalized domain names (if applicable); 6.2.9 be able and willing to provide ICANN with regular status reports; and 6.2.10 provide adequate compensation for the portfolio of customers/registrations. 6.3 While these criteria will guide ICANN’s selection of a gaining registrar, they are not intended as inflexible rules. That is, an applicant who meets most of the criteria may nevertheless be considered to be the gaining registrar, and similarly, unique circumstances may require consideration of additional factors not listed here. 7. Alternatives When No Gaining Registrar is Identified 7.1 If no qualified gaining registrar can be located through the Gaining Registrar Selection Process, ICANN might: 7.1.1 temporarily operate the registrar through its “terminated registrar” registry account and establish a deadline by which all registrants must transfer their names out; 7.1.2 operate the terminated registrar indefinitely by providing unlocking and auth-code services to registrants; 7.1.3 retain the services of a registrar backend service (or backend and customer service) provider either temporarily or indefinitely; 7.1.4 compensate a registrar to receive the bulk transfer; 7.1.5 offer a temporary accreditation to potential gaining registrars; or 7.1.6 allow names to be deleted upon expiration. 7.2 These alternatives reflect, to varying degrees, handling of a “worst-case” scenario. It is expected that, in nearly every de-accreditation, the customer portfolio of the de-accredited registrar will have some value, such that a gaining registrar can be identified through the Gaining Registrar Selection Process described above. 8. Ongoing Process Development 8.1 ICANN recognizes that this procedure may not address all possible scenarios of registrar de-accreditation or other RAA terminations. Moreover, viable alternatives to the procedures described in this document may be available in the future, pending possible policy development or further coordination between relevant stakeholders and upon full implementation of the registrar data escrow program. For these reasons ICANN staff will periodically review the effectiveness of this Terminated Registrar Transition Procedure and implement modifications as necessary to ensure it remains a useful and efficient tool in the protection of registrants. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org