<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body>Reading this after being woken up at 02:50 am makes my head hurt!!!!!!!!!!!!<br>
-- <br>
Sent from my mobile. Please excuse brevity and typos.<br><br><div class="gmail_quote">On April 14, 2015 1:41:41 AM EDT, Client Committee List for CWG <cwg-client@icann.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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 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>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />Cwg-client mailing list<br />Cwg-client@icann.org<br /><a href="https://mm.icann.org/mailman/listinfo/cwg-client">https://mm.icann.org/mailman/listinfo/cwg-client</a><br /></pre></blockquote></div></body></html>