Comments on the ITRP D policy

[Arthur Zonnenberg <sunsmountain@xxxxxxxxxxx>]

Dear ITRP D team,

Firstly, my appreciations of the work done so far in discussing improvements to 
the ITRP. It's a noble endeavour to develop good domain policy for the benefit 
of registrants and registrars alike. I hope I can contribute, and do so 
primarily for getting better policy to the benefit of everybody.

As an employee for a major Dutch and EU reseller turned ICANN accredited 
registrar recently, I have almost 7 years of experience with domain (gTLD and 
ccTLD) transfers and related issues. I'll try to keep my feedback centered on 
the 6 charter questions asked. We have not joined the GNSO yet, but as a 
stakeholder we would belong there.

Being Dutch, my style may seem a bit frank and direct to you. Don't worry as we 
share the same intention: to make policy better. These comments are made by 
myself as an experienced individual and member of the public, not on behalf of 
the company I work for. This is my first time responding on GNSO policy, so 
please bear with me.


*
a) Whether reporting requirements for registries and dispute 
providers should be developed, in order to make precedent and trend 
information available to the community and allow reference to past cases
 in dispute submissions;


> In general, this is a good idea that you support. This will give precedents 
> we can all refer to and make the rules more clear to everybody.


*
b) Whether additional provisions should be included in the TDRP (Transfer 
Dispute Resolution Policy) on how to handle disputes when multiple transfers 
have occurred;


> If multiple transfers have occured after the first one that is wrong, then 
> only that one should be checked. Checking the entire chain does not seem 
> useful to me. Wherever the domain may be afterwards, it should be rolled back 
> to the state before the first breach, preferably actively by the registry. 
> Most of the affected 'registrants' are puppets by a hacker, or real users 
> that saw a deal that was too good to be true (an inviting price for a highly 
> valued domain). Then it usually is. But it's pretty much a corner case that 
> does not occur often.


*
c) Whether dispute options for registrants should be developed and 
implemented as part of the policy (registrants currently depend on 
registrars to initiate a dispute on their behalf);


 > There are not many TDRPs filed in total, which I explain primarily by the 
 > lack of need for them. The wild west in the starting days is a long time ago 
 > and no longer relevant. The policy of the company I work for is to outreach 
 > first, and only if we have 
gathered proof and are 100% certain we will win, would we start the 
procedure. The financial risk of having to pay for a TDRP is 
discouraging us to invite our end users (domain name holders) to contact us to 
start the procedure. Especially if a 'no decision' can and often does occur. 
The notion then remains that losing registrars blocking a transfer of your 
domain name because of payment dispute, can simply continue to do so, which is 
unfortunate. What we find in practice is where those cases are reported to us, 
we can - up to now - always convince the 'losing' registrar to cooperate.

> I would like to encourage the ITRP D work group to consider recommending 
> removing the fees (keep the fines), as they can currently and are seen by us 
> as prohibitive. Registrars starting procedures in vain or without good cause 
> can be warned, fined and ultimately de-accredited based on the RAA. I feel 
> gTLD registries should take more responsibility, in order to deal with this. 
> Ultimately they are responsible for their database, not others, even if it's 
> a thin registry.


*
d) Whether requirements or best practices should be put into place 
for registrars to make information on transfer dispute resolution 
options available to registrants;


> In general, yes this is a good idea. But a lot of text on the ICANN website 
> needs to be shortened and simplified, because it still uses way too much text 
> and acronyms to explain something simply. This not only applies to the 
> transfer FAQs which are actually directly linked from the homepage (a good 
> step), but also to the registrants rights and responsibilities, and other 
> policies like WDRP, ERRP or Whois Accuracy Specfication, which are actually 
> not explained to the public at all, while missing / bouncing one of these 
> e-mails means your website and e-mail are disabled within 15 days. *sarcasm 
> on* Always nice to find out when you get back from your holiday, and learn 
> about ICANN the "positive pro-active" way with your domain disabled. *sarcasm 
> off*. Seriously, the ICANN website needs educated text writers who can write 
> in a more accessible way in layman's terms. The registrant impacting policies 
> should have short pages no longer than 1 screen, explaining each of them 
> separately. Answering questions like "Why is this policy here? How does it 
> affect me? What can I do about it?" I fully agree with your recommendations 
> on this point.


