Draft of Principles and Criteria that Should Underpin Decisions on the Transition of NTIA Stewardship
Introduction
These principles and criteria are meant to be the basis on which the decisions on the transition of NTIA stewardship are formed.  This means that the proposals can be tested against the principles and criteria before they are sent to the ICG.  
a.	Security, stability and resiliency: changes must not undermine the operation of the IANA function and should assure accountability and objectivity in the stewardship of the service.
i. Transition should be subject to adequate stress testing; 
ii. Any new IANA governance mechanisms should not be excessively burdensome and should be fit for purpose; 
b.	Support the open Internet: the changes should contribute to the open and interoperable Internet.
c.	Accountability and transparency: the service should be accountable and transparent.  
i.	Transparency:  transparency is a prerequisite of accountability. While there might be confidentiality concerns or concerns over operational continuity during the process of delegation or redelegation of a TLD, the final decision and the rationale for that decision should be made public or at least be subject to an independent scrutiny as part of an ex-post assessment of service performance;
Unless prevented or precluded by confidentiality, any and all audit reports and other review materials should be published for inspection by the larger community;
ii.	Independence of accountability:  accountability should be independent of the IANA Functions Operator and should assure the accountability of the Operator to the inclusive global multistakeholder community;
iii.	Independence of policy from IANA:  the IANA Functions Operator should be independent of the policy processes.  Its role is to implement changes in accordance with policy agreed through the relevant bottom up policy process. (Note: this does not pre-suppose any model for separation of the policy and IANA roles. The current contract already requires such separation);
iv.	Protection against Capture: safeguards need to be in place to prevent capture of the service or of any oversight or stewardship function;
v.	Performance standards: the IANA Functions Operator needs to meet agreed service levels and its decisions should be in line with agreed policy. Processes need to be in place to monitor performance and mechanisms should be in place to remedy failures. A fall-back provision also needs to be in place in case of service failure; and
vi.	Appeals and redress: there should be an appeals process, which should be independent, robust, affordable, and timely, on decisions that include binding redress open to affected parties and open to public scrutiny. Appeals should be limited to challenging the implementation of policy or process followed, not the policy itself.
d.	Service levels: the performance of the IANA Functions must be carried out in a reliable, timely and efficient manner.  It is a vital service and any proposal should ensure continuity of service over the transition and beyond, meeting a recognized and agreed quality of service and in line with service-level commitments;
i.	Service level commitments should be adaptable to developing needs of the customers of the IANA Function and subject to continued improvement; and
ii.	The process should be automated for [all routine functions];
e.	Service quality should be independently audited (ex-post review) against agreed commitments.
f.	Policy based: decisions and actions of the IANA Functions Operator should be made objectively based on policy agreed to through the recognised bottom-up multi-stakeholder processes. As such, decisions and actions of the IANA Functions Operator should be:
i.	Predictable: decisions are clearly rooted in agreed policy and determined by the relevant policy body;
ii.	For ccTLDs, and in particular for delegation and re-delegation decisions, based on nationally agreed processes in accordance with national laws and in compliance with IETF technical standards where appropriate. Post transition of the IANA function nothing will be done by ICANN/IANA to impact the stable operation of legacy ccTLD Registries and gTLD Registries. The ccNSO is a policy authority within ICANN working in an open process with all ccTLDs, not only ccNSO members, although its authority is not universally accepted. For gTLDs, the policy authority is the GNSO;
iii.	Non-discriminatory;
iv.	Auditable (ex-post review); and 
v.	Appealable by significantly interested parties.
g.	Diversity of IANA’s Customers: 
i. IANA’s operations need to take account of the variety of forms of relationship between TLD operators and the IANA Functions Operator. The proposal will need to reflect the diversity of arrangements in accountability to the direct users of the IANA Functions; 
ii. For ccTLDs: the IANA should provide a service without requiring a contract and should respect the diversity of agreements and arrangements in place for ccTLDs. In particular, the national policy authority should be respected and no additional requirements should be imposed unless they are directly and demonstrably linked to global security, stability and resilience of the DNS.
iii. For gTLDs: the IANA function should continue to provide service notwithstanding any on-going or anticipated contractual disputes between ICANN and the gTLD operator. No additional requirements for prompt delivery of IANA services should be imposed unless they are directly and demonstrably linked to global security, stability and resilience of the DNS. 
h.	Separability:  any proposal must ensure the ability:
i.	To separate the IANA Functions from the current operator (i.e. ICANN) if warranted and in line with agreed processes; 
ii.	To convene a process for selecting a new Operator; and
iii.	To consider separability in any future transfer of the IANA Functions. 
i.	Multistakeholder principle: any proposal for a group to conduct oversight of the management of the IANA Function, whether by a committee or by a separate oversight mechanism, must draw its membership from a full range of stakeholders.