Feasibility Impact Analysis of the Transfers Task Force
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
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:
- 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.
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.
- 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
- 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.
to deny Transfers
#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.
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.
For reference, we have highlighted
relevant sections of the Task Force recommendations under discussion:
- The Gaining Registrar is solely responsible
for validating Registrant requests to transfer domain names between
- 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.
- 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.
- The presumption in all cases will be that
the Gaining Registrar has received and authenticated the requisite request
from the Registrant or Administrative Contact.
- 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.
- A Losing Registrar may deny a transfer request
only in the following instances;
- Evidence of fraud
- UDRP action
- Court order
- Reasonable dispute over the identity of the
Registrant or Administrative Contact
- 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.
- 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)
- Instances when the Losing Registrar may not deny
a transfer include, but are not limited to;
- Nonpayment for a pending or future registration
- 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)
- 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.
- Domain name registration period time
constraints other than during the first 60 days of initial registration.
- General payment defaults between Registrar and
business partners / affiliates in cases where the Registrant for the
domain in question has paid for the registration.