Transfer Task Force Implementation Analysis by Chuck Gomes

15 January 2003

This document provides my personal analysis of the implementation impact of the 29 recommendations made by the GNSO Transfer Task Force with regard to the registrar transfer policy for gTLD registries and registrars.

Over the past several months I have specifically engaged in dialog with registrars for the express purpose of trying to see if there is a way to facilitate the process of finding a solution to the domain name transfer problems that registrants, registrars and registries have been experiencing for nearly two years. My analysis primarily comes from the information I gathered from registrars.

Fundamental Assumption Underlying the Analysis

It is critical that there be strong support from registrars for a new transfer policy for the following reasons:

• Registrars will have to directly implement the policy.
• Without support from a strong majority of registrars, it is not possible to claim consensus because, in my opinion, registrars are the most heavily impacted constituency.
• The existing Registry Registrar Agreements (RRAs) will have to be amended.
• Registrars will have to be willing to execute the amended RRAs; this is especially critical if clear consensus is not demonstrated.
• If a new transfer policy is imposed on registrars without their support, the success of the new policy will likely be limited.

The emphasis on registrars should in no way be interpreted to mean neither that registrars are the only impacted parties nor that other parties are not significant. Without registrants, registrars and registries are not needed. Moreover, it is my belief that any policy that does not serve the interest of registrants is bad for registrars and registries. With regard to registries, it is quite likely that they will assume greater responsibilities when a new policy is implemented, so their support is essential.

Organization of the Analysis

The analysis is mostly contained in two tables. In Table 1 I provide the following for each of the recommendations made by the GNSO Transfer Task Force: 1) what I believe to be the level of impact for some key implementation factors; 2) what level of support can be anticipated from registrars; and 3) my personal recommendation with regard to what steps should happen to facilitate a successful implementation. In cases where my personal recommendation involves alternative or expanded approaches, a detailed explanation is given in Table 2.

Because the alternative recommendations in Table 2 are correlated where possible with the 29 recommendations of the task force, it is difficult to visualize the full impact of the recommendations in Table 2. Consequently, a summary of what the transfer process might look like if the alternative recommendations were implemented is provided after Table 2.

Table Abbreviations

Table Headings

# The number of the recommendation made by the GNSO Transfer Task Force (1-29); note some NEW items are added after 29.

Cost What is the cost impact if the recommendation is implemented? (high/medium/low/?)

Enf Is the recommendation enforceable if it is implemented? (yes/no/?)

Feas Can the recommendation reasonably be implemented from a process point of view? (yes/no/?)

Supp What is the anticipated level of support for the recommendation from registrars? (high/medium/low/?)

Tech Can the recommendation be reasonably implemented from a technical point of view? (yes/no/?)

User Would the recommendation contribute to a good user experience? (yes/no/?)

Legend

High High impact or support + Positive impact 0 No impact / easily doable

Med Medium impact or support - Negative impact * See Table 2

Low Low impact or support ? Unknown N/A Not applicable

Table 1 Implementation Analysis
		Level of Impact if Implemented
