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)

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

4

Our Principles

CWG ‘key elements’ from legal scoping document1. 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.

NTIA RequirementsA. 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

EXTERNAL INTERNAL HYBRID

Contract Co Ext. Trust Acc. Mech. Int. TrustIANA Subsidiary

IANA Shared Standalone

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.Pros Cons

• 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

Pros Cons

• 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)

Pros Cons

• 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