<div dir="ltr">Hi Milton,<div><br></div><div>See comments inline.</div><div class="gmail_extra"><div><div><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></tbody></table></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 12, 2014 at 6:40 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt">
<div>
<div>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</div>
<div><span>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">ICANN was fundamentally created to handle the IANA functions (cf the Bylaws, where coordination of allocation and assignment of the three sets of unique identifiers is
mission n°1). It has performed this without major problems so far and it should not be excluded a priori to confer this mission permanently to the
<font color="#1f497d"><span style="color:rgb(31,73,125)"><u></u><u></u></span></font></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</span><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">MM: Actually there were major problems in the early days. And the logic of saying, “you have been going a good job
recently while you were accountable to us, so now you don’t need to be accountable anymore” has always escaped me. The NTIA role was not fundamentally about workflow or mandate, it was about
<b><span style="font-weight:bold">accountability</span></b>. Periodic contracting is the only acceptable accountability mechanism on the table, imho. There can be all kinds of oversight mechanisms but they are ineffective, even meaningless unless someone can
pull the trigger on a contract. </span></font></p></div></div></div></div></div></blockquote><div><br></div><div><font face="arial, helvetica, sans-serif">BPC: To clarify: the NTIA "mandate" role we are discussing here does indeed include in my view both conferring the responsibility through the contract (hence providing legitimacy) and the capacity to rescind or not reattribute it (what you label accountability). But in my 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.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Second, please do not put words in my mouth. I never said (nor meant) "<i>you have been doing a good job recently when you were accountable, so now you do not need to be accountable anymore</i>". I certainly do not mean no accountability, hence the questions I listed at the end of my message (see further comments below). I respect your arguments and try to understand and ponder them honestly. I expect the same in return. Otherwise there is no fruitful exchange. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">More precisely, you say: "<span style="color:rgb(31,73,125)">Periodic contracting is the only acceptable accountability mechanism on the table, imho. </span><span style="color:rgb(31,73,125)">There can be all kinds of oversight mechanisms but they are ineffective, even meaningless unless someone can pull the trigger on a contract.</span><span style="color:rgb(31,73,125)">" </span></font></div><div><span style="color:rgb(31,73,125)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">Where we disagree is on the necessary link you make between the two sentences. I fully support the second one: the possibility of "pulling the trigger on a contract" for mis-performance is indispensable. But my argument is that periodic re-bidding </font><span style="color:rgb(0,0,0)">of such contract </span><span style="color:rgb(0,0,0)">by one external entity (to be determined) is only one option and not the "only acceptable accountability mechanism" as you </span></font></div><div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><font face="arial, helvetica, sans-serif"><span style="color:rgb(0,0,0)">Other options (non-exhaustive list) include for example: </span><span style="color:rgb(0,0,0)">the right to denounce a permanent arrangement (as is the case with the Affirmation of Commitments), </span><span style="color:rgb(0,0,0)">a long duration arrangement with an expectation of renewal in the absence of fault (what is implemented in the new gTLD program), or a framework contract imposed upon a party with strong compliance teeth (remember the difficult negotiations of the Registrar AA). </span></font></div><div><span style="color:rgb(0,0,0)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><font face="arial, helvetica, sans-serif"><span style="color:rgb(0,0,0)">Furthermore, ultimate accountability does not need to come from a single point of authority. It </span><span style="color:rgb(0,0,0)">can be more distributed. For instance, i</span><span style="color:rgb(0,0,0)">f 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></font></div><div><span style="color:rgb(31,73,125)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><font face="arial, helvetica, 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. </font></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><div><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</div>
<div><span>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">Were the overall community to agree - in the course of these stewardship transition discussions - that this mission is conferred on a permanent basis to ICANN, a large
part of this problem goes away. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</span><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">MM: And so does accountability!! That will never be an acceptable solution to a large part of this community.</span></font></p></div></div></div></div></div></blockquote><div><br></div><div>I refuse the rapid link between "permanent mandate" and "no accountability" for the reasons above. Permanent organizations can be accountable, pending appropriate mechanisms. The two things are distinct. And should not be artificially linked. </div><div><br></div><div>More generally speaking, I have difficulty seeing why periodic re-bidding at short intervals would foster stability in the system more than a permanent architecture with sufficiently strong safeguards. </div><div><br></div><div>As for whether this could be acceptable to the community, let's not prejudge what the ultimate decision will be. 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? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><div><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">
<u></u><u></u></span></font></p>
</div><span>
<div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt"><u></u> <u></u></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">It would then transform into the following questions: <u></u><u></u></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">- who sets the SLAs for the three sets (in the case of this group, for the two names communities)? <u></u><u></u></span></font></p>
</div>
</span><div><span>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">- who controls performance vis-à-vis these SLAs? <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</span><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">MM: The whole concept of an SLA means, “I am selecting you to provide service, and if the service doesn’t meet the
standards in the SLAs, I will go elsewhere. Without that recourse of moving the contract, an SLA is not very meaningful.</span></font></p></div></div></div></div></div></blockquote><div><br></div><div>BPC: Milton, your response here conveniently omits the bullet points that followed in my post. They are enough to clearly confirm that a "recourse to move the contract" was clearly in my mind. I repeat them here for convenience:</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:12.6666669845581px">- what form do the corresponding arrangement(s) take?</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:12.6666669845581px">- who has the power to denounce the arrangement(s) for lack of performance? </div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:12.6666669845581px">- who (or what) could trigger a re-bidding of the entire arrangement or parts thereof? </div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div style="font-family:arial,sans-serif;font-size:12.6666669845581px">- what would be the exceptional procedure adopted in that case?</div></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><div><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">
<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</div>
<div><span>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12pt">The situation is similar to the discussion on functional versus structural separation. The last IANA contract has established a useful functional separation and I sense
that the community is keen on strengthening it, which seems legitimate and strongly agree with. Some, including you in particular, would prefer a completely separate entity.
<font color="#1f497d"><span style="color:rgb(31,73,125)"><u></u><u></u></span></font></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</span><p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Not any more. The main point of having a separate entity was to enhance accountability. If you can enhance accountability
by periodically recontracting the IANA functions, all you need is functional separation in the short term.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></font></p>
</div>
</div>
</div>
</div>
</div>
</blockquote></div><br></div><div class="gmail_extra">BPC: I now understand better the link you make between the two components (separation and recontracting) and welcome the evolution in your thinking. But for the reasons above, I do not think that periodic recontracting is the <u>only</u> solution that could provide accountability to a level sufficient to stay with the functional separation. </div><div class="gmail_extra"><br></div><div class="gmail_extra">I hope this clarifies and helps. Happy to continue the exchange. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Best</div><div class="gmail_extra"><br></div><div class="gmail_extra">Bertrand</div><div class="gmail_extra"> </div></div>