1. Agenda CWG-Stewardship Meeting - 27 March, 2015 in Istanbul 09:00 – 09:15 Introduction / overview of agenda 09:15 – 09:45 Further questions on legal 09:45 – 13:00 Review & test models 13:00 – 14:00 Lunch break 14:00 – 16:15 DTs - status & development 16:15 – 16:30 Coffee break 16:30 – 17:00 Timeline 17:00 – 17:30 Wrap up All times in local time (UTC+2) 1

2. 2 Further Questions on Legal

3. CWG Proposed Structures External Solutions –Contract Co. –Trust Internal Solutions –Accountability mechanisms with functional separation –Trust Hybrid/Integrated Model –IANA subsidiary (“affiliate”) of ICANN with possible future services agreements (a.k.a Accountability mechanisms with legal separation) –Standalone IANA entity 3

4. Our Principles CWG ‘key elements’ from legal scoping document 1.Maintaining “separability” (i.e., the ability to replace ICANN as the IANA Functions Operator in the event of significant performance failures, and through the potential of RFPs at the end of a contract term (or a similar fixed term of years)). 2.Continuing to have binding documentation of ICANN’s duties and obligations as the IANA Functions Operator and the rights and obligations of the NTIA’s successor (currently set forth in the IANA Functions Contract). 3.Maintaining separation between ICANN’s performance of the IANA functions and ICANN’s policy coordination and implementation role. 4.Creating effective independent review and redress mechanisms for instances where ICANN’s performance of the IANA functions fails to adhere to documented policies and/or applicable rules. 5.In the event of a change of IANA Functions Operator, ensuring that interactions between ICANN (as the policy source for gTLDs) and the new Operator maintain the stability and continuity of the IANA Functions. 4 NTIA Requirements A.Support and enhance the multistakeholder model; B.Maintain the security, stability, and resiliency of the Internet DNS; C.Meet the needs and expectation of the global customers and partners of the IANA services; and, D.Maintain the openness of the Internet. E.…NTIA will not accept a proposal that replaces the NTIA role with a government-led or an inter- governmental organization solution. Other Issues? I.Capture II.Diversity of community (gTLDs and ccTLDs)

5. 5 EXTERNALINTERNALHYBRID Contract CoExt. TrustAcc. Mech.Int. Trust IANA Subsidiary IANA SharedStandalone CWG Maintaining “separability” Continuing binding documentation Maintaining separation IANA funct/ICANN policy Effective ind. review and redress mechanisms Ensuring interactions ICANN and new Operator NTIA Support and enhance MSM Maintain security/stability/resiliency Meet needs and expectation customers of IANA Maintain openness of the Internet Non-gov-led or inter-gov org solution OTHERS _ _ _ _ _ _ Can the model support the principle? Possible Answers: Yes, No, No Impact, Don’t Know

6. External > Contract Co. 6 ProsCons Clear separability This model moves stewardship in advance of moving the function Contract is status quo Clearly implementable (we know that a contract can be signed with ICANN) Avoids creating a single point of failure (distributed among orgs) Contract Co was intended to be a conduit, not the oversight itself (MRT was oversight) Long chain of decision-making Accountability of Contract Co. Creates new entity (ref. NTIA) It is confusing to have an external entity decide on a contract ‘between ICANN and ICANN’ (in current structure with ICANN as IANA Functions Operator) Implementation and Accountability issues should the IANA function be moved This model moves stewardship in advance of moving the function Untested steward Response to the Public Comment 1 (December 2014) Financial weight of the Contract Co. Long chain of decision-making This model as stated does not provide the benefits of any functional or structural separation Complex Contract Co was intended to be a conduit, not the oversight itself (MRT was oversight) Concern: impact on other communities

7. Internal > Accountability Mechanisms with functional separation 7 ProsCons It is status quo in the sense that ICANN as the IANA Functions Operator Golden Disaster Recovery Plan (GDRP) Accountability mechanisms can be put in place at ICANN CCWG-Acct mechanisms can create the accountability necessary Ensures the stability of the IANA Functions Op for those who need it most It would guarantee that ICANN’s accountability would improve (and have spillover effect on policy and whole system) By not having the “spin-off” you are more likely to fix the problem with a RFP. NTIA perceived to favor an internal model If you decide to fully separate (as opposed to outsource) the IANA Function at some future point, additional corporate restructuring would be required (and such work is likely to be at a time of difficulty/stress) Need to nail down the mechanisms that gives effect to the “teeth” in this model (while there is a notion that there is a mechanism for separability, it’s not clear today) Dependent on ICANN accountability enhancements (accountability mechanisms are unclear and undefined) No contract may mean no place for documentation of operational requirements, oversight or separation (both other models have place for a contract)  Reduces transparency REWRITE Who can decide to separate? SO/ACs are not incorporated (see CCWG-Acct’s work on ‘empowered community’) Significant change to the status quo in the sense that we abolish the need for a contract Diversity of service to gTLDs and ccTLDs is not clear (contracts or not) Increases the CWG’s dependence on CCWG-Acct (might slow those projects down)

8. Hybrid/Integrated > IANA subsidiary (“affiliate”) of ICANN with possible future services agreements (a.k.a Accountability mechanisms with legal separation) 8 ProsCons Separability is well-defined and “ready to go” if needed Maintains the stability of the current status (ICANN as IANA Functions Op) Creates an external oversight by virtue of contract (lessens dependency on accountability mechanisms) Creates a clear pathway (through the affiliate) that the other two customers of the IANA function could use (at any time) to come together Increase the transparency of the IANA Operator Remove the perceived “conflict of interest” of the ICANN board (policy/operations) Benefits from ICANN’s financial weight and accountability processes It takes more work to get started (the actual drawing the line around the IFO) Create a governance structure / replicate Requires discussion with other communities or needs to be specified Doesn’t answer how to make the decision of reassignment of the IFO  for both of the internal models Greater isolation from management Diversity of service to gTLDs and ccTLDs is not clear (contracts or not) Dependent on ICANN accountability enhancements (accountability mechanisms are unclear and undefined) REWRITE Significant change to the status quo in the sense that we abolish the need for a stewardship contract