<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 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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle18
{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: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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The answer to this Chuck seems obvious to me. We are not tasked with _<i>changing</i>_ ICANN’s status as policy authority, but any intelligent IANA transition
plan should require IANA to continue to accept ICANN as its policy authority, should it not?
<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 have not had time to read this entire thread, but that is how I interpreted Malcolm’s comment.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I believe that ensuring that a new IANA follows ICANN policy is a critical part of the transition, especially if we achieve separability. <o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></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"><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"> cwg-rfp3-bounces@icann.org [mailto:cwg-rfp3-bounces@icann.org]
<b>On Behalf Of </b>Gomes, Chuck<br>
<b>Sent:</b> Tuesday, November 18, 2014 3:31 PM<br>
<b>To:</b> Guru Acharya; Malcolm Hutty<br>
<b>Cc:</b> RFP3<br>
<b>Subject:</b> Re: [CWG-RFP3] Policy authority<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Guru/Malcolm,<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">Please show me where in the CWG charter we are tasked with doing anything with regard to the Policy Authority.<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">Chuck<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"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span 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>Guru Acharya<br>
<b>Sent:</b> Tuesday, November 18, 2014 3:52 AM<br>
<b>To:</b> Malcolm Hutty<br>
<b>Cc:</b> RFP3<br>
<b>Subject:</b> Re: [CWG-RFP3] Policy authority<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Excellent point Malcolm. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think this also raises an issue of recursiveness. If the members of the Oversight Body are drawn from ICANN's (the incumbent Policy Authority) organisational structures (SO/AC), and this Oversight Body chooses to change the Policy Authority
in the IANA Functions Contract, then it would automatically dissolve the legitimacy of the incumbent members of the Oversight Body. This would lead to a transition phase where both the membership of the Policy Authority and the Oversight Body are to be reconstituted,
possibly a risky situation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, I agree that the Policy Authority should not be immutable or perpetually granted to ICANN.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Guru<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Nov 18, 2014 at 1:08 PM, Malcolm Hutty <<a href="mailto:malcolm@linx.net" target="_blank">malcolm@linx.net</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Dear all,<br>
<br>
I hope I have not come too late to this party to participate. I have<br>
carefully read the mail archive before posting.<br>
<br>
Before I dive in with my suggestions, I have a question regarding<br>
Strawman 2 and Strawman 3. Both these strawmen envisage that the IANA<br>
Functions Contract would continue, with two different types of new<br>
entity as the counter-party to replace NTIA, "PROC" and "PROSI". Both<br>
these strawmen entertain the the possibility that someone other than<br>
ICANN could be awarded the IANA Functions Contract.<br>
<br>
My question is this: in the event that the new counter-party (PROC or<br>
PROSI) placed the IANA Functions Countract with a new operator, would it<br>
be open to the counter-party to direct the IANA operator to a new source<br>
of policy authority for gTLDs?<br>
<br>
The existing policy authority of ICANN derives from paragraph C.2.9.2.d<br>
of the IANA Function Contract, which states:<br>
<br>
* C.2.9.2d Delegation and Redelegation of a Generic Top Level<br>
* Domain (gTLD) -- The Contractor shall verify that all requests<br>
* related to the delegation and redelegation of gTLDs are consistent<br>
* with the procedures developed by ICANN. In making a delegation or<br>
* redelegation recommendation, the Contractor must provide<br>
* documentation verifying that ICANN followed its own policy framework<br>
* including specific documentation demonstrating how the process<br>
* provided the opportunity for input from relevant stakeholders and was<br>
* supportive of the global public interest. The Contractor shall submit<br>
* its recommendations to the COR via a Delegation and Redelegation<br>
* Report.<br>
<br>
This paragraph appears to be of core importance. As I understand matter,<br>
it is this paragraph which gives ICANN policy authority over gTLDs as a<br>
practical matter: subjective claims about community support may explain<br>
why the NTIA chose to grant ICANN this authority, but that community<br>
will was only given effect through this paragraph.<br>
<br>
So my first question is, do the current strawmen (2 & 3) intend that<br>
this provision be a fixed and wholly immutable provision of any future<br>
IANA Functions Contract, or could ICANN be replaced by the counter-party<br>
(either at-will or in defined circumstances)?<br>
<br>
I would like to point out that this is not explicitly clear from the<br>
strawmen as drafted, and that is a weakness that should be addressed.<br>
My sense is that you intend it to be immutable, and I do consider that<br>
problematic, but before diving into why I would like to confirm your<br>
intentions (and discover whether there is an existing consensus on this<br>
point).<br>
<br>
<br>
Malcolm.<br>
<br>
--<br>
Malcolm Hutty | tel: +44 20 7645 3523<br>
Head of Public Affairs | Read the LINX Public Affairs blog<br>
London Internet Exchange | <a href="http://publicaffairs.linx.net/" target="_blank">
http://publicaffairs.linx.net/</a><br>
<br>
London Internet Exchange Ltd<br>
21-27 St Thomas Street, London SE1 9RY<br>
<br>
Company Registered in England No. 3137929<br>
Trinity Court, Trinity Street, Peterborough PE1 1DA<br>
<br>
<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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>