Global Public Interest and ICANN

By Gangesh Varma

Global Public Interest is a difficult term to define. Any attempt to define it has always been met with resistance, or dissatisfaction. Yet, it features prominently in ICANN’s universe – through its bylaws, documents and contracts. In this post, I recapitulate the discussions surrounding global public interest within ICANN’s remit, the subject of a high interest session at ICANN 55 earlier this month.

Debates surrounding the term were revived during deliberations of the Cross-Community Working Group on Enhancing ICANN’s Accountability (CCWG-Acct). It was among the most difficult issues discussed due to diverging perspectives from various stakeholders. One of the recommendations of the CCWG-Acct is to embed the concept in the core values of ICANN’s bylaws as follows:

“Seeking and supporting broad informed participation and reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision making to ensure that the bottom-up, multistakeholder policy development process is used to ascertain the global public interest and that those processes are accountable and transparent.”[1] [Emphasis added]

ICANN’s struggle with global public interest is not new or isolated to the transition process. In 2013-14, a Strategic Panel led by Nii Quanyor examined this topic. The Report of the Panel attempted a broad definition of global public interest as follows:

“ICANN defines the global public interest in relation to the Internet as ensuring the Internet becomes, and continues to be, stable, inclusive, and accessible across the globe so that all may enjoy the benefits of a single and open Internet. In addressing its public responsibility, ICANN must build trust in the Internet and its governance ecosystem.”[2]

This broad and aspirational definition formulated by the Strategy Panel, did not receive complete support from the Community. However, it was not entirely rejected. This was the basis of further effort to source an understanding of the concept from the various departments within ICANN. The Development and Public Responsibility Programs Department at ICANN conducted a survey across the organization. It compiled resources and research on this subject to facilitate a discussion within ICANN’s multistakeholder Community i.e. the Supporting Organizations (SOs) and Advisory Committees (ACs).

Following this stock-taking, the session at Marrakech also updated the Community on a workshop organised on this subject at the Internet Governance Forum last year. The workshop discussed the idea of global public interest with reference to critical internet resources[3].  It highlighted the various traditional understandings of “in public interest” that is usually associated with developing regulation. It also focussed on the linkages between public interest and human rights including concepts like social justice, equal access, cultural diversity etc. It highlighted the regional perceptions of public interest and its possible contribution to conceptualizing ‘global public interest’. One of the key takeaways from the IGF workshop that resonated at the session in Marrakech was the idea that public interest is an aspirational goal, and cannot be fully achieved.

The diverging views are broadly in two categories. First, public interest as a concept that has a specific definition that can be articulated and achieved in each case. Second, is a broader perception of public interest. Here, it is perceived to be a purely aspirational goal, which must not be defined because it varies with context and is easily susceptible to exceed ICANN’s limited mission. While fears of such ‘mission creep’ are not unfounded, it must be noted that public interest appears not only in ICANN’s bylaws, but also as a criteria in some of its contracts. This compels a clearer and more tangible definition of the concept.

ICANN can take a two-prong approach to this challenge. First, is to pursue a definition for the broad aspirational goal that can be applied across its operations. As suggested during the session at Marrakech, the starting point could be definition of the Strategy Panel. This can be further refined and developed with the support of principles from the NETmundial meeting that were achieved through a global multistakeholder process. The Report titled “The Public Core of the Internet” is a resource that can help create the idea of critical internet resources as a global public good. This would protect the core infrastructure of the internet from unwarranted interventions by states or other stakeholders. Inspiration can be drawn from similar concepts in international environmental law, particularly that of the ‘common heritage of mankind’.  The second prong, would focus on key instances of specific use of public interest criteria in ICANN’s contracts and operations. Here, developing a tangible and functional definition using the inventory created is necessary. Lessons can be drawn from conceptualization of public interest in disciplines like international investment laws.

Currently, ICANN has turned to its SOs and ACs to consider this arduous task of defining global public interest. The idea of setting a Cross Community Working Group has been suggested, and a mailing list for discussions has been set up.The Wiki page  made is an invaluable resource for anyone to begin their engagement in this discussion.

[1] See page 5, and 19 of Annex 05

[2] See Page 4 of Report of Strategy Panel on the Public Responsibility Framework available here