#	Description	Cost	Enf	Feas	Tech	User	Supp	Personal Recommendation	*
1	Min. standards / ICANN policies	Low	Yes	Yes	Yes	Yes	High	Keep it as is
2	Existing protocols & standards	Low	Yes	Yes	Yes	Yes	High	Keep it as is
3	Email address for registrars & registry	Low	Yes	Yes	Yes	Yes	High	Minor modification	*
4	Clear & concise processes	Low	Yes	Yes	Yes	Yes	High	See Table 2, #17.
5	Registrant informed of transfer process	Low	No	No	Yes	Yes	?	Reword	*
6	For EPP, registrar must provide registrant unique ‘auth-info code’ within 72 hours.	Low	Yes	Yes	Yes	Yes	?	See Table 2, #23.
7	For EPP, ease of getting ‘auth code’ must not be any more difficult for use with transfers than for other transactions.	Low	Yes	Yes	Yes	Yes	?	Keep as is
8	Standardized form	Low	Yes	Yes	Yes	Yes	High	Expand – see Table 2, #17	*
9	Gaining registrar is solely responsible for validating transfer request but losing registrar may do its own validation.	Low	Yes	Yes	Yes	Yes	Med	Modify	*
10	Lack of response from the registrant to the losing registrar is not an acceptable reason for denying a transfer.	N/A	Yes	Yes	Yes	?	Med	Modify	*
11	If losing registrar elects to independently validate the transfer request, it must be done consistently with transfer policy standards.	N/A	Yes	Yes	Yes	Yes	Med	Modify	*
12	The gaining registrar will be given the benefit of doubt regarding validation of the transfer request. Losing registrar may file dispute.	N/A	Yes	Yes	N/A	Yes	Med	Expand on enforcement	*
13	Losing registrar may file a dispute.	Med	Yes	Yes	Yes	Yes	High	Add more detail	*
14	Transfer processes must not be used as a means to secure payment.	N/A	?	Yes	Yes	Yes	?	Modify	*
15	For EPP, the losing registrar must not refuse to issue an ‘auth code’ because of lack of payment.	N/A	Yes	Yes	Yes	Yes	?
16	Only the Admin Contact or Registrant as listed in the losing registrar’s Whois may authorize transfers. The Registrant’s authority overrules the Admin Contact in case of a dispute.	N/A	Yes	Yes	Yes	?	High	Keep it as it is
17	The gaining registrar must use a standardized form to validate the transfer.	Low	Yes	Yes	Yes	Yes	High	Expand use of standardized form	*
18	ICANN should facilitate the development of the standardized form. Form must be usable in printed or electronic (email/web) format.	Low	Yes	Yes	Yes	Yes	High	Modify	*
19	A printed copy of the completed standardized form is acceptable if signed by the registrant or admin contact and accompanied by the applicable Whois information.	Med	Yes	Yes	Yes	Yes	?
19a	If a printed form is used, registrar is responsible for validating identity.	Med	Yes	Yes	Yes	?	?
19b	Acceptable forms of identity for printed forms include: notarized statement, valid driver’s license, passport, articles of incorporation, military ID, state or government issued ID, birth certificate.	Med	Yes	Yes	Yes	?	?
19c	In case of electronic authentication, acceptable forms of identity include electronic signature in conformance with national legislation or email address of admin contact or registrant as recorded in losing registrar’s Whois.	Low	Yes	Yes	Yes	Yes	?
20	Gaining registrars must maintain copies of the Standardized Form of Authorization.	Low	Yes	Yes	Yes	Yes	High	Expand	*
21	Gaining registrar must allow inspection of evidence used for verification by losing registrar, ICANN, dispute provider, registry.	N/A	Yes	Yes	Yes	Yes	High	Add more detail	*
22	Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The losing registrar retains the right to inspect evidence at all times consistent with existing document retention requirements.	Med	Yes	Yes	Yes	Yes	?	Modify	*
23	The Gaining Registrar must fulfill the Losing Registrar’s request for evidence within three business days.	?	Yes	?	?	Yes	?	Expand	*
24	A Losing Registrar may deny a transfer request only in the following instances: a) evidence of fraud; b) UDRP action; c) Court order; d) reasonable dispute over the identity of the Registrant or Administrative Contact; e) No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into “Registrar Hold” status by the Losing Registrar prior to the denial of transfer; f) Express written objection from the Registrant or Administrative contact. (e.g. – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means).	N/A	Yes	Yes	Yes	Yes	Med	See Table 2, 24 Add.	*
25	Instances when the Losing Registrar may not deny a transfer include, but are not limited to: a) Nonpayment for a pending or future registration period; b) No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (e.g., email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means); c) Domain name in Registrar Lock Status unless the Registrant is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request; d) Domain name registration period time constraints other than during the first 60 days of initial registration; e) General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.	N/A	Yes	Yes	Yes	Yes	Med	Some registrars think that this list is unnecessary if a finite list is provided for allowable reasons.	*
26	There must be a dispute resolution process with these requirements: a) Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both; b) the process must be limited in scope to issues arising out of inter-Registrar domain name transfers; c) the process must be solely initiated by a Registrar; d) appeal of rulings is allowed, but is limited in number; e) the policy must include specific obligations for all parties to