[ga] ICANN Opens Public Comment Period for Draft/Interim Terminated Registrar Transition Procedure

["GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>]

[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@xxxxxxxxx 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