Transfers Implementation Committee Report 30 January 2003

This document provides:

An assessment of whether a recommendation is implementable

Information on issues that will need to be considered during implementation

Suggested additional text to clarify or improve the existing recommendations, with the aim to obtain a net gain in the transfer process from the current situation.

Organization of the Analysis

The analysis is mostly contained in two tables. In Table 1 contains an assessment of whether the Transfers Task Force recommendation is implementable, the relative cost of implementation, and the level of support from registrars.

Table 2 contains information on issues associated with the recommendations that will need to be considered during implementation, and also where appropriate additional or alternative text to strengthen or clarify the existing recommendation.

Table Abbreviations

Table Headings

# The number of the recommendation made by the GNSO Transfer Task Force (1-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/?)

Legend

N/A Not applicable

Table 1
#	Cost	Enf	Feas	Tech	Supp
1	Low	Yes	Yes	Yes	High
2	Low	Yes	Yes	Yes	High
3	Low	Yes	Yes	Yes	High
4	Low	Yes	Yes	Yes	High
5	Low	Yes	Yes	Yes	High
6	Low	Yes	Yes	Yes	High
7	Low	Yes	Yes	Yes	High
8	Low	Yes	Yes	Yes	High
9	Low	Yes	Yes	Yes	Med
10	N/A	Yes	Yes	Yes	Med
11	N/A	Yes	Yes	Yes	High
12	N/A	Yes	Yes	N/A	Med
13	Med	Yes	Yes	Yes	High
14	N/A	Yes	Yes	Yes	Med
15	N/A	Yes	Yes	Yes	Med
16	N/A	Yes	Yes	Yes	High
17	Low	Yes	Yes	Yes	High
18	Low	Yes	Yes	Yes	High
19	Med	Yes	Yes	Yes	High
19a	Med	Yes	Yes	Yes	High
19b	Med	Yes	Yes	Yes	High
19c	Low	Yes	Yes	Yes	High
20	Low	Yes	Yes	Yes	High
21	N/A	Yes	Yes	Yes	High
22	Low	Yes	Yes	Yes	High
23	Med	Yes	Yes	Yes	Med
24	N/A	Yes	Yes	Yes	Med
25	N/A	Yes	Yes	Yes	Med
26	Med	Yes	Yes	Yes	High
27	Med	Yes	Yes	Yes, with constraints	Med
28	Med	N/A	Yes	N/A	Med
28a	Med	N/A	Yes	N/A	High
28b	Med	N/A	Yes	N/A	High
29	N/A	N/A	N/A	N/A	N/A

Table 2 Detailed implementation analysis
#	Current recommendation with suggested enhancements	Comments and issues
1	Registrants must be able to transfer their domain name registrations between Registrars provided that the Gaining Registrar's transfer process follows minimum standards and such transfer is not prohibited by ICANN or Registry policies..	The Registry operators and ICANN should consider methods for improving the testing of a registrar’s transfer processes to ensure that their implementation is in compliance with the transfer policy. This testing could be done at the time of initial accreditation, or as part of an audit process.
2	Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards.	There are two primary registry to registrar protocols in use. RRP – developed by Verisign and used for com/net/org EPP – developed within the IETF process and still being finalised. Verisign have announced that they will migrate from RRP to EPP near the end of 2003, and into 2004. Where system changes (which could include software, legal or business process changes) are required at either the registry or registrars, a reasonable period of time (e.g 3 months) would be required to reach full compliance. Verisign notes that in some cases, software changes may take up to 6 months from an initial high level idea to include time to complete detailed specifications, software development, testing and deployment.

3	Existing Recommendation: Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar.	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.
	Suggested Replacement text: Registrars should provide a unique and private email address for use only by other registrars and the registry: 1. This email is for transfer issues only. 2. The address should be managed to ensure messages are received by someone who can respond to the transfer issue. 3. 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.
4	Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders.

5	Current recommendation: The Registrant must be informed 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. Information to registrants (and registrars) may be improved by ICANN providing a central registry of the transfer processes for each registrar to ensure that each registrar had a documented process. This may consist of links to the relevant transfers policy listed on the registrar website. Some registrars are adding additional constraints to when transfers can occur into their terms and conditions. A registrar should not be able to add conditions in addition to those listed in recommendation 24, that may limit competition and attempt to lock in the consumer to a particular provider.
	Suggested replacement text: 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.
