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@hostnet.nl 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@icann.org> To: gnso-irtpd@icann.org 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