[3] During the WSIS Process, the United Nations Working Group on Internet Governance described critical Internet resources as including the administration of the Domain Name System, the Internet Protocol addresses, administration of the root server system, technical standards, peering, and interconnection, as well as telecommunication infrastructure, including innovative and convergent technologies.

CCWG-Accountability: A Marrakech Wrap-up

With the final two chartering organizations confirming their approval yesterday, the co-chairs of the CCWG-Accountability sent the Final Report to the ICANN Board, which has now been transmitted to the NTIA. Today’s CCWG meeting outlined the work that lies ahead in the upcoming months.

Work Stream 1 recommendations will be implemented through the Budget Implementation Group and IRP Implementation Group. However, a majority of the work lies in Bylaws drafting, to ensure that the recommendations are accurately captured in the text of the new bylaws. The drafting and finalization of the bylaws are going to take place over the next few weeks, on a rather tight timeline. Though the final report has been transmitted to the NTIA, the review and assessment on that end will not be completed until bylaws implementing the Work Stream 1 recommendations are in place. Further, it is desirable that the NTIA-assessed report be submitted to the U.S. Congress before it goes on recess mid-July. Accordingly, the CCWG has set for itself a target timeline:

8 April: CCWG finishes draft bylaws

15 April: Open Public Comment for bylaws

15 May: Close Public Comment for bylaws

31 May: Board approves draft bylaws

Once this is completed, Work Stream 2 is expected to kick-off around June 2016. The work will be divided into subgroups on the themes of: Human Rights, Jurisdiction, Transparency, Diversity, SO/AC Accountability, Staff Accountability and Ombudsman. At present, the chartering organizations have been invited to re-confirm their appointed members, to ensure that they can take on the heavy workload that lies ahead.

As this historic meeting draws to a close, it must be remembered that the battle is far from over. While CCWG has completed a significant portion of its mandate, it must be emphasised that implementation details are crucial to this process. The importance of Work Stream 2 mustn’t be underestimated either, as each of those issues is critical to enhancing ICANN’s accountability.

A Marrakech update: CCWG-Accountability at ICANN55

The most discussed topic floating around the surprisingly chilly winds of Marrakech this week has been the CCWG-Accountability proposal. Over the past few weeks we traced the evolution of each recommendation of this Final Report, which was sent to all the chartering organizations for their approval. SSAC was the first to confirm its approval, even before the meeting started, with ASO quick to follow. ALAC has also ratified the entire proposal. The much-awaited response from GAC came last night, as it confirmed that it had no objection to the current proposal being transmitted to the ICANN Board. While GAC finally confirmed its (conditional) intention to participate as a decisional participant in the Empowered Community, it has not reached consensus on Recommendation 11 and the GAC ‘carve-out’ proposed in Recommendations 1 and 2. Finally, GNSO and ccNSO passed the report this afternoon, completing the process of approval from Chartering Organisations. The next few days will see the report being sent to the ICANN Board, to be transmitted to the NTIA for the final steps of the IANA transition. The Board has confirmed that it will do so immediately, without making any changes.

On the Road to Marrakech, Part 7

By Gangesh Varma

Recommendation #5:

The next post in our series tracking the development of the CCWG Accountability Proposal is on Recommendation #5: Changing Aspects of ICANN’s Mission, Commitment and Core Values.  The CCWG Accountability through Recommendation 5, proposed changes to the ICANN bylaws to ensure that the ICANN Bylaws reflect the measures proposed in the recommendations of the CCWG Accountability under Work Stream 1.

ICANN’s bylaws currently include its mission statement, a statement of core values and a non-discriminatory treatment provision. The comments from the community indicated that bylaws as it stands would need to be strengthened and enhanced. This was a necessary step to improve ICANN’s accountability to the global internet community and its stakeholders, a criteria set by the NTIA and a requirement of the ICG proposal.

