<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Greg for putting together this variant.<br>
<br>
I don't see this as the return of the Contract Co model which was a
completely separate structure - this variation of the legally
separated affiliate model offers far greater predictability and
certainty. <br>
<br>
I support further consideration of this variation by our legal
advisers and also wanted to highlight two key points at the end of
Greg's e-mail:<br>
<br>
<i><span id="OLK_SRC_BODY_SECTION">While structural separation of
the IANA Functions operations does make a certain kind of future
total separation easier (spinning off the current IANA Functions
Operator within ICANN), this is really the less likely form of
total separation. The more likely form of total separation
would be the selection of a new IANA Functions Operator, and
that right would be structurally separated from ICANN.
<br>
<br>
More importantly from an operational perspective, the oversight
and stewardship over the operations of the IANA Functions would
be structurally separated from ICANN. It would be firmly in the
CSC, the PRT and the multistakeholder board. This would be the
primary job of the Affiliate, putting service accountability
front and center. Yet, it does not slight separability.</span></i><br>
<br>
Matthew<span id="OLK_SRC_BODY_SECTION"></span><br>
<br>
<div class="moz-cite-prefix">On 4/14/2015 8:59 AM, Client Committee
List for CWG wrote:<br>
</div>
<blockquote cite="mid:D1528670.1097D%25maarten.simon@sidn.nl"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Hi Greg (and Paul),</div>
<div><br>
</div>
<div>Isn’t this this simply the return of contract co ? And didn’t
we in Istanbul decide to leave this further aside a it was quit
clear that there was not much of support for it?</div>
<div><br>
</div>
<div>Maarten</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Client Committee
List for CWG <<a moz-do-not-send="true"
href="mailto:cwg-client@icann.org">cwg-client@icann.org</a>><br>
<span style="font-weight:bold">Reply-To: </span>"<a
moz-do-not-send="true" href="mailto:cwg-client@icann.org">cwg-client@icann.org</a>"
<<a moz-do-not-send="true"
href="mailto:cwg-client@icann.org">cwg-client@icann.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday 14 April
2015 07:41<br>
<span style="font-weight:bold">To: </span>"<a
moz-do-not-send="true"
href="mailto:cwg-stewardship@icann.org">cwg-stewardship@icann.org</a>"
<<a moz-do-not-send="true"
href="mailto:cwg-stewardship@icann.org">cwg-stewardship@icann.org</a>>,
Client <<a moz-do-not-send="true"
href="mailto:cwg-client@icann.org">cwg-client@icann.org</a>><br>
<span style="font-weight:bold">Subject: </span>[client com]
The Reverse Hybrid Model<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">All,<br>
<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Paul Kane among
others has suggested a variation on the current
"internal" models. Rather than quashing it, I thought
it was proper to give it appropriate consideration. As
Paul is traveling, I thought I would put this together
so that it could be given such consideration.
<br>
<br>
For the sake of convenience, I'm calling it the "Reverse
Hybrid Model."<br>
<br>
In this model, ICANN would still be the source of the
right to perform the IANA Functions, as in the current
internal model. However, ICANN would enter into an
irrevocable agreement with the Affiliate for the IANA
Functions. Rather than having the right to perform the
IANA Functions itself, the Affiliate would be given the
right to contract for an entity to act as IANA Functions
Operator. (Thus, the Affiliate would be set up as a
supervisor, not as an operator.) Initially (but not
perpetually), that subcontracted entity would be ICANN,
the current IANA Functions Operator. However, the
Affiliate would have the option, under the circumstances
designated by the CWG, to separate the performance of
the IANA Functions from ICANN (e.g., by issuing an RFP
and enter into an agreement with a third party).<br>
<br>
As with the current internal models, ICANN Corporate
would be the only member of the Affiliate. The
multi-stakeholder community would (s)elect the
independent Board of the Affiliate, which would have a
limited (and defined) scope.<br>
<br>
It may appear that ICANN is granting a right to itself,
through the Affiliate. However, the key is that the
Affiliate would have the oversight and stewardship
responsibility over the IANA Functions, by exercising
the rights and powers it has under the agreement with
the IANA Functions Operator. In other words, the
Affiliate would be the contractor with oversight of
ICANN-as-IANA Functions Operator, and would also have
the right to exercise escalation rights, up to and
including issuing an RFP and potentially a contract to a
third party if the designated triggers warranted it.
The CSC and the PRT would be activities of the
Affiliate, created by bylaws of the Affiliate, with a
multistakeholder board providing oversight over the CSC
and the PRT and ultimately over the IANA Functions
Operator (initially, ICANN-as-IANA). <br>
<br>
Under the irrevocable agreement, ICANN would retain
"ownership" of the IANA Function Operator rights but the
Affiliate would (irrevocably) hold the right to
subcontract for the performance of those services.
Although ICANN would be the only member, we would need
to insure that its rights as the member to override the
Board were as limited as possible.<br>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
While this does not structurally separate the IANA
Function operations from the rest of ICANN, it does
separate the stewardship and the decision-making
rights regarding the performance of the operations
from ICANN. As with the second option under the
current hybrid proposal, there would be functional
separation of the IANA Function operations from the
rest of ICANN.
<br>
<br>
While structural separation of the IANA Functions
operations does make a certain kind of future total
separation easier (spinning off the current IANA
Functions Operator within ICANN), this is really the
less likely form of total separation. The more likely
form of total separation would be the selection of a
new IANA Functions Operator, and that right would be
structurally separated from ICANN.
<br>
<br>
More importantly from an operational perspective, the
oversight and stewardship over the operations of the
IANA Functions would be structurally separated from
ICANN. It would be firmly in the CSC, the PRT and the
multistakeholder board. This would be the primary job
of the Affiliate, putting service accountability front
and center. Yet, it does not slight separability.<br>
<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">I believe this
proposal has sufficient merit to warrant due
consideration. One of the reasons we have engaged
Sidley is so that we can understand the viability and
desirability of various models and mechanisms (and so
I and other don't have to "play lawyer"). In that
spirit, I am forwarding this model to both the CCWG
and the Client Committee so that this "Reverse Hybrid"
model can be appropriately considered.<br>
<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Speak to you
all in a few hours, as dawn rises over New York City.<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Greg<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">
<div class="">
<div id=":27k" class="" tabindex="0"><img
moz-do-not-send="true" class=""
src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div>
</div>
<span class=""><font color="#888888"><br>
<br>
</font></span></div>
<br>
<br>
<br>
Kind regards to both<br>
<br>
Best<br>
<span><font color="#888888"><br>
Paul<br>
</font></span><br>
<br>
</div>
</div>
</div>
</div>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cwg-client mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cwg-client@icann.org">Cwg-client@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/cwg-client">https://mm.icann.org/mailman/listinfo/cwg-client</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Matthew Shears
Global Internet Policy and Human Rights
Center for Democracy & Technology (CDT)
+ 44 (0)771 247 2987</pre>
</body>
</html>