6	In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time.	Many registrars have not properly implemented the EPP Protocol which incorporates an AuthInfo password for each domain name. To initiate a transfer a registrant must supply the AuthInfo password to the gaining registrar. The issue is that many registrars have not implemented procedures to allow a registrant to easily obtain the AuthInfo password associated with the domain name. The protocol allows for the user to select their own AuthInfo password, but the common implementation involves registrars creating this AuthInfo password on behalf of the registrant, and only provided the password to the registrant on request. It would be useful for registrars to settle on a common approach for retrieving the AuthInfo password, so that gaining registrars may instruct a registrant on the procedure to follow to retrieve the AuthInfo password. In any case the procedure for obtaining the AuthInfo password should be incorporated in the documentation for the transfer process discussed in recommendation 5.
7	In EPP-based gTLD Registries, Registrars may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what they require from a Registrant to change any aspect of its contact or nameserver information.
8	Current recommendation: The Gaining Registrar must verify the intention of the Registrant or Administrative Contact of Record to transfer their domain name registration by requiring that the Registrant complete a valid Standardized Form of Authorization. Suggested replacement text: The Gaining Registrar must confirm a transfer request, by requiring that the Registrant or Administrative Contact of Record as listed in the WHOIS complete a valid Standardized Form of Authorization. A transfer must not be allowed to proceed if no confirmation is received.	The current wording uses “verify the intention of the Registrant”. This may be difficult to implement legally. The replacement text uses the word “confirm”, to indicate that the registrant/admin contact listed in the WHOIS should explicitly confirm the request. In most cases a registrars’ only contact with the registrant is via a website, where the registrant has provided their contact details. There is no other information available to identify the registrant (ie no finger prints, or company incorporation documents etc) to verify the intention of the registrant. Many registrars for security reasons also do not retain credit card information. The last sentence makes it explicit that a transfer must not be allowed to proceed if no confirmation has been received.
9	Existing Recommendation: The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars. (a) However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant’s intent to transfer its domain name to the Gaining Registrar. Proposed revised text: The Gaining Registrar is responsible for validating Registrant requests to transfer domain names between Registrars. (a) However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant’s intent to transfer its domain name to the Gaining Registrar.	From a customer service point of view, it would be useful for the gaining registrar to know in advance that a losing registrar will also independently confirm the Registrar’s intent. One possible implementation would be for the registry to maintain a table showing for each gaining/losing registrar pair, whether the losing registrar will independently confirm the Registrant’s intent. Given that many registrants will receive two confirmation messages (first from the gaining and then from the losing), a further customer service improvement could be achieved by cooperating pairs of registrars to allow a losing registrar to send the first confirmation message, and if no response is received to that message then the gaining registrar would need to carry out confirmation. Under such an arrangement, the gaining registrar must obtain validation from the Registrant if the losing registrar has not received validation in response to the first confirmation message, and if the gaining registrar does not obtain an explicit confirmation from the registrant, then the gaining registrar must cancel the transfer operation. Registrars that operate via resellers, will often let the reseller carry out the validation process (particularly where language issues are involved), but that those registrars must still comply with the requirements to ensure that the process is being carried out in accordance with the transfers policy, and documentation must still be maintained and made available during dispute resolution The removal of the word “solely” will provide some flexibility in implementation, whilst ensuring that the gaining registrar is ultimately responsible.
10	Current recommendation: In the event that a Registrant has not confirmed their intent to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. Suggested replacement text: In the event that a Registrant or Admin Contact listed in the WHOIS has not confirmed their request to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed.	A longer period following the transfer to confirm a transfer – e.g 10 days instead of 5 days, would increase the chances of the losing registrar getting a positive response from the registrant, and thus reduce the number of disputes. This must be balanced against the potentially negative impact on the registrant in terms of a longer process to complete a transfer. This could be mitigated by requiring a losing registrar to immediately send a transfers approve message (as supported under both RRP and EPP protocols) to the registry when the registrant approves a transfer, and thus may offer the registrant the option to reduce 5 days down to less than 24 hours, to balance the possibly longer period if the registrant fails to respond. Before increasing the period to 10 days, a significant portion of registrars (e.g accounting for more than 66% of total registrations) would need to implement software to support immediate positive acknowledgements. Note most losing registrars only send a message to the registry when a transfer has been denied. Note under recommendations 8 and 9, if the losing registrar has not received confirmation, a gaining registrar must not allow a transfer to proceed if the registrant has not explicitly confirmed the transfer request. See also comments in recommendation 8 about the need to confirm the request via the registrant/admin contact listed in the WHOIS, rather than “verify the intent of the registrant”. The text of recommendation 11 could be improved similarly.
11	Existing Recommendation: If the Losing Registrar chooses to independently confirm the intent of the Registrant when the Losing Registrar receives notice of a pending transfer from the Registry, the Losing Registrar must do so in a manner consistent with the standards set forth in these recommendations of this report pertaining to Gaining Registrars. Specifically, the form of the request employed by the Losing Registrar must provide the Registered Name holder with clear instructions for approving or denying the request for authorization and a concise declaration describing the impact of the Registrant’s decision(s) including the outcome if the Registrant doesn’t respond. a. This requirement is not intended to preclude the Losing Registrar from marketing to its existing customers through separate communications. This requirement is intended to ensure that the form of the request employed by the Losing Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant. Suggested additional text: Authentication communications with registrants regarding the transfer process should not include any information other than that contained in the standardized form., Authentication communications with registrants should be sent as soon as operationally possible but must be sent not later than 24 hours after receiving the transfer request.	The intent of the suggested additional text is to ensure that a losing registrar does not attempt to unduly confuse a registrant by primarily sending marketing communications with some authorisation text buried. There have been some reports of emails from losing registrars being blocked by SPAM filters because of their high advertising content, and the lack of response from registrants has in turn created distrust by losing registrars in the process of gaining registrars. Thus it is important to ensure that losing registrars follow the same standardised text as gaining registrars for authentication messages, and that this text be sent within a time limit. Losing registrars are free to send any other additional messages before or after the authentication text.