Re: [gnso-irtpd] Final Report Recommendations

[Arthur Zonnenberg <azonnenberg@xxxxxxxxxx>]

Dear all,

As promised, my reactions to this final report as well as previous meetings' 
comments. Due to a recent internal physical transfer of our office, I was 
delayed in getting these to you. See you all soon in the meeting.

charter question C

cost increase is handled from the point of view of the registries, but not from 
the point of view of the RNH, what the BC intended. Perhaps ICANN compliance 
could be a more accessible and affordable dispute resolution for registered 
name holders, where - as noted - trademark knowledge and such legal background 
is not a priori necessary to resolve a dispute. IF such legal knowledge is 
deemed necessary, ICANN compliance can still give a 'no verdict' and refer the 
complainant to legal measures.
This would also be in line with ICANN explaining the TDRP on its website - they 
could offer a channel to handle such disputes.

charter question D

Instead of adding explanations as best practice, the explanation of TDRP could 
be added to a FOC versus an FOA. That way you always have the information as a 
former registered name holder.

charter question F

useful for auditing. It is however not likely to prevent fraudulent transfers. 
Any hacker that has access to the auth code, generally at the account level or 
user level, will be like to have access to (updating) the e-mail address of the 
registered name holder. Rendering the FOA moot.

For auditing purpose the FOA could be changed to a Form of Confirmation sent to 
the previous registered name holder. The reason why this is important is 
because this 'extraneous step' is a likely cause of a higher gTLD transfer fail 
rate, together with it's depencies on the WHOIS as well as the EPP status: 
clientTransferProhibited. Our Hostnet data indicates, that, based on 3 million 
.com transfers per year and a current 25% fail rate, 1 million .com transfers 
are not transferred each year despite the registered name holder express wish 
to do so. ccTLD transfer data imply that we can reduce this to 10% or less, 
which would mean 600.000 more successfull transfers leaving 400.000 failed 
ones, where registered name holder truly changed their mind instead of where 
they gave up. The question is if the WG considers this a valid reason to change 
the FOA to a confirming non-blocking e-mail (Form Of Confirmation)?


In reaction to comments made by :

Berry Cobb - it is important to note that the FOA / auth-code / 
clientTransferProhibited combination does not, in security terms, constitute a 
'true' multi-factor authentication
http://en.wikipedia.org/wiki/Authentication_factor#Factors_and_identity
This is because all 3 elements are based on what a user knows, not what a user 
has (smartphone with software key or a hardware token), nor what a user is or 
does (finger print, retinal pattern, DNA, hand written signature). In reality, 
all 3 factors are often accessed by the same customer portal registrars offer 
to end users or resellers. If a portal is not offered, expiring the end user 
contract for the domain name can lead to a combined unlock + distribution of 
authcode + update of e-mail admin-c, defeating any claim to multi-factor 
security. This may be too high for ICANN to aim for, if required a solution 
could be the signature or a open source authenticator as for example 
implemented by dns.be :
http://www.dnsbelgium.be/en/help-page-2-step-verification

Volker Greimann - the FOA does not prove with certainty who is authorizing the 
transfer. An IP address does not uniquely identify a RNH. The only thing we 
know about a FOA is to which e-mail address it was sent. Preferably for 
inter-registrar, but also inter-registrant transfers, the *previous* registered 
name holder is informed. This can also satisfy the audit requirements. The new 
registered name holder is required to verify the e-mail address as you have 
mentioned.

James Bladel - First of all thanks for asking about the suggestion of changing 
the FOA to your godaddy compliance department. The reseller becoming registrar 
can temporarily set itself as administrative contact, to grant permission on 
behalf of the RNH for any bulk transfer. This can and is frequently done. 
Legally, the end user contract is unaffected by which supplier is chosen. While 
the RAA does require us to inform the registrant of their current registrar, it 
does not force us to include the current registrar in the end user agreement. 
In other words even for ICANN a change of registrar does not constitute a 
change in the contract with the registered name holder. At the same time, one 
can safely assume a gaining registrar will only submit a transfer once it has 
or has been reasonably satisfied its terms & conditions have been accepted.
Furthermore, combining multiple FOA / FOC transfer e-mails into a single 
e-mail, would already be allowed under current policy in terms of compliance. 
Text messages would give an alternative, but not improve the likelihood of a 
RNH agreeing. The point is that many RNH's currently give up is what we're 
noticing in practice. A resulting point of that is that I'm not trying to 
prevent harm, I'm trying to prevent unnecessary blocking of RNH's legitimate 
wish to transfer their domains.

Rob Golding - your opinions describes exactly the agreement on behalf of the 
new registered name holder which can safely be assumed to be had. I would 
suggest we aim to simplify the IRTP where possible, while not sacrificing any 
audit power the policy currently gives.

Met vriendelijke groet / Kind regards,

Arthur Zonnenberg
Product Manager

azonnenberg@xxxxxxxxxx
http://www.hostnet.nl
Tel: +31.207500834
Fax: +31.207500825

Hostnet bv
De Ruijterkade 6
1013 AA Amsterdam
NL

----- Original Message -----
From: "Lars Hoffmann" <lars.hoffmann@xxxxxxxxx>
To: gnso-irtpd@xxxxxxxxx
Sent: Friday, July 11, 2014 10:16:20 AM
Subject: [gnso-irtpd] Final Report Recommendations


Dear all,


Please find attached a first red-line version of the recommendation for the 
Final Report. In light of Monday’s agenda (see below) it would be very useful 
if you could familiarise yourself with the changes as we will start working on 
determining consensus level on at least some of these.


Many thanks and best wishes,
Lars




Proposed Draft Agenda
I RTP Part D PDP WG, Monday 14 July 2014



1. Roll Call/SOI Update


2. Review redline-version of recommendations and determining consensus level


3. Next steps/Confirming next meeting