Based on the comments and inputs from the community, the CCWG Accountability found that these existing provisions in the bylaws are weak and could lead to excessive discretion by decision makers within ICANN. It also noted that the current bylaws do not reflect the key elements of the Affirmation of Commitments. The CCWG Accountability recommended that ICANN’s mission statement be clarified to define its limited scope. It further observed that these changes once made to the bylaws should not be easily amended by the Board. Thus, the CCWG Accountability through Recommendation 5 proposed to modify ICANN’s mission statement, and to divide the Core Values into Commitments and Core Values. This Recommendation addresses numerous changes and each of these was extensively discussed and debated. Some of the key discussions on changes were around the following themes:

On Competition and Consumer Trust:

There was considerable interest in including consumer trust as part of the core values which can be illustrated through the comments of the ALAC (at pg.4) and the USCIB (at pg.5). The concept in the ICANN universe has its origins in the preamble of the AoC as a description of ICANN’s role and as a review commitment with respect to expansion of TLDs. Given this context of a limited application in its origin, the key consideration was whether this could be expanded into a generalised consumer trust obligation on ICANN. In order to understand the intention of the drafters of the AoC, the group sought clarifications from the NTIA. In response, it clarified that the reference to consumer trust in the AoC was limited to the expansion of new gTLDs. It was finally decided that the language of the 3rd Draft proposal will be retained, where core values will not refer to consumer trust but it will be included as part of the AOC reviews.[1]

On GAC Advice and Scope of ICANN’s agreements with contracted parties – Public Interest Commitments and Contract Provisions:

Comments from some governments and the GAC focussed on the effect that changes made under this recommendation will have on the Board’s ability to accept and implement GAC advice on aspects that affect public policy.[2] To address the concern of GAC members, the Commitments as envisaged under the Proposal provides  that ICANN shall employ open, transparent and bottom-up, multistakeholder policy development processes “while duly taking into account the public policy advice of governments and public authorities”.[3]  

The Board in its comments highlighted that while it would support the recommendations on core values and commitments, it would support modifying the Mission statement only with emphasis on clear and concise language. The Board’s concerns with the Mission statement were twofold. One, ICANN’s operational and policy role and second, contractual enforcement. The Board argued that the Mission Statement did not adequately reflect the operational role of ICANN, and focussed only on its policy development role. On the issue of contractual enforcement, the Board contended that the “grandfathering approach” and discussions relating to it resulted in text proposals that lacked clarity. While conceding that ICANN is not a regulator and should not regulate content, many comments also pointed out that the issues identified in the Registrar and Registry Agreements (the “picket-fence”) must be considered within the scope of ICANN’s Mission. This was reflected in the final proposal as part of the ‘note to drafters’.[4] Many comments expressed concern that the restrictive scope of ICANN’s Mission should not affect ICANN’s ability to negotiate, enter into and enforce agreements including public interest commitments (PICs) with contracted parties. In order to address concerns regarding Public Interest Commitments and other contract provisions in RAAs, etc. the CCWG clarified with a note on a ‘grandfathering approach’ to drafters. It also clarifies that grandfathered terms and conditions (including PICs) can be renewed until the expiration date of any such contract following ICANN’s approval of new/substitute form of Registry Agreement or RAA.

Global public interest was also among the many contested topics during the discussions. Addressing the myriad concerns that were raised, the CCWG proposal specifically provides that ensuring that a bottom-up, multistakeholder policy development process is used to ascertain the global public interest is one of ICANN’s core values. ICANN 55 has a special session on exploring the “public interest” within ICANN’s remit. This recommendation saw the amalgamation of some of the most crucial debates surrounding ICANN,and the transition. Recommendation #5 will be the foundation of ICANN’s future as it designs a legal framework within which the institution will operate.

[1] See transcripts of call #78. Discussions from pg. 54-61.

[2] See comments submitted by GAC, and most government comments to the 3rd Draft Proposal such as Denmark, New Zealand

[3] See the final text of Section2.5 of Commitments as provided in details of Recommendation 5 under Annex 05 at pg.11.

[4] As noted in Annex 05, the language proposed in this recommendation are conceptual in nature at this stage. The final language revising the Articles of Incorporation and Bylaws will be drafted by the ICANN Legal Team and external legal counsel.

On the Road to Marrakech: Part 6

Recommendation 11

In continuation of our series on CCWG-Accountability recommendations, this post examines one of the most controversial recommendation: Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18). Previous posts in this series can be read here. No other recommendation has seen this level of debate and compromise as Recommendation #11 has over the past year. There have been several new developments over the past few weeks, as has been traced below.

