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 the dispute to provide documentation to the dispute resolution provider; f) the Registrar filing a dispute must pay the cost of filing the dispute and the party that “loses” the dispute must pay the cost of administering the dispute resolution and reimburse the filing Registrar for the filing fees if applicable; and g) the third party dispute resolution service or Registry must be able to direct the appropriate Registry or Registrar to return a domain name to whatever state the dispute resolution provider deems appropriate based on the facts presented during the proceeding.	Med	Yes	Yes	Yes	?	Med	See the add-on recommendations for #26 in Table 2.	*
27	Registries must implement a “Transfer Undo” command that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document.	?	Yes	Yes	Yes	Yes	?
28	The implementation and execution of these recommendations should be monitored by the GNSO.	?	?	?	Yes	?	?
28a	ICANN Staff should analyze and report to the GNSO Council at three, six and twelve month intervals after implementation with the goal of determining: i) How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants; ii) Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages; iii) The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.	?	Yes	Yes	Yes	Yes	?
28b	The GNSO Council may instruct the staff to: i) continue bi-annual reviews in a manner consistent with the aforementioned requirements; or ii) report again to the Council in an additional twelve-month time frame.	?	?	Yes	Yes	Yes	?
29	Guidance. The Task Force has completed three supplementary documents (“Exhibit A, Reference Implementation”, “Exhibit B, Proposed Dispute Resolution Model” and “Exhibit C, Standardized Definitions”) in support of these recommendations. These exhibits are submitted as guidance to those that will be required to craft and/or implement the policies adopted as a result of these recommendations.	?	?	?	?	?	?

