<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time.  I will review the notes and recording and respond on list as necessary.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round.  A very simple, clean way to settle contention
 sets without these measures is to have them all go to an ICANN auction of last resort or a random draw.  But some people insist that losers should get paid so those are off the table.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I also believe that we have to address BOTH Board concerns -
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions</span></b><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">We have made good progress in addressing #1 and I think we can get there with some tweaks.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Transparency requirements are good but they should not be rolled back for the creation of JVs.  Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also
 know the circumstances around what caused members of the contention set who are not part of the JV to drop out. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators.  Rationale is that at some point, the evaluators will disappear.  They are temporary help. 
 ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">And along these lines – ICANN should oversee all auctions, not just the Auction of Last resort.  As currently constructed in Paul’s edit – there are too many steps for revealing the results of private auctions. 
 With ICANN overseeing this, it’s a much cleaner process.  ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">As far as penalties for violations of the Bona Fide requirements – loss of registry has to be there.  That is a major deterrent and should not be cast aside.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">Board Concern #2 - gaming for the purposes of financing other applications.</span></b><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The base Proposal 5 does nothing to address Concern #2.  Donna stated that she’s “not convinced that means we have to address it.”  I couldn’t disagree more. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves.  Neither
 is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications.  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I and others believe that the Bona Fide requirements do not go far enough here.  Others believe my sealed bid requirement goes too far.  So what are alternative solutions that are enforceable and prevent this
 type of activity?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Auction proceeds held in escrow? All auction conducted at once? 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront.  With bids upfront, auctions could be conducted whenever but there is a constraint
 on the ability to roll funds over and over.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">ICANN’s right to refer to competition authority. 
<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether
 it should be spelled out.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators.  It specifically calls out competition authority referral if ICANN
 makes a determination such referral is necessary.  I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">My rationale for including this provision and calling it out specifically is simple – if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer
 it to relevant competition authorities to ensure they are ok with it.    This protects ICANN the institution from charges that it is fostering anticompetitive behavior.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Jim Prendergast<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The Galway Strategy Group<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">+1 202-285-3699<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>