All, we have discussed that we need to work on our messaging and document more what we have done. I have tried to write up an introduction to such document, which focuses more on what we build on and keep rather than on the changes. This is meant to start our discussion on how to present our work. At the end, you will only find headings where our work results need to be explained. As you know, the content of the document will need to be rephrased depending on what our final recommendations will look like. Nonetheless, we need to start working on this now. Best, Thomas The Multi Stakeholder Model is what makes ICANN unique and successful in managing a global resource that is essential for running the Internet. Security, stability and resiliency of the Internet unique Identifiers System are the focus of ICANN’s efforts. Since ICANN’s inception, the Supporting Organizations and Advisory Committees, who form the ICANN community, have developed and matured the policy development processes that, when necessary, set the rules that balance the interests of market players, end users and policy makers. The policy development includes public comment periods to ensure all interested parties globally can be heard and that their suggestions can be incorporated. Until today, the US Government has played a key stewardship role in ICANN’s governance. Not only has it obliged ICANN of its duty to regularly review and improve its accountability and transparence, but it also had the opportunity to find another contractor for the IANA functions. While the US government never had to make use of this power, its role has been rightfully characterized as a backstop by many. The CCWG Accountability has been tasked with working on consensus recommendations to enhance ICANN’s accountability for a post-transition era and to offer accountability enhancements that efficiently safeguard ICANN against contingencies, i.e. to replace the historic relationship with the US Government. The CCWG Accountability has analyzed carefully the accountability mechanisms that already exist in ICANN. It has carefully analyzed community input as well as criteria published by NTIA for accountability enhancements and transformed those to a list of requirements for improving ICANN’s accountability. Is has then considered different models and measures to implement and operationalize these requirements, it has listened to the advice of independent experts on corporate governance and accountability as well as independent legal advisers. It has discussed the pros and cons of different models and now suggests accountability enhancements that require least change, least unintended consequences while fulfilling the accountability requirements to the best possible extent. By nature, the focus of the group’s work was on identifying the need for change or amendment. However, it is important to also highlight what the group did not change. - Policy development in ICANN as well as the adoption of policies by the ICANN Board remain unaltered. - The unique advisory role of the Governmental Advisory Committee and the interaction on such advice with the ICANN Board remains unaltered. - The structure, decision-making and way SOs and ACs operate, remains unaltered. - The balance of power of the SOs and ACs is maintained. In order to preserve ICANN’s bottom-up, community-driven multi stakeholder approach, the recommended accountability enhancements include: - specifying ICANN’s role and mission and make it more robust against change to avoid mission creep and keep ICANN focused on its current mission - perpetuating the ATRT reviews required by ICANN’s current Affirmation of Commitment with the US Government, to ensure ICANN continuously works on its improvement - enhancing the Independent Review Process as an independent judiciary assessing whether ICANN operates in compliance or in violation of its bylaws. While strengthening this process the CCWG ensured that the IRP would not be empowered to circumvent the bottom-up nature of the policy processes. The IRP powers are strictly limited to confirming or cancelling ICANN’s decisions and it has no mandate to enforce specific outcomes on these decisions. These enhancements shall provide a basement and framework of enhanced trust and clear limits of what the organization can and cannot do. They ensure that ICANN follows the multi stakeholder model and follows bottom-up consensus-driven processes. In case of issues and contingencies, the CCWG has worked on a nuanced repertoire of community powers so that the community can choose the least invasive measure in case of alleged or actual wrongdoings. While all of the community powers could ultimately be enforced in court, the group has installed safeguards to make it highly unlikely this will ever be necessary. The community powers and the escalation processes for these are very nuanced to ensure they cannot be abused by individual groups or interests. Additionally, there is only a limited number of community powers. These 5 powers are relating to the - budget, strategic and operating plan - changing standard bylaws - changing fundamental bylaws, i.e. those bylaws that shall be made more robust against change (e.g. the mission, commitments and core values) - removing individual directors and - recalling the entire board Four out of five community powers only provide the community with a right to jointly exercise a right to ask the Board to redo a board decision or to veto a decision. Under no circumstances can the Community take decisions itself, let alone overturn the bottom up policy processes. The ICANN Board already engages with the community before adopting a budget. The ICANN Board already engages with the community before it adopts changes to bylaw provisions. This approach remains the same and it will rather be strengthened as an efficient consultation decreases the need for the community to step in after a resolution has been passed. The Community would only need to step in case, for instance, the Board adopts a budget that does not sufficiently fund the operation of the IANA functions, or if a strategic plan approves new activities inconsistent with ICANN’s Mission. Before a community power can be exercised, at least one of ICANN’s existing structures (SOs or ACs) are required to petition for it. Also, different thresholds of support for the execution of the community power are required. A higher degree of community consent is required for recalling the entire board than for vetoing a strategic plan. The only community power that prevents the board from taking a decision before obtaining community approval is related to changes to fundamental bylaws. The CCWG Accountability is of the opinion that changes to ICANN’s mission, commitments and core values or changes to the independent review process, amongst others, i.e. the main pillars of ICANN’s accountability and governance, shall not be changed without very strong consensus within the Board as well as within the community. While mission creep needs to be prohibited, there might be the need for ICANN to adjust to a changing environment. However, the cornerstones of what grants security, stability and resilience of the DNS must get special protection. What is common for all community powers is that the level of support for the execution of a community power must always be close to what would be called „rough consensus“ in a consensus call. Only it is more specified by embracing this notion in a voting scheme giving all existing groups the same level of relative influence as they have today. As explained above the voting scheme proposed by the CCWG only happens in extreme cases, as a last resort check and balance, and is not empowered to replace the bottom up, consensus based processes that is at the basis of ICANN’s core processes. After community wide discussion has taken place, the voting happens within the existing, well tested SO and AC structures, thus avoiding the creation of any new body. Finally, the SO and ACs themselves will be subject to regular reviews of their accountability and transparency practices, to ensure that they remain accountable to the communities they are designed to represent. In sum, the community powers do replace the backstop the US Government has provided so far. These need to be made enforceable as a matter of last resort. In order to make them fully enforceable, a legal person is required for the community to be used as a vehicle for exercising the community powers. Again, the CCWG Accountability is building on existing structures. ICANN is incorporated as a membership organization, but currently does not have any members. Therefore, the CCWG Accountability recommends - to rely on ICANN’s existing strucure as a membership organization rather than changing it, - to only have the community as the one and only member, - to ensure no part of the community gets exceeding rights (either by the ability of pushing through their individual interests or blocking community consensus), and - to ensure the community can only jointly exercise rights, mostly based on consensus. Hence no single SO or AC can exercise community powers or other statutory rights. The community as a whole is empowered to replace the role of the US Government. The CCWG Accountability believes that this truly empowers the Multi Stakeholder Model, relying on each stakeholders within existing and tested structures, in their respective roles. Even more, the CCWG Accountability believes that this community driven model is the only eligible candidate for replacing the historical relationship with the US Government. Finally, it shall be noted that in order to ensure proper checks and balances and a division of powers amongst the legislative (community), executive (ICANN Board), constitution (bylaws) and judiciary (IRP), enhancements to the accountability of the community are also suggested so that rogue players or interests inside the community cannot jeopardize ICANN and its operations. The whole proposal, as further described has been legally assessed by two independent expert law firms and successfully stress tested against various contingencies. [here comes the part that we need to work on] In the following chapters, we present I. an overview of the proposed accountability enhancement, II. an explanation of each component recommendation for of the proposed accountability architecture III. a rationale for i. why we are suggesting the changes ii. what alternative solutions have been discussed iii. why preference was given to the proposed solution iv.. why we are suggesting the changes at this time v. how we propose to deal with the interim phase until the accountability enhancements are fully implemented. IV. Omnibus volume of appendices and supporting documentation In the appendices, you find previous reports, legal assessments, the analysis of public comments received and information on the genesis of the proposed accountability enhancements.