Feasibility Impact Analysis of the Transfers Task Force Report

By Register.com

Authentication

The Transfers Task Force recommendations 9-10, 12, and 24-25 work together to create a significant loophole that could leave vulnerable many consumers. Task Force recommendation 13 does not provide an adequate and timely solution to protect consumers.

Taken together this sub-set of recommendations means that the losing registrar must trust the gaining registrar to do the authentication – a) send the approved confirmation message, b) to the appropriate contact in the losing registrar’s Whois, c) not confuse the registrant with deceptive marketing, and d) receive a confirming message from the registrant or administrative contact. Recommendation #12 specifies that this must all be “presumed.” The losing registrar may not deny a transfer even if he/she has reason to know that the gaining registrar has not followed these steps, has sent an approved confirmation to the registrant, and has not heard back.

We have seen instances of confusion by registrants, particularly due to misleading or deceptive marketing practices by large and small registrars and their resellers. Consumers are transferred against their will, have a hard time returning to their original registrar and registrars suffer not only from a loss of business, but customer complaints (at best) for not fulfilling the losing registrar’s fiduciary role. A dispute resolution mechanism does not solve this problem – it is lengthy and expensive. It offers only a post-facto solution even in cases of losing registrars knowing ahead of time of gaining registrars’ malfeasance.

Therefore, we would propose augmenting these recommendations in several ways:

1. In cases where a losing registrar knows or has reason to know that a gaining registrar has regularly violated authentication requirements or based transfer requests on deceptive marketing, the losing registrar may deny a transfer request if he/she does not get a response from the registrant.

i) Such evidence would include: examples of deceptive marketing messages; FTC or other similar government body advisory about such registrar’s marketing practices; 25% or more of the transfer requests being Nack’ed due to registrants responding that they do not want to transfer; 25% of such transfers trying to return after the transfer; or a significant number of complaints lodged with ICANN regarding the transfer practices of such registrar.

2. The time frame for the transfer process should be increased – to 10-15 days – to allow the losing registrar to alert the registry of bad practices by the gaining registrar. This could be an out-of-band occurrence (a fairly infrequent one), so that it would not require a change in protocol.

3. We would propose that the registry could have a list of the registrars that cannot be responsible for validating registrant requests (losing or gaining) due to a history of proven bad practices. This would alleviate the need to make changes in the protocol on a case-by-case basis.

Reasons to deny Transfers

Recommendation #25 may not work with the current deletes task force recommendations. Right now for purposes of alerting registrants that their name is expiring and they should renew, the grace period may be used to take the name and place it on registrar lock. This action would inadvertently trigger a nack under 24 and 25. The registry’s rules may need to change to address this discrepancy.

At the same time, if a transfer request comes through too close to the end of the renewal grace period and the registrant had not paid for the new term, a losing registrar may not be able to timely request reimbursement from the registry. Therefore, among the allowable reasons in #24 should be the transfer request coming within 5 days of expiration of a grace period.

Task Force

For reference, we have highlighted relevant sections of the Task Force recommendations under discussion:

9. The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars.

1. 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.

10. 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.

12. The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact.

13. In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation.

24. A Losing Registrar may deny a transfer request only in the following instances;
1. Evidence of fraud
2. UDRP action
3. Court order
4. Reasonable dispute over the identity of the Registrant or Administrative Contact
5. 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.
6. 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)

25. Instances when the Losing Registrar may not deny a transfer include, but are not limited to;
1. Nonpayment for a pending or future registration period
2. No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (egg – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)
3. 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.
4. Domain name registration period time constraints other than during the first 60 days of initial registration.
5. General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.