<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=utf-8">
<meta name="Generator" content="Microsoft Word 12 (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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m not sure who would do the approval, given the liability implications. This is why there needs to be a robust appeals mechanism based on whether the decision
is in line with the agreed policy. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The problem of approval is that the approvals body then seems to have a say over the decision – which in its own right can bring in (in the case of ccTLDs,
but the same would apply to many geo-TLDs) a judgement from outside the interested community and would still be open to challenge.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">An appeals body could be seen to do the same thing, but in this case it is clearly identified as independent and with expertise in making such calls.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I for one would be very concerned about an approval function that brought in what essentially would look like a kangaroo court into this process and one which
would be open to liabilities that it could not respond to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MB<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cwg-rfp3-bounces@icann.org [mailto:cwg-rfp3-bounces@icann.org]
<b>On Behalf Of </b>Gomes, Chuck<br>
<b>Sent:</b> 25 November 2014 18:56<br>
<b>To:</b> Milton L Mueller; 'Camino.MANJON@ec.europa.eu'; 'cwg-rfp3@icann.org'<br>
<b>Subject:</b> Re: [CWG-RFP3] Brief comments after Frankfurt<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I still need to be convinced that the approval function for a delegation or re-delegation is not needed, but I open to being convinced. Even if
the approval function is fairly straightforward in confirming processes and technical checks were done, it seems to me that it is a good check point before delegation/re-delegation. I assume that the IANA functions operator would do this but I believe it
shouldn’t be left to that operator alone. I should also add that I think that this could be done in fairly short order, i.e., one or two days max.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I strongly support what Camino says in item 6.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Chuck<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:cwg-rfp3-bounces@icann.org">cwg-rfp3-bounces@icann.org</a> [<a href="mailto:cwg-rfp3-bounces@icann.org">mailto:cwg-rfp3-bounces@icann.org</a>]
<b>On Behalf Of </b>Milton L Mueller<br>
<b>Sent:</b> Tuesday, November 25, 2014 11:33 AM<br>
<b>To:</b> 'Camino.MANJON@ec.europa.eu'; 'cwg-rfp3@icann.org'<br>
<b>Subject:</b> Re: [CWG-RFP3] Brief comments after Frankfurt<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Comments in line below:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span lang="EN-US" style="font-family:"Calibri","sans-serif";color:black">2) The IANA functions document dated 19 Nov includes 5 functions, being the first the "Approval function of changes to the root zone".
</span><span style="font-family:"Calibri","sans-serif";color:black">It could be made clearer in the CWG proposal how the new architecture addresses this verification-authorisation role. The current flow-chart also does not include Function 5 (backstop fx).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MM: My impression from reading the transcripts was that it was decided there was no need for the approval function. This is a conclusion
I would agree with. The appeals mechanism seems to eliminate the need for it. <o:p>
</o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span lang="EN-US" style="font-family:"Calibri","sans-serif";color:black">4) In the appeals panel, it could be clarified that both the IANA Customer Standing Committee and the Periodic Review Team can initiate
an arbitration procedure if the operator does not agree to implement recommendations. Is otherwise pulling the plug on the contract the only remedy? How are instructions or recommendations coming from the customers and the multi-stakeholder body enforced?
</span><span style="font-family:"Calibri","sans-serif";color:black">As the flow-chart shows now it seems that the only impact of the Customer Committee and of the subsequent escalation to the Review Team towards any issue of suboptimal performance of the operator,
has to do with changes in the contract. If the IANA operator is, for instance, interpreting policy and implementing on its own account, how do customers or the review team enforce any decision to stop the operator and how is the operator activity put on hold
pending resolution of a conflict? <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MM: These are very good questions. I do not know how to answer them, based on the materials coming out of Frankfurt. The proposal
should have clear answers to them. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-family:"Calibri","sans-serif";color:black">5) As regards the contracting function, we tend to favour the opinion of colleagues who have noted that there needs to be (i) a limited term for the
contract; (ii) an open and transparent beauty contest (RFP); and (iii) no presumption or renewal of the contract to provide performance incentives.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MM: I am happy to see this, and I think it would be advisable to get general agreement on these criteria before we start debating
whether the renewal period is 3, 5 or 6 years. ;-)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-family:"Calibri","sans-serif";color:black">6) As regards what some members and participants have echoed in respect to the two processes (accountability and IANA transition) being interrelated
and interdependent, the straw mans included some useful wording in this sense and it may be useful not to dismiss it: "The transition must not take place until (1) the requisite accountability mechanisms have been identified by the CWG on Enhancing ICANN Accountability
(“Accountability CCWG”), (2) mechanisms that the community determines are necessary pre-transition have been put in place and (3) agreements and other guarantors are in place to ensure timely implementation of mechanisms that the Accountability CCWG decides
may be implemented post-transition". <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MM: On point (1), just to be clearer, you might want to specify “…the requisite accountability mechanisms have been identified
by _<i>Track 1</i>_ of the CWG on Enhancing ICANN Accountability….” <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Track 1 refers to those parts of the CWG that are supposed to be specified before the transition.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:10.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>