Table 2 Personal Recommendations
#	Recommended Requirement	Justification/Comments
1	No change.
2	No change.
3	Registrars should provide a unique and private email address for use only by other registrars and the registry: This email is for transfer issues only. The address should be managed to ensure messages are received by someone who can respond to the transfer issue. A timeframe should be required for responses such as this: “commercially reasonable” but not to exceed XX time period. XX time period will be determined within 3 months of implementation.	To facilitate timely and effective communications between registrars regarding the transfer process, a unique and private address should avoid problems that might occur when mixed with other email traffic.
4	Refer to # 17.
5	Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.	The TF recommendation says, “The Registrant must be informed of . . .” It is not always possible to ensure that a registrant is informed so this part of the TF recommendation could not reasonably be implemented or enforced. The transfer process could be included in the terms and conditions of the registration agreement.
6	See #23.
7	No change.
8	See #17.
9	Only losing or gaining registrar should authenticate the transfer request, not both. In cases where the losing registrar chooses to do the authentication, it would be appropriate for the gaining registrar to explain the process to the party requesting the transfer with information about the admin contact to whom the authentication message will be sent. There will be a centrally accessible matrix (e.g., at the registry) that indicates for each gaining registrar/losing registrar pair, which registrar will be responsible for final authentication.
10	?	Some registrars are not supportive of the TF recommendation that lack of response from the registrant cannot be used as a reason for denying a transfer. This is because in the past some gaining registrars have not been rigorous in obtaining authority from the registrant, and there has been no systematic auditing of the gaining registrars processes by ICANN or the Registries. Other registrars are concerned that losing registrars make little effort to obtain confirmation of a transfer, and instead concentrate on marketing to the registrant to get them to change their mind. This in turn has led to the communications from the losing registrar being either ignored or misinterpreted.
11	Refer to # 11 Adds and #17.
11 Add	Authentication communications with registrants regarding the transfer process should not include any information other than that contained in the standardized form.	There is some disagreement over this requirement but support probably exceeds opposition.
11 Add	Authentication communications with registrants should be sent as soon as operationally possible but must be sent not later than 24 hours.	The `24-hour’ time limit may need to be revisited, especially with smaller registrars and it will undoubtedly be a factor of how long the ‘transfer pending’ period is. If however the period is extended to accommodate smaller registrars, the larger registrars should not be able to send marketing communications more than a time limit (say 1 hour) before the authentication message is sent out in response to the message from the registry.
12		Further work should be done on enforcement to ensure there is a mechanism to act quickly when a registrar is not following the transfer policy (e.g., the equivalent of some form of injunction) as well as the normal dispute resolution process (that may take weeks to resolve).
13	Either registrar should be able to file a dispute.
14	Transfer processes must not be used as a means to secure payment except for non-payment for previous registration period if transfer is requested after the expiration date, or non-payment of the current registration period, if transfer is requested before the expiration date.	Should be consistent with TF recommendation 24 (e).
15
16
17	All transfer process communications to registrants from losing and gaining registrars should be standardized. (Standardization to be determined and decided later.) English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied.	A recommended first step is to prepare a list of all transfer process communications that should be standardized.
18	Refer to # 17.	Whereas it seems perfectly okay for ICANN to facilitate development of standardized forms, the most critical factor is to ensure that registrars are key contributors to the development of standardized forms. Work is currently underway by some registrars in this regard.
19
19a
19b
19c
20	Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process.	It is important that all documentation that might be used to resolve disputes be maintained by registrars, not just standardized forms.
21	Both gaining and losing registrars should allow inspection of evidence by the other side.	This may be facilitated by extending the period available for a losing registrar to accept or reject a transfer, so that the losing registrar may check the processes of a gaining registrar.
22	Minimum, standardized documentation should be required of registrars for all transfer procedure steps for use in dispute resolution.
23	Losing and gaining registrars should be required to complete all specific transfer process steps within to-be-determined and specifically defined time periods.
24	?	24 d) is not included in CT principle #29: “reasonable dispute over the identity of the Registrant or Administrative Contact.” Also, the following condition is added in the TF recommendations: “. 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.”
24 Add	Add the following two allowable reasons for denying a transfer: A domain name is in lock status provided that the registrar provides a readily accessible and easy means for the registrant to remove the lock status. A domain name is in the first 60 days of an initial registration period.	After January 25, 2003, VGRS will be displaying the domain name status in Whois so registrars will be able to check to see if a name is in lock status before proceeding with a transfer; note also that this allowable reason is consistent with TF recommendation 25c. The second reason added is a repeat of an already existing contractual requirement but it is repeated here because the list of allowable reasons is said to be finite.
24 Add	There should be a finite list of allowable reasons for denying a transfer request with the understanding that procedures should be put into place to modify the list if registrars support any changes.	One key difference in this recommendation from the TF recommendations is that it calls for procedures to be put into place to allow modification of the finite list.
25	?	The following non-allowable reasons are included in the TF recommendations: 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.
25 Add	Certain non-allowable reasons for denying transfers should be identified, especially in cases where past behavior may need to change.	This list should be made after the allowable reasons are finalized.
26 Add	If the gaining registrar is responsible for transfer authentication and the losing registrar’s special Whois is not accessible for a to-be-specified time; this can be grounds to allow the transfer to occur in case of a dispute.	Boundaries on timeframe are needed. One thought is to add “In lieu of extenuating circumstances” to better define.
26 Add		With regard to 26 (f) the dispute resolution process only relates to whether a registrar has followed the transfer process. It cannot be used to resolve disputes between parties that both claim to be the registrant (e.g., if contact details are not maintained in the WHOIS). A registrar that files the dispute bears any costs associated with the dispute, if the other registrar has complied with the transfer process.
26 Add	Reword 26 c) as follows: Only registrars may initiate disputes. If registrants want to initiate a dispute, it must be done through a registrar. The registrar makes the decision as to whether to initiate a dispute.
26 Add	The registry is responsible for first level dispute resolution.	VGRS would prefer that a neutral 3rd party does this but it appears that it would be quite costly and therefore should be used at the appeal level only. VGRS is willing to perform this function for .com and .net transfer disputes under the condition that the revised policy provides explicit requirements that can be enforced objectively based on clearly measurable criteria. This is a recommendation that has significant cost impact on all registries so their concurrence is very important.
26 Add	There will be a non-judicial second-level dispute resolution process for appeals.	It should be noted that using a neutral 3^rd party for this could be fairly costly. A couple of the UDRP service providers have indicated that they would consider doing this. As just one example, admittedly for a different process, WIPO’s minimum charge for a UDRP dispute is $1500. More investigation of alternatives needs to be done on this.
26 Add	Email communications can be used for dispute resolution if the registry was bcc'd on the email message.  Bcc, not cc, is to be used to limit customer service emails being sent to the registry from entities other than registrars. Email communications sent in response to mail bcc'd to the registry can be used during the dispute resolution.  The registrar is encouraged to forward these messages to the registry as well.
27
28
28a
28b
29
New Whois	If Whois contact information is inaccurate, registrants should correct the information before a transfer may be initiated. Upon receiving any updates to Whois data elements from the Registered Name Holder, Registrar shall promptly update its database used to provide the public Whois access.
New Whois	Registrars should provide special, standardized Whois access, which may be separate from public Whois access, to other registrars and the registry solely for the purpose of transacting transfers.
New Whois	As the Special Whois is only accessible between registrars and registry and only for purposes of authenticating transfers, and as finding fair and flexible rules for defining query rate limits seems not possible, the Special Whois access must not be query rate limited and must be provided with the same treatment to all registrars. (Reminder: the Special Whois should have a common, unified output format between all registrars and therefore needs to be separate from the publicly available Whois)
New EPP	If some form of auth code is used, the same auth code must be used for the same domain name and the same gaining registrar.
New	Upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial.
New	The new process replaces the old process (i.e., a registrar can't use the new process and the old process as a follow up to restrict a transfer).	A new transfer policy needs to be written to replace the existing policy.
New	If registrant’s ISPs consistently block losing registrar’s emails, so that the losing registrar’s authentication cannot possibly reach registrants, the losing registrar loses the ability to be the authenticating party. In that case, Gaining Registrar must obtain authentication.
New ML	The registrar responsible for authorization shall be obligated to provide additional standardized local language for the mandatory English transfer notification by providing a reference, e.g. a link, to the standardized communication to registrant. The link will be at the beginning of the authorization message and allow the registrant to select from several translations of that message. The registrars will agree to the available translations.
Add	Prior to filing a transfer dispute, the filing registrar should first attempt to solve the issue with the other registrar in question through the email address noted in principle #1.
Add	Extend the current 5-day transfer pending period to a longer period.

If the GNSO Task Force recommendations were modified to include the recommendations contained in Table 2, it is my belief that there would be stronger support from registrars while at the same time ensuring the other factors of my analysis are also impacted in a favorable way. The resulting process is summarized below.

Modified RRP Transfer Process

If the losing registrar wants to authenticate transfers initiated from certain other registrars, it may do so provided it follows the requirements of the transfer policy. Registrars would be required to communicate their decisions to a central point such as the registry where a matrix would be compiled containing the authentication decisions for all registrars with all other registrars. This matrix would be accessible by all registrars.

The RRP transfer process would then follow these steps:

1. An unauthenticated party (Requestor) requests a transfer from a new registrar.

2. Gaining registrar :

a. Checks WHOIS to determine the registrar-of-record (Losing Registrar) for the domain name

b. Checks table maintained by registry to determine whether losing registrar is responsible for authentication

c. If gaining registrar is responsible for authentication

i. Obtain the Admin Contact data from the Losing Registrar WHOIS,

ii. Send standardized authentication message to the Admin Contact.

iii. If there is no affirmative response to this message, then no further action is taken.

iv. If there is an affirmative response to this message, go to step 3.

3. If losing registrar is responsible for authentication, send a standardized explanation to the Requestor of the process (which will include that the Losing Registrar will send an authentication message to the Admin Contact listed in the Losing Registrar’s WHOIS).Gaining registrar submits a transfer command to the registry.

4. Registry immediately notifies the losing registrar of the transfer request.

5. The losing registrar will:

a. First check to see if the domain name is available to be transferred (no UDRP action, no court action, etc.).

b. If the domain cannot be transferred under one of the allowable reasons, the losing registrar will immediately send a disapproval message to the registry.

c. If the name is available for transfer, the losing registrar will check to see if it is responsible for authentication based on the name of the gaining registrar.

d. If the losing registrar does the validation:

i. The standardized validation form is sent to the registrant/admin-contact within 24 hours.

ii. If, within a to-be-specified time (e.g., 10 calendar days), the losing registrar receives specific authorized approval or disapproval from the registrant/admin-contact, the losing registrar must submit the corresponding protocol response within a to-be-specified time (not to exceed 24 hours).

iii. If, within a to-be-specified time (e.g., 10 calendar days), the losing registrar receives no specific authorized approval or disapproval from the registrant/admin-contact, the authentication responsibility will be switched to the gaining registrar (based on the gaining registrar receiving no response from the registry).

1. The gaining registrar will have a to-be-specified time (e.g., 5 calendar days) to verify the validity of the transfer request by sending the standardized validation form to the registrant/admin-contact.

2. If the gaining registrar cannot verify the validity of the request, then thegaining registrar must submit the appropriate transfer cancellation command to the registry.

3. If the gaining registrar succeeds in verifying the transfer request, the gaining registrar must provide an email confirmation to the registry for record keeping in case of a of dispute, and then:

a. The gaining registrar must send a standardized message to a to-be-defined email address at the registry notifying the registry that required validation has been obtained.

b. The losing registrar need take no action.

c. The registry will process the transfer request at the end of the to-be-specified period (e.g., 5 calendar days).

6. The registry notifies both registrars as applicable regarding the action taken on the transfer request.

7. The gaining registrar notifies the entity requesting the transfer of the action taken using a standardized form.

8. Either registrar may file a dispute:

a. Registrars are expected to attempt to resolve disputes among themselves before initiating a dispute.

b. The registry of record will serve as the first level dispute resolution provider.

c. A neutral third party will serve as the second level dispute resolution provider.

d. The registrar raising a dispute will pay any dispute processing fees if the other registrar has complied with the transfer policy. If the other party is found not to have complied with the transfer policy, it will pay the costs of the dispute. The transfer dispute resolution will not be used to resolve disputes between parties claiming to represent the registrant.Registries will be responsible for debiting fees from registrar accounts and distributing them to providers as necessary.

e. Registrars will be responsible for maintaining and making available to the other registrar, to the registry and to any other dispute resolution provider documentation of all transfer process steps according to predefined standards.