<div dir="ltr">Hi Seun and Guru,<div><br></div><div>I think you are talking about two different elements that overlap but are distinct:</div><div><ul><li>the notion that the contract(s) should be <b>breakable and transferable</b> to an other actor - for instance through an open bidding - in case of blatant non-performance, disfunction or fault. This is an extra-ordinary/emergency sanction and Seun indicates it should be possible at any point in time if the conditions are met. <br></li><li>the notion that the contract(s) could have a <b>set duration</b>, with Guru asking if a longer term (10 years) could alleviate the concern regarding institutional instability that doing a rebid at too short intervals could entail. This is discussed as a normal regime, even in the case that the operator performs OK. <br></li></ul></div><div>I feel the first point would receive broad support. In any case, I am personally comfortable with it. Some extra-ordinary procedure is probably needed to anticipate real problematic situations. A key question is the determination of the threshold(s)/acceptable triggers and how high they are. But let's leave this aside for the moment. <br></div><div><br></div><div><b>Two variables to define options for a "normal regime"</b></div><div><br></div><div>The second point (the "normal regime" to be implemented even in the absence of any problem a priori) makes me think that we can map options on the basis of <b>two complementary variables</b>:</div><div><br></div><div>a) On one hand, the basic <b>duration of the contract</b>(s): there is a simple range going from very short (eg: 2years) to fully permanent (including the procedure above), with for the sake of simplicity, two intermediaries at 5 and 10 years for instance. </div><div><br></div><div>b) On the other hand, <b>what happens at the expiration of each period</b>. I see here three basic options: </div><div><ol><li>systematic and compulsory full rebidding each time (as per Milton),<br></li><li>explicit decision each time to either continue with the same operator for another period or do a rebidding <br></li><li>presumption of renewal unless explicit decision is made to open rebidding under certain conditions (they can be more or less strict and even have no threshold at all) <br></li></ol></div><div><b>Combinations</b></div><div><b><br></b></div><div><div>These two variables can be combined in many ways.</div><div><br></div><div>For instance, the current IANA contract has a first period of three years plus two options for extension for two years each (ie: 7 years in total). In the absence of the current effort towards transition, this would have allowed NTIA to nor exercise the option after three years and open a rebid if it wanted. This corresponds to option b)2 supra. </div><div><br></div><div>Likewise, the current regime for gTLDs is closer to b)3: presumption of renewal unless very strict criteria justify otherwise.</div></div><div><br></div><div>In designing the post-transition regime, we need both to find a sustainable solution that will not have to be re-discussed in a couple of years (the natural tendency at ICANN, an organization in perpetual institutional flux) and take into account that the new regime may need a period of adaptation/transition itself. </div><div><br></div><div>Moving towards a longer contract period and presumption of renewal could be envisaged with predetermined steps. For instance, five initial years with an explicit extension option of five years and then a move to 10 years or any other combination. </div><div><br></div><div>The option of opening rebidding would be available at each deadline but could be (explicitly or implicitly) NOT exercised if performance is judged sufficient and stability is deemed paramount. Or, on the contrary, be available only IF performance is deemed insufficient. An alternative similar to the opt-in and opt-out choice. </div><div><br></div><div>In other words, there are many ways to play with those components to tailor something appropriate. In any case, I would argue that a very short duration of the contract (2-3 years) with systematic rebidding would probably harm stability and create administrative burdens more than it would enhance accountability beyond other combinations. </div><div><b><br></b></div><div><b>Open rebidding as principle or as signal?</b></div><div><br></div><div>It is interesting to note that the last IANA contract process did not produce competing candidates. It was mostly a negotiation of enhanced SLAs and better structural organization (including functional separation). But it created an important preliminary administrative burden. </div><div><br></div><div>Open rebidding is not needed to renegotiate SLAs or arrangements with the same operator. Such a modification process could be triggered separately at any appropriate moment, should the need arise, according to specific separate rules. </div><div><br></div><div>In other terms, there is a difference between open rebidding as a matter of principle, even when the operator is perceived as performing OK and open rebidding as a signal that something is not functioning correctly. My sense is that if it is optional, it strongly encourages the operator to avoid deserving this message. </div><div><br></div><div>In that situation, any announcement on the occasion of a renewal that an open rebid will be made would stigmatize strongly the operator. Remember the image of ICANN when its first submission in the last IANA process was refused. On the contrary, making rebid systematic penalizes the good operator by not treating it differently from a non-performing one.</div><div><br></div><div><b>The overall objective</b></div><div><br></div><div>As a general rule, I favor regimes that make things easy for the good guy and install strong ongoing monitoring and remediation measures to rapidly address dysfunctions, rather than regimes tailored on the basis of defiance and the a priori supposition of misconduct. </div><div><br></div><div>Changing the operator would not be a minor decision. It would entail administrative and technical challenges, risks to the stability of the system, and in any case unknowns regarding the potential replacement (the devil you know...): making a submission is one thing, living up to the promises might be another. It is therefore more a threat, a sanction, a message, than an ongoing mundane mechanism. </div><div><br></div><div>So far, the contract has been renewed for the last 16 years. Hopefully ICANN - once again created for that purpose - can be incentivized to perform better and better and remain the operator far in the future. I would favor designing the regime in the perspective of this objective. </div><div><br></div><div>Apologies for the long post. Certainly needs refinement. But I hope it helps frame the discussion further. Just my own perspective. </div><div><br></div><div>Best</div><div><br></div><div>Bertrand</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><table width="600" border="0" cellspacing="3" cellpadding="0" style="font-family:Arial,Helvetica,sans-serif;font-size:13px;line-height:1em;color:rgb(38,38,38)"><tbody><tr><td colspan="3" height="5"></td></tr><tr style="font-size:13px;color:rgb(176,173,176)"><td colspan="3">"<em>Le plus beau métier des hommes, c'est d'unir les hommes</em>", Antoine de Saint Exupéry<br>("<em>There is no greater mission for humans than uniting humans</em>")</td></tr><tr><td colspan="3" height="10"></td></tr><tr><td colspan="3"><span style="color:rgb(0,138,204);text-transform:uppercase">BERTRAND DE LA CHAPELLE</span></td></tr><tr><td colspan="3">Internet & Jurisdiction Project | Director</td></tr><tr><td colspan="3">email <a href="mailto:bdelachapelle@internetjurisdiction.net" alt="email Bertrand de la Chapelle" style="color:rgb(159,157,159);text-decoration:none" target="_blank">bdelachapelle@internetjurisdiction.net</a></td></tr><tr><td colspan="3">email <a href="mailto:bdelachapelle@gmail.com" alt="email Bertrand de la Chapelle" style="color:rgb(159,157,159);text-decoration:none" target="_blank">bdelachapelle@gmail.com</a></td></tr><tr colspan="3"><td>twitter <a href="https://twitter.com/IJurisdiction" alt="Internet & Jurisdiction Twitter Accompt" style="color:rgb(159,157,159);text-decoration:none" target="_blank">@IJurisdiction</a> | <a href="https://twitter.com/bdelachapelle" alt="Paul Fehlinger Twitter" style="color:rgb(159,157,159);text-decoration:none" target="_blank">@bdelachapelle</a></td></tr><tr colspan="3"><td>mobile <span style="color:rgb(159,157,159)">+33 (0)6 11 88 33 32</span></td></tr><tr><td colspan="3"><a href="http://www.internetjurisdiction.net" alt="Internet & Jurisdiction Website" style="color:rgb(159,157,159);text-decoration:none" target="_blank">www.internetjurisdiction.net</a></td></tr><tr><td colspan="3" height="5"></td></tr><tr><td colspan="3"><img src="http://www.internetjurisdiction.net/wp-content/uploads/2013/11/InternetJurisdiction-Logo-w300px.png" alt="A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS" width="300" style="margin:0px;border:none"></td></tr><tr><td colspan="3" height="5"></td></tr></tbody></table></div></div></div>
<br><div class="gmail_quote">On Thu, Nov 13, 2014 at 8:48 PM, Seun Ojedeji <span dir="ltr"><<a href="mailto:seun.ojedeji@gmail.com" target="_blank">seun.ojedeji@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Nov 13, 2014 at 6:41 PM, Guru Acharya <span dir="ltr"><<a href="mailto:gurcharya@gmail.com" target="_blank">gurcharya@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Would your concerns about stability arising from operator hopping be addressed if the contract term is longer - say 7 or 10 years?</div></blockquote><div><br></div></span><div>Not really, i am thinking more of a scenario where if ICANN goes against defined SLA/terms it be called to order to resolve and if that goes negative, a clearly defined process to transfer to another operator is initiated. Ability to do that should not be possible after a 2 years term neither should it be after a 10years. This should be possible at any point in time and if that understanding valid, i don't see why a termed contract will be necessary.<br><br></div><div>However i am not a lawyer so perhaps what i have explained is not legally attainable, but from a logical point of view, i think it is feasible. <br></div><div><br></div><div>Thanks<br><br></div><div>Regards<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 10:58 PM, Seun Ojedeji <span dir="ltr"><<a href="mailto:seun.ojedeji@gmail.com" target="_blank">seun.ojedeji@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">While we consider all these options, I will ask that we also consider whether it's better to concentrate on an organisation with the aim of improving it's operation OR we keep on moving from one incomplete organisation to the other in the name of keeping the previous/current operator accountable. </p>
<p dir="ltr">We should in this process determine whether there is significant improvement in the current operator of IANA and also whether there is room for further improvement. Stability cannot be maintained if the operator itself is not stable. </p>
<p dir="ltr">My 2 cents.</p>
<p dir="ltr">Cheers!</p>
<p dir="ltr">sent from Google nexus 4<br>
kindly excuse brevity and typos.</p><div><div>
<div class="gmail_quote">On 13 Nov 2014 18:03, "Guru Acharya" <<a href="mailto:gurcharya@gmail.com" target="_blank">gurcharya@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree with Milton that the IANA contract should be for a limited time period (say 3 or 5 years). The oversight body should be responsible for deciding the new IANA operator at the end of the contract term. This is the most effective way of ensuring accountability.<div><div><br></div><div>However, I disagree with the mechanism of "Open Bidding" that Milton seems to be suggesting for determining the new IANA operator. The term Open Bidding seems to suggest financial reverse auctions. The mechanism should instead be in the form of a transparent beauty contest wherein open applications are invited from all interested parties. The judging parameters for the beauty contest should be mostly technical. In this beauty contest, the incumbent IANA operator should get extra marks in case of a good record in the previous contract term, the measure of which should be in the form of objective service level criteria.</div></div><div><br></div><div>If the IANA contract is perpetual or with termination clauses based solely on service levels then, in case of serious dissatisfaction with the incumbent IANA operator, the process of changing the IANA operator may be subjected to a lot of litigation and arm-twisting. The current transition arrangements need to have the foresight to avoid such problems.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 7:03 PM, Milton L Mueller <span dir="ltr"><<a href="mailto:mueller@syr.edu" target="_blank">mueller@syr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><a name="149aab49c2640b63_149aa3ec42c7721c_149aa33093806e3e_149aa1be53bdc499_149a96156c884d0a__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:4.8pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Bertrand de La Chapelle [mailto:<a href="mailto:bdelachapelle@gmail.com" target="_blank">bdelachapelle@gmail.com</a>]
<br>
<br>
</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<div><span>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">view, accountability was also exercised on a regular basis, through the monitoring of performance, the possibility of audits and, actually, also the role of NTIA as RZM process administrator
(on each modification). In this regard, moving the contract somewhere else, as "nuclear option", was the ultimate accountability stop but not the alpha and omega of the accountability system.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">MM: True. Those forms of accountability are complementary. But most of the proposals on the table for a new contracting authority also include these other forms
of monitoring. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><span>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">Furthermore, ultimate accountability does not need to come from a single point of authority. It can be more distributed. For instance, if the different user communities of the IANA
functions were to establish separate agreements with ICANN (or recognize that it plays this role for them) with the capacity to cancel this agreement on the basis of specific criteria (including performance), the capacity to "pull the trigger on a contract"
would be fulfilled. </span><span style="font-family:"Arial",sans-serif"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">MM: This is a very interesting idea and I hope you pursue it and make it more concrete. As a future scenario it is highly likely that IANA’s performance might
satisfy one or two of the operational communities but not the other one. Furthermore, as you suggest, it is safer to distribute this contracting authority rather than having it concentrated.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><span>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">The question of accountability should not be limited to the single model of replacing the NTIA by another single structure (to be created), continuing without question the practice of re-bidding
that was the result of circumstances as much as a voluntary choice, and focusing on the "nuclear option" as the most important aspect, neglecting on the way more continuous accountability dimensions. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">MM: Well, I do not want to neglect more continuous accountability dimensions, but after 16 years of experience with the ICANN environment I have a pretty strong
conviction that nothing short of periodic renewal can provide the foundation for all the other forms of monitoring and accountability.
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><span>
<p class="MsoNormal">All I argue for is that we should include in our thinking the following option: what would be the accountability mechanisms appropriate IANA were permanently managed by ICANN? <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">MM: No, there is definitely a contradiction between “being accountable” and a grant of “permanent management” rights. While there can be some additional supervisory
or oversight mechanisms, insofar as the grant is permanent it massively increases the slack that the operator has against its principals. If the assumption is, “I will always be the contractor” you can issue all the stern warnings and bad reports you like,
the incentive to change is drastically weakened. This seems obvious to me. <u></u>
<u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr">------------------------------------------------------------------------<br><font color="#888888"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:garamond,serif">
<i><span style="color:rgb(0,102,0)">Seun Ojedeji,<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Federal University Oye-Ekiti<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">web: </span><a href="http://www.fuoye.edu.ng" target="_blank">http://www.fuoye.edu.ng</a><br>
<span style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Mobile: <a value="+2348035233535">+2348035233535</a></span><span style="color:rgb(0,102,0)"></span><br></i><i><span style="color:rgb(0,102,0)">alt email:<a href="http://goog_1872880453" target="_blank"> </a><a href="mailto:seun.ojedeji@fuoye.edu.ng" target="_blank">seun.ojedeji@fuoye.edu.ng</a></span></i><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The key to understanding is humility - my view !<br></blockquote></blockquote></font><br></div></div>
</font></span></div></div>
<br>_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br></blockquote></div><br></div>