*
Penalties for IRTP Violations

e) Whether existing penalties for policy violations are sufficient or if
 additional provisions/penalties for specific violations should be added
 into the policy;

> Financial penalties are almost always efficient when dealing with registrars 
> violating policy. Alternatively, ICANN compliance has enough tools as it is 
> for those registrars unfased by fines.


*
Need for FOAs

f) Whether the universal adoption and implementation of EPP AuthInfo codes has 
eliminated the need of FOAs.

> Here's the only issue we disagree on. In the report 5.2.6.1 Observations are 
> made by ICANN compliance, that "FOAs are essential to help resolve the 
> dispute and to reverse it if appropriate. It is for this reason that ICANN 
> Compliance also expressed its support for maintaining FOAs, reasoning that 
> its continued use may help prevent hijackings in certain cases or serve as 
> evidence in disputes." Yet no examples or numbers are given where the FOA 
> made the difference, above and beyond the AuthInfo code. Why should 
> compliance dictate the rules for 250.000+ successfull transfers per month 
> based on a couple of disputes? (see the .com registry report for november 
> 2013, com-transactions-201311-en.csv from 
> http://www.icann.org/en/resources/registries/reports/com)  If there are 
> 500.000+ failed transfers each month (timed out waiting for owner approval), 
> isn't that a far bigger and more serious issue than a handful of hijack cases?

> Let me inform you that the FOAs are our single most common source of pending 
> orders costing time and often revenue in our registration systems. The 
> typical way a gTLD transfer proceeds -  as James Bladel describes in the full 
> report - is somewhat incomplete. Please allow me to add important elements to 
> it pertaining to the FOA and other relevant elements:

===
a) A Registrant sends a transfer request to the new registrar (“Gaining 
Registrar”);
b) The Gaining Registrar provides instructions to the registrant, incl. get the 
AuthInfo Code from the current registrar (“Registrar of Record”);
> including unlocking the domain name and updating the admin-c email address.

c) After confirming the Registrant and/or Administrate Contact email address, 
the Gaining Registrar sends the FoA to the Transfer contact;
> and confirming the domain being unlocked and the auth code being reported as 
> retrieved.

d) The Transfer contact confirms the FOA and sends the AuthInfo code that was 
obtained from the Losing Registrar to the Gaining Registrar;
> No, typically the transfer times out the first time, because the registrant 
> has no idea what to do with the FOA. Then the domain is locked after time x 
> for typical "safety reasons" by the losing registrar, and you first have to 
> inform the transfer contact to unlock the domain again. Often the losing 
> registrar will have updated the AuthInfo code "safety reasons", leading to 
> many failed gTLD transfer with the wrong (previous) AuthInfo code. Most 
> transfer contacts (customers) give up, you don't hear about them and you 
> don't see them in the statistics. The FOA is a primary reason for this.
My careful estimate is that the number of failed transfers are at least twice 
the number of successfull transfers.

e) The Gaining Registrar requests the transfer and sends the AuthInfo code to 
the Registry;
> If your customer is a seasoned or thoroughly instructed and persistent 
> Transfer Contact, then yes.

f) If the domain name registration has no status that impedes the transfer 
(e.g., client Transfer Prohibited) and the AuthInfo code valid, the Registry 
sends notice that the transfer is pending to the Gaining and Losing Registrar;
> That's  a big if. Often a domain does have an impeding status, even if it was 
> removed before. The domain lock client Transfer Prohibited is also a primary 
> reason for transfer contacts (customers) giving up.

g) The Losing Registrar must send an FOA to the Registrant. However, the 
transfer is not depending on this step.
> It's a big shame the losing registrar does not actively ACK to reduce the 5 
> day waiting time, which is a long time and wasted time is wasted money. For 
> large teams building big websites, this is costly.

h) After 5 days with no objections (“NACK”), the transfer is complete.
> And all kinds of winbacks of transfers can still occur. But usually yes 
> you're done.
===

> However, if you as a transfer contact have to update your admin e-mail 
address, while at the same time unlocking the domain and requesting the 
auth code, some registrars (NetworkSolutions, Ascio, ...), trigger 
additional "safety measures" leading again to transfer contacts giving 
up. You have to phone call them to tell them you're leaving. Per domain name. 
Or you have to confirm the FOA from the losing registrar or they will NACK the 
transfer by default, even if they have no right to, and they'll typically only 
do it once. Per domain name.

> The effort that goes into contacting legitimate registered name holders, 
> explaining to them this "extraneous" step they need to take, after it has 
> already failed once, means any gTLD transfer typically takes 3 weeks for 
> those unaccustomed to the process. That's after a delay of 2 weeks before 
> even starting with the FOA, telling customers to unlock their domain name 
> first and get the AuthInfo code. Even those end users that have experience, 
> often forgot which email address they used at some point in the past to 
> register those domains, or forget 1 step and face failed transfers and more 
> delays due to 5 days waiting time per transfer attempt. A lot of providers as 
> resellers still enter their own email address instead of that of the end 
> user, and you have to time the new attempt to transfer and inform the end 
> user to chase the losing provider/reseller to cooperate, because they will 
> ignore the email whenever they can. Again leading to transfer contacts giving 
> up.

> Let's stop kidding ourselves. An authorisation is an authorisation.
 And the majority should not suffer from the minority. A trust model is 
possible, where
 gaining registrars are trusted in the transfers they execute with valid 
AuthInfo codes. In the 
case of abuse or dispute, it should be easier to complain, rollback and 
fine the abusing registrar. The original registered name holder should 
be retrievable and verifiable after one or more transfers have been made, where 
the 
original registrant can prove their identity and say: "I want my domain name 
back, it has been hijacked." FOAs add nothing to this. If as a hacker you
 can get access to the auth code and unlock the domain, the email 
address is a piece of cake since you can update it via the same 
registrar control panel. Please read this article: 
http://gizmodo.com/how-i-lost-my-50-000-twitter-username-1511578384

> Currently 3 factors are required for 1 successfull transfer (unlock, FOA + 
> email address, auth code), where every factor beyond the auth code does not 
> add either authorisation or true security. All 3 are often accessible through 
> 1 control panel or email address. It's actually possible to have domains 
> unlocked by default. In that case, locking and unlocking your domain name 
> could be a 2 factor authenticated process (identification documents, phone 
> calls for identification, hardware or software tokens uniquely linked to a 
> personal secret, etc.), so it would actually add security. Currently the 
> clientTransferProhibited has been watered down in my opinion compared to what 
> it could be.

> The more difficult you keep gTLD transfers, the less competitive the market 
> will become. GoDaddy is the biggest registrar here, and the more factors they 
> can keep to prevent transfers away, the more business revenue they can and 
> will protect (see transfer contacts giving up above). The same can be said 
> about the other large registrars. They might say it's all about security and 
> safety, but really it isn't.

> Concluding remarks: The ITRP is indeed a cornerstone to the industry, but as 
> it stands it is too complicated for registrants to understand. Many abandon 
> their desire to transfer at some point and stick with the current registrar 
> and change the DNS or nameservers instead. This is anti-competitive 
> behaviour. Additionally, both registrant and registrars I think prefers a 
> trust model. Complaints afterwards should be easier to make and checked, 
> after which rollbacks are performed by engaged 
registries, and trespassing gaining registrars should be fined by ICANN 
compliance, regardless of cause. 
Finally, the 3.000.000+ succesfull and the 6.000.000+ failed .com transfers per 
year should weigh heavier 
than the ~50 complaints related to unauthorized transfers per year ICANN
 compliance faces. Requiring 3 steps from gTLD registrants versus 1 step for 
most ccTLDs registrants does not promote a fair and equitable market.

I would recommend the remaining ITRP working groups D and E to consider these 
comments in future deliberations.

If you have any questions, comments or suggestions to improve my feedback, let 
me know. I will be present at the ICANN50 meeting in London, and will spare 
what time I can.

Sincerely,

Arthur Zonnenberg
http://icannwiki.com/index.php/Arthur_Zonnenberg