Recommendation #11: Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18)

The matter of GAC advice remains the most hotly debated issue in Work Stream 1, with discussions taking place as late as earlier last week.[1] The Governmental Advisory Committee (GAC) has a special advisory status in ICANN, which manifests in how the Board of Directors considers GAC advice on public policy. According to Article XI of the existing bylaws, if the Board takes a decision inconsistent with any GAC advice, it must state in writing the reasons for doing so, and then work with GAC to find a mutually acceptable solution. Stress Test 18 considers a scenario where the GAC changes its decision making process from consensus to majority voting. In such a scenario, the Board would be obligated to find a mutually acceptable solution even if the GAC advice achieved only a majority of votes. To mitigate these concerns, CCWG-Accountability recommended certain changes in the previous proposal, which have since been thoroughly debated and modified for the third proposal and again for the supplemental final report.

3rd draft proposal

In the 3rd draft, it was recommended that Article XI be modified to require trying to find a mutually acceptable solution only for advice supported by a full GAC consensus, and describes consensus to mean general agreement in the absence of formal objection, be included in Article XI. This ‘consensus’ clarification was added to ensure that the Board would only have to consider advice agreed upon by the entire GAC, and not find itself caught mediating between opposing governments. This recommendation also gave the Board an option to reject GAC advice, if this decision is supported by 2/3rds of the Board. However, this would not modify GAC’s ability to give advice at any time.

Public comments indicated support for the definition of consensus provided, and the requirement that GAC advice be supported by consensus. It also raised the need for GAC advice to be supposed by a rationale. Comments also objected to the 2/3rds threshold required from the Board to reject GAC advice, while others emphasised that the current operations of GAC should not be changed.

Clarifications

Starting with the less controversial issues, a few clarifications were made to address concerns raised in public comments. First, it was clarified that formal advice must be accompanied by rationale, and this requirement held true for all Advisory Committees, not just GAC. Second, it was categorically stated that while GAC advice is not restricted, the Board cannot take any action that is inconsistent with ICANN bylaws. Should the Board do anything inconsistent with the bylaws (even if acting on GAC advice), the Empowered Community would have the power to initiate an IRP against the Board. This provision is intended to limit the instances in which the Board is obligated to try to find a mutually acceptable solution.

Board threshold to reject GAC consensus advice

The only other matter left to be resolved is the one that was most discussed across several calls and hundreds of emails. Opinions were split on the 2/3rds threshold required for the Board to reject GAC consensus advice, with GAC members in favour of this higher threshold, while GNSO opposed it. For some vocal members of the GAC, retaining the 2/3rd Board threshold for rejection was the only way Recommendation #11 and Stress Test 18 would be acceptable to GAC. However, GNSO members argued that the CCWG 3rd draft, as a whole, was changing the role of GAC and expanding its power. Therefore, the 2/3rds threshold was considered too high.

This difference of opinion resulted in a deadlock, and the co-chairs decided to conduct a poll among the CCWG-Accountability Members, to take stock of their position on this Recommendation. Ultimately, that wasn’t necessary, as members and participants brainstormed ideas and two major proposals gained traction in the community: One suggested reducing the threshold for rejection to 60%, but many felt that this did not address the overarching concerns about GAC’s role in post-transition ICANN. The second proposal took these concerns into account, as it suggested modifying Recommendation 2 to the effect of giving GAC a purely advisory role in situations where the Empowered Community is discussing launching an IRP to challenge Board’s implementation of GAC advice. Two special meetings were scheduled,[2] to give the working group more time to discuss these new suggestions. During these calls, a third suggestion emerged, combining both the proposals, as neither satisfied all concerns independently. This compromise proposal suggested the following changes:

  1. Recommendation #1– Establishing an Empowered Community for Enforcing Community Power

Language was proposed to be added to explain the ‘GAC carve out’, to give GAC a purely advisory role when the Empowered Community was considering challenging the Board’s implementation of GAC advice:

“The GAC may not, however, participate as a decision maker in the Empowered Community’s consideration of the exercise a community power for the purpose of challenging or blocking the Board’s implementation of GAC Advice. In such cases, the GAC remains free to participate in community deliberations in an advisory capacity, but its views will not count towards or against otherwise agreed thresholds needed to initiate a conference call, convene a Community Forum, or exercise a specific Community Power. This carve out preserves the ICANN Board’s unique obligation to work with the GAC try to find a mutually acceptable solution to implementation of GAC Advice supported by consensus (as defined in Rec. #11) while protecting the community’s power to challenge such Board decisions.”

  1. Recommendation #2– Empowering the Community Through Consensus: Engage, Escalate, Enforce

The table defining thresholds required for the exercise of various powers would need to be modified to reflect that GAC cannot cast a decisional voice when considering the exercise of community IRP for Board action on the basis of GAC advice:

“The CCWG-Accountability also recommends that in a situation where the GAC may not participate as a Decisional AC because the community power is proposed to be used to challenge the Board’s implementation of GAC Advice and the threshold is set at four in support, the power will still be validly exercised if three are in support and no more than one objects.”

  1. Recommendation #11– Board Obligations with Regard to Governmental Advisory Committee Advice (Stress Test #18)

Finally, this recommendation would have to be modified to reflect the lower threshold of 60% for the Board to reject GAC consensus advice.

This compromise ‘package’ proposal was accepted by the group, with broad agreement. Specificities of this compromise proposal were clarified by the CCWG-Accountability independent legal team.

GAC carve out revisited

Just when it was thought that the proposal had been finalized, certain aspects of Recommendations 1 and 2 were reopened to discussion when the Board submitted its position on the GAC carve out, expressing concern over the reduced threshold of 3 SO/AC for exercising the power of recalling the entire Board. This discussion was reopened in the CCWG-Accountability and the members and participants were polled in the last call. Based on the polling, the co-chairs concluded that the lower threshold of 3 SO/ACs for removal of the entire Board would only apply if the community IRP concluded that in following GAC advice, the Board acted inconsistently with ICANN bylaws. This version of the proposal has been finalised.

The issue of GAC’s role in post-transition ICANN has been the subject of much discourse. The majority of the dissent seemed to have arisen not because of Recommendation #11 alone, but because of how the CCWG proposal as a whole dealt with the role of GAC: as a decisional participant in Recommendation 1 (discussed here), exempting it from accountability reviews in Recommendation 10 (discussed here) and finally, GAC consensus advice in Recommendation #11. While the supplemental proposal has been finalised, it isn’t without dissenters. Minority Statements have been included in this proposal to accurately represent the range of opinions of CCWG-Accountability Members, and the proposal now awaits approval from the Chartering Organisations.

[1] This recommendation was discussed in Meetings #73, #78, #79, #81, #82, #83, #85 as well as Rec-11 meetings on 4th February and 8th February 2016.

[2] Special Rec-11 meetings were held on 4th February and 8th February 2016.

CCWG Accountability: On the Road to Marrakech, Part 5

By Gangesh Varma

Recommendation 7

Continuing our series on tracking the CCWG Accountability Process, in our fifth post, we look at Recommendation 7 which concerns ICANN’s Independent Review Process. This post examines the key changes and developments since the 3rd Draft Proposal was opened for public comment.  Our previous posts can be found at this index page for the CCWG Accountability Blog Series.

Recommendation #7: Strengthening ICANN’s Independent Review Process.

Recommendation 7 attempts to strengthen ICANN’s existing Independent Review Process (IRP) to accommodate the changes post transition. ICANN’s IRP exists to ensure that ICANN does not exceed the scope of its mission, and operates within its Articles of Incorporation and Bylaws.  The public comments largely supported this recommendation while seeking clarification and details to avoid any gaps in the implementation. They key clarifications regarding this recommendation revolved around the scope of the IRP, Community IRP (related to Recommendation #4), and suggestions to be provided as implementation details to the Implementation Oversight Team (IOT).

Scope of IRP

The discussions regarding the scope of the IRP can be discussed as per the following changes from the 3rd Draft Proposal:

Inclusion of PTI

Inclusion of actions or inactions of Post Transition IANA (PTI):  The comments of the CWG-Stewardship indicated that the scope of IRP must be extended to appeals from direct customers of the IANA naming function that are not resolved through mediation.[1] It was decided that while the expansion of the scope to include the PTI is non-controversial it should be subject to the two conditions. First, it will be limited to the naming functions. Second, the standard of review for PTI cases will be an independent assessment of whether there is a material breach of PTI obligations under the contract with ICANN and this has resulted in material harm to the complainant.

Inclusion of DIDP Decisions

The idea that a denial of access to documents under DIDP can be escalated to an appeal through IRP was subject to considerable debate. The Board in its comments stated that reference to IRP to resolve under DIDP claims should be restricted to instances where such decisions violate ICANN’s bylaws as it currently does. It also suggested that the DIDP escalation path be made more robust and refined to involve a greater role for the Ombudsman under Work Stream 2. While DIDP processes are detailed in Work Stream 2, the CCWG agreed with the Board position and the final text of the recommendation specifically provides that the scope of IRP includes issues relating to DIDP decisions. However, it also specifies that this is restricted to cases where the DIDP decisions by ICANN are inconsistent with  the ICANN Bylaws.       

Exclusion of Protocol/Parameters Decisions

The Internet Advisory Board’s (IAB) comment to the 3rd Draft Proposal explicitly refused to support the recommendation unless it excluded the protocol/parameters decisions. It had stated in its comments to the 2nd Draft Proposal, that the protocol parameters community had a “well-tested appeals process” and that “a parallel process would be counter-productive” and in conflict with the Memorandum of Understanding between the IETF (including the IAB) and ICANN.

Limitation of challenge to Expert Panel Decisions

The Board in its comments had raised a concern with extending the IRP to challenge decisions of expert panels. It stated that IRP should not be used to challenge specific substantive operation decisions and such a measure would move away from the purpose of the IRP. Discussions during call #76 also highlighted the need to set up a process with respect to expert panel decisions and the need to be able to challenge the decisions where it is in conflict with the ICANN Bylaws. Eventually, the final text of Recommendation 7 provides that an IRP challenge to expert panel decisions would be limited to whether the panel decision is consistent with ICANN’s bylaws.  

Community IRP

The power to launch a community IRP is one of the seven powers of the Empowered Community provided under Recommendation #4. Certain details applicable to this power are clarified under Recommendation #7.

Legal Expenses

The first clarification was with regard to the legal fees in case of the Community IRP. Recommendation #7 clarifies that the legal expenses of the Empowered Community associated with the community IRP will be borne by ICANN. In his comment, Prof. Jan-Aart Scholte cautions that this arrangement might prompt a conflict of interest. He recommends that the financial resources be allocated to a trust fund which will be institutionally separate and this trust may administer the legal fees. This concern however is not addressed in the proposal, and may be considered by the Implementation Oversight Team.

Community IRP Challenging PDP

Recommendation #7 also provides an exclusive carve out language for a community IRP that challenges the result of a Policy Development Process (PDP). The exclusionary clause discussed during call #78 provides that no community IRP can be launched against the results of a PDP without the support of the supporting organization that developed such PDP. It also provides that the in case of joint PDPs, it would require the support of the supporting organizations that developed the PDP.  This language is also included in Recommendation 4.

While these are the key aspects in the development of Recommendation 7, a substantial amount of detail concerning its implementation will be addressed by the Implementation Oversight Team.  

[1] See paragraph 8 of Annex 07. It may be noted that the CWG-Stewardship Proposal dependencies also requires the ability to ensure PTI compliance through the IRP.

CCWG-Accountability: On the road to Marrakech, Part 4

Recommendations 3 and 10

As we fast approach the ICANN55 meeting at Marrakech, we continue our series of posts tracking the CCWG-Accountability process. Previous posts in this series can be read here, here and here. This post examines Recommendation #3: Redefining ICANN’s Bylaws as ‘Standard Bylaws’ and ‘Fundamental Bylaws’, and Recommendation #10: Enhancing the accountability of Supporting Organizations and Advisory Committees. It also studies the process of developments in these recommendations, since the 3rd draft proposal was opened for public comments.

Recommendation 3: Redefining ICANN’s Bylaws as ‘Standard Bylaws’ and ‘Fundamental Bylaws’

The 3rd draft proposal further refined the concept of fundamental bylaws by recommending the splitting of ICANN bylaws into ‘Fundamental Bylaws’ and ‘Standard Bylaws’. Fundamental bylaws are harder to change, and include the Mission, Commitments and Core Values, the seven community powers, and the framework for Independent Review Process, to name a few. Public consultations are to be undertaken before any changes are made to either standard bylaws or fundamental bylaws. Changes to fundamental bylaws would additionally require a 75% approval from the ICANN Board as well as approval from the community.

Untitled

Source: CCWG-Accountability Supplemental Final Proposal on Work Stream 1 Recommendations, Annex 03.

The Board was in support of this recommendation, since it formalized the involvement of the community in major bylaw changes. The public comments also supported the adoption of this recommendation, with no major issues raised.

The matters discussed in the calls[1] were more in the form of clarifications. It was clarified that the IANA Functions Review provisions only apply to IANA’s domain name management function, as part of the CWG-Stewardship requirements. Further, the Empowered Community has also been given the right to approve amendments to the Articles of Incorporation in a process similar to the one provided for fundamental bylaws, to ensure that fundamental bylaw provisions aren’t subverted by amendments to the Articles. CCWG-Accountability’s independent counsel also recommended that the Empowered Community be provided the right to approve the transfer of all or substantially all ICANN assets, to solidify the community’s say in important matters, including changing ICANN’s legal jurisdiction. Finally, the right to inspect and the right to investigate have been added as fundamental bylaws, in keeping with the changes made to Recommendation #1. The Articles of Incorporation will be suitably modified to reflect these changes.

The entire CCWG-Accountability process has been directed towards solidifying the Empowered Community’s powers, to ensure that ICANN and its Board are accountable to the Community. However, accountability cuts both ways, and with the set of new powers being given to the participating SO/ACs, it is necessary to ensure that these bodies are accountable and transparent themselves.

Recommendation #10: Enhancing the accountability of Supporting Organizations and Advisory Committees

The 3rd draft proposal provided for this to be implemented in a staged process. In Work Stream 1, this will be achieved by including the review of SO/AC accountability mechanisms in the independent structural reviews performed regularly. However, the bulk of this discussion shall take place in Work Stream 2, including the proposal to add SO/AC accountability to the Accountability and Transparency Review Process.

While public comments were largely in favour of this recommendation, the major concerns raised were (1) that GAC should be subject to the same accountability standards as the other organizations, and (2) that independent reviews should be done at the request of a majority of the SO/ACs, and any recommended changes should only occur with the approval of the Empowered Community. These concerns were echoed by the GNSO as well, and discussed in the calls.[2]

(1) GAC Accountability

The CCWG-Accountability proposed that SO/AC accountability be enhanced in Work Stream 1 by including, through an amendment, a review of its accountability mechanisms in the organizational reviews performed regularly. Article 4, Section 4 of the ICANN bylaws require periodic review of the SO/ACs, with the exception of GAC, which is permitted to provide its own review mechanisms. As mentioned above, public comments found this exclusion to be problematic. In its comments, the GNSO stated that since GAC is sought to be empowered through Recommendations #1 and #11, it should also be subject to the same accountability standards as other decisional participants. After some discussion, it was decided that the Accountability and Transparency Review will assess the role and effectiveness of GAC’s interaction with the Board as well as the ICANN community, and make suggestions on how this can be improved.

(2) Top-Down Accountability Review

Another concern raised was over the current manner of handling SO/AC review results, which was considered top-down, with unilateral control held by the Board. The GNSO felt that this would allow the Board to be involved in the governance structure of SO/ACs, and instead expressed a preference for a community-led review process in keeping with ICANN’s bottom-up model of governance. This would entail independent reviews being done at the request of a majority of SO/ACs, and recommended changes occurring only with the approval of the Empowered Community. However, the Board expressed concern over removing the Board’s role in approving recommendations, stating that this would affect the independence of the review process. It was finally decided that a detailed working plan shall be developed in Work stream 2, taking into account the comments made during the public comment period.

[1] This recommendation was discussed in calls #77 and #79.

[2] This recommendation was discussed in calls #79 and #81.