CCWG-Accountability: A Marrakech Wrap-up

By Aarti Bhavana

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

By Aarti Bhavana

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 6

By Aarti Bhavana

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/3^rd 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.”

2. 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.”

3. 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

By Aarti Bhavana

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.

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.

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

By Gangesh Varma

Recommendation 4

In the weeks leading up to the ICANN 55 Meeting at Marrakech, we are doing a series of posts tracking the CCWG-Accountability process. The first and second posts by Aarti Bhavana analyze Recommendations 1 & 2 and Recommendation 6  & 12 respectively. This third post in our series on the CCWG- Accountability recommendations will recap the discussions on Recommendation 4. The Empowered Community is vested with powers to ensure enhanced accountability and these are provided under Recommendation 4: Ensuring Community Involvement in ICANN Decision-making: Seven New Community Powers. These were designed to prevent domination of a single stakeholder or individual section of the community.

 Source: CCWG-Accountability Supplemental Final Proposal on Work Stream 1 Recommendations at page 22.

Recommendation #4: Ensuring Community Involvement in ICANN Decision-making: Seven New Community Powers

While the public comments largely supported the recommendation and the seven community powers, there was a call for greater detail and clarity. The key discussions following the public comment period on this recommendation have been focussed on three aspects.^[1] First, the issue of indemnification of community members in case of removal of Directors. Second the discussion on the power to reject the IANA Budget (IANA Budget veto power) and third the IANA Separation process. The discussion on the scope of Independent Review Panel (IRP) is closely connected to Recommendation 7: Strengthening ICANN’s Independent Review Process, and will be addressed in a separate post of this series.

Indemnification and Liability Mitigation in the Event of Removal of  Entire Board or Individual Directors:

One of the primary concerns raised with regard to these powers was that the removal of Board Directors runs the risk of litigation against community members. It was considered that there is a possibility that a Director who was being removed through this power vested in the community could sue members of the community for libel, slander or defamation. This would stall the process and restrict any utility of the provision. In order to prevent such liability, it was suggested that pre-service letters^[2] with a waiver of right to sue for statements made in the exercise of this power might be required. On the last call addressing this recommendation, the Board objected to the inclusion of a waiver and indemnification while it was supportive of the pre-service letters. The Board also confirmed that the requirement for a clear and written rationale for removal was not a restriction over the type of rationale under which the removal would be executed.  After extensive discussions, it was concluded that indemnification will be available

(i) to a member of a Supporting Organization, Advisory Committee, the Nominating Committee or the Empowered Community

(ii) who is acting as a representative of such applicable organization or committee

(iii) for actions taken by such representative in such capacity pursuant to the Bylaws (e.g., a chair of a Supporting Organization submitting a written rationale for the removal of the director)

It was further clarified that this indemnification will be available only if the actions were taken in good faith, and in a manner that the indemnified person reasonably believed to be in the best interest of ICANN.^[3] The specific guidelines for the standards of conduct such as good faith, due diligence etc. will be developed by ICANN. These details would ensure that even when the power of removal of directors is used, it will encourage and promote healthy discussions.

IANA Budget:

The power to reject the ICANN’s Budget or strategic/operating plans also includes the power to reject the IANA Budget. There were four main concerns with this aspect. First, the CWG-Stewardship in its comments sought for greater clarity in the process and criteria for exercise of this power (relating to budget transparency, grounds for rejection of a budget/plan, timing of budget preparation and development of the caretaker budget)^[4]. The 2nd draft proposal contained these clarifications, and the CCWG resolved this concern by  re-introducing the 2nd draft proposal text in the 3rd draft proposal. The second main discussion was on refining the role of operational communities in the IANA Budget veto power, taking inputs from the various stakeholders. The Internet Advisory Board (IAB), in particular, raised this issue and stated that it did not wish to alter the power in a manner in which the IETF had a direct voice in the budget.^[5] Upon further discussion, it was resolved by removing specific reference to the IETF, and inclusion of text referring to service level contractual obligations. The third concern was expressed by the Board that sought clarification on the IANA Budget within the context of this specific power, and made a proposal for a ‘caretaker budget’ to be operational so that ICANN can perform its functions on a day-to-day basis. While the finer details of the caretaker budget will be developed in the implementation process, the 3rd draft proposal requires it to be a public and transparent process. The fourth aspect for consideration was whether this ‘caretaker budget’ approach  should be embedded in the bylaws. The CCWG concurred with the Board’s suggestion that the ‘caretaker budget’ approach be embedded in the Fundamental Bylaws.

IANA Separation Process:

The Empowered Community is also vested with the power to reject ICANN Board decisions relating to the reviews of the IANA functions including the triggering of Post-Transition IANA Separation^[6]. The Board suggested that the recommendation should clarify that this is limited to the Names component of the IANA function. Additionally, CWG in its comments suggested the insertion of two conditions for greater clarity.  First, the right to reject Board decisions relating to reviews of IANA Functions can be applied by the Empowered Community an unlimited number of times. Second, the ICANN Bylaw drafting process and related Separation process will continue to include involvement by the CWG-Stewardship. Both these suggestions were incorporated in the recommendation at paragraphs 75 and 77 of the final draft of Annex – 04.

Scope of Community Independent Review Process (IRP):

The Empowered Community is also vested with the power to initiate a binding Community IRP. The circumstances^[7] under which this power may be used are listed as follows:

1. “Hear and resolve claims that ICANN through its Board of Directors or staff has acted (or has failed to act) in violation of its Articles of Incorporation or Bylaws (including any violation of the Articles of Incorporation or Bylaws resulting from action taken in response to advice/input from any AC or SO).
2. Hear and resolve claims that PTI through its Board of Directors or staff has acted (or has failed to act) in violation of its contract with ICANN and the CWG-Stewardship requirements for issues related to the IANA naming functions.
3. Hear and resolve claims that expert panel decisions are inconsistent with ICANN’s Bylaws. Hear and resolve issues relating to DIDP decisions by ICANN which are inconsistent with ICANN Bylaws.
4. Hear and resolve claims initiated by the Empowered Community with respect to matters reserved to the Empowered Community in the Articles of Incorporation or Bylaws”

In the 3rd Draft Proposal, this power is accompanied with the option of filing a Request for Reconsideration.  One of the main suggestions regarding limiting the scope of the Community IRP was to confine its applicability to the names community excluding the numbers and protocol community. Additionally, another key concern raised was with regard to the threshold for initiating this right and to prevent parts of the community affecting decisions relating to policy development processes. This discussion is closely related to Recommendation 7 and will be discussed in a separate post of this series.

—

^[1] The key discussions on this recommendation were on calls #74, #75, #76, #77, #78, #79 and #82.

^[2] Pre-Service Letters in this context refer to letters signed prior to taking the position of Director on the ICANN Board. In this case, the proposition was that such letter would include a waiver of the right to sue when this Power was used by the Community Member.

^[3]  The final readings of this text was on call #83.

^[4]http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009308.html

^[5]http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160106/f7a04bfd/Recommendation4-BudgetIANA-0001.pdf See comment w6 at paragraph 22.

^[6] As per Annex 04 at page 4: “ If the CWG-Stewardship’s IANA Function Review determines that a Separation Process for the IANA naming functions is necessary, it will recommend the creation of a Separation Cross Community Working Group. This recommendation will need to be approved by a supermajority of each of the Generic Names Supporting Organization and the Country-Code Names Supporting Organization Councils, according to their normal procedures for determining supermajority, and will need to be approved by the ICANN Board after a Public Comment Period, as well as by the Empowered Community”

^[7] See   Paragraph 71 of the Annex 04 at page 22.

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

By Aarti Bhavana

Recommendations 6 & 12

In the weeks leading up to the ICANN 55 Meeting at Marrakech, we are doing a series of posts tracking the CCWG-Accountability process. The first post in this series, analysing Recommendations 1 & 2, can be read here. This post examines Recommendation #6: Reaffirming ICANN’s Commitment to Respect Internationally Recognised Human Rights and Recommendation #12: Committing to Further Accountability Work in Work Stream 2. It also studies the process of developments in these recommendations, since the 3rd draft proposal was opened for public comments.

Recommendation #6: Reaffirming ICANN’s Commitment to Respect Internationally Recognized Human Rights

The 3rd draft proposal recommended reaffirming ICANN’s commitment to human rights through two bylaws: one, a draft Bylaw which would clarify ICANN’s obligation to respect internationally recognised human rights, and the other, an interim bylaw that would commit to the development of a framework of interpretation for the implementation of the draft bylaw.  However, this approach was met with some resistance.

a. Human Rights and the ICANN Board

In its comments, the Board stated that while it is ‘committed to upholding human rights’, it disagreed with the staged approach proposed in the 3^rd draft proposal. It feared that the proposed language could be used to expand ICANN’s obligations and increase the risk of unintended consequences such initiating the Independent Review Process (IRP) or litigation on human rights grounds. Leaving issues open until the approval of the Framework of Interpretation (FOI) could result in courts and binding IRP decisions creating precedent for what ICANN’s rights commitments are. A rather surprising aspect of the Board’s comments was the reference to evaluate this recommendation on grounds of Global Public Interest,^[1] if its objections were not addressed.

The Board suggested holding off on a human rights bylaw until the FOI was approved. It also recommended developing a Human Rights Statement with the community, in a top-down manner.^[2] Crucial details such as whether a human rights commitment should be included in the bylaws or elsewhere would be discussed in Work Stream 2.

b. A shot at a compromise

Shortly after receiving the Board’s comments, the CCWG-Accountability attempted to understand the objections made, particularly with reference to Global Public Interest. Some viewed the Board’s response as a way to strong-arm the CCWG into a position acceptable by it, while others worked on ways to address these concerns without altering too much of the original text. Further, contrary to the Board’s position, the CCWG lawyers clarified that the language in the 3rd draft proposal would not create additional legal risks.

Against the backdrop of these discussions, the calls^[3] set out three ways of moving forward:

1. Continuing with human rights commitment in Work Stream1 (roughly the 3rd draft proposal approach),
2. Deferring the discussion to Work Stream 2 (the Board’s approach), and
3. A compromise position of including a bylaw, which would take effect only after the FOI was approved (dormant bylaw).

In an effort towards cooperation, the co-chairs invited members and participants to consider option C (dormant bylaw), as it was a compromise between the Board’s position and the language set out in the 3rd draft. This was met with some disagreement, as it was felt that CCWG and WP4 had together agreed on option A when it was included in the 3^rd draft proposal, and this work should not be disregarded.

In response to the Board’s objections and in the midst of much confusion over the options, it was decided that 3rd draft proposal language will be modified to make the bylaw dormant until FOI is approved. This would address the Board’s concerns over IRP and litigation risks as well, since the bylaw would not be effective until the framework of interpretation was adopted. There was consensus for the compromise option. However, the Board remained steadfast in its position of supporting option B, evoking quite a bit of frustration within the CCWG community. It was decided that unless the Board came up with a bylaw statement acceptable to the community, this compromise language would be finalised.

c. Necessity of inclusion of the HR bylaw

While comments received during the public comments period were largely supportive of the inclusion of human rights, few raised concerns about including a human rights commitment prior to the completion of the Framework of Interpretation, and some felt that this matter should be pushed to Work Stream 2. Another issue raised by a few was that a human rights commitment didn’t belong in the bylaws.

The large majority in favour of including the human rights commitment explained that in the absence of the NTIA oversight, there was no backstop for human rights obligations unless ICANN made such a commitment. This commitment was considered essential to satisfy the NTIA criteria of maintaining the openness of the internet. It was also felt necessary to include this commitment in Work Stream1 as an assurance that the work would continue in Work Stream 2.

Amidst much relief, the Board shifted its position and proposed bylaw language similar to the text agreed by the CCWG-Accountability. After a final call discussing this proposed language, CCWG accepted the Board’s proposal and the recommendation has been finalized. Final drafting is left to the lawyers, and the CCWG breathes a collective sigh of relief as the human rights commitment has been secured.

Recommendation #12: Committing to Further Accountability Work in Work Stream 2

The 3rd draft proposal proposed certain accountability topics for Work Stream 2- a timeline that extends beyond the IANA transition. These topics included mechanisms to enhance ICANN’s transparency, improve diversity at all levels, jurisdiction and accountability, developing a framework of interpretation for the bylaw on human rights, and enhancing the Ombudsman’s role and function. It also proposed an interim bylaw committing ICANN towards implementing CCWG-Accountability Work Stream 2 recommendations.

In its comments, the Board stated its concern over the interim bylaw requiring the Board to commit to implement the CCWG-Accountability Work Stream 2 recommendations in full, as it was felt that this commitment couldn’t be made without evaluating the recommendations first. It was also made it clear that while it supports Work Stream 2 efforts, this was limited only to the extent of the listed topics.

The discussion over this recommendation was fairly short,^[4] and it was the first to be finalised. The Board’s concerns were addressed through modifications to the Recommendation. Clarifications were made to the interim bylaw, ensuring that the Board’s obligations would be identical to those in Work Stream 1. The list of topics to be dealt with in Work Stream 2 has been limited to those listed. It was clarified that Work Stream 2 would follow rules similar to Work Stream 1: consensus recommendations would be endorsed by chartering organisations, and if 2/3rds of the Board agrees that a recommendation is not in the global public interest, it would have the option to initiate a special dialogue with the CCWG-Accountability.

Additionally, enhancing Ombudsman’s role and functions has been confirmed and elaborated for Work Stream 2, in response to public comments. Transparency of board deliberations have also been added, as suggested by NCSG in its comments. Finally, appropriate modifications are to be made to portions concerning human rights, keeping with the changes made to Recommendation #6, as detailed above.

—

^[1] In its Resolution in October 2014, the Board committed to following certain principles when considering CCWG-Accountability recommendations. One such principle was over Global Public Interest: if, by agreement of 2/3rds of the Board, it was decided that a particular recommendation was not in the global public interest, the Board would initiate a special dialogue with the CCWG over its concerns.

^[2] The Cross-Community Working Party on ICANN’s Corporate Social Responsibility to protect Human Rights (CCWP-HR) is currently working on providing inputs for this human rights statement, in the hopes that it will be developed through a bottom-up multistakeholder process.

^[3] This recommendation was discussed in calls #76, #78, #80 and #83.

^[4] This recommendation was discussed in calls #74 and #76.

 

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

By Aarti Bhavana

Recommendations 1 & 2

In the weeks leading up to the ICANN 55 Meeting at Marrakech , we are doing a series of posts tracking the CCWG-Accountability process. Through these posts we will be examining all the recommendations and trace their developments since the third draft proposal was opened to public comments late in December, 2015. A quick summary of the third proposal can be found here.  January has been an extremely busy month for CCWG-Accountability members and participants, who have participated in over 24 hours of calls and countless discussions on the mailing list, to finalise the draft proposal to meet the NTIA’s extended deadline of 30th September 2016.

This post examines Recommendation #1: Establishing an Empowered Community for Enforcing Community Power, which details the functioning of the Sole Designator as the Empowered Community, and Recommendation #2: Empowering the Community Through Consensus: Engage, Escalate, Enforce, which explains the process of decision-making within the Empowered Community. It also highlights the keys concerns raised in the public comments and by the ICANN Board, to  study the changes made to these recommendations over the past month.

Recommendation #1: Establishing an Empowered Community for Enforcing Community Power

Introduced in the third draft proposal, this Recommendation sets up the Empowered Community in the form of a Sole Designator (a shift from the sole member model). This entity consists of representatives of the participating Supporting Organizations (SOs) and Advisory Committees (ACs), who are known as Decisional Participants. The Sole Designator has the statutory right to appoint and remove an individual director or the entire Board of directors. In addition, the right to inspect was also included, to enable this entity to inspect ICANN financial records.

Through the public comments and subsequent conversations, the two most extensively discussed aspects within this recommendation have been inspection rights and the role of GAC within the Empowered Community.

(i) Inspection rights

In the third draft proposal, the CCWG-Accountability proposed to give to the Empowered Community an additional, non-statutory right in the form of the right to inspect. This right, normally available only to members under Section 6333 of the California Corporations Code, would allow the Empowered Community to inspect accounting books and records, as well as minutes of meetings of the Board and committees. The inclusion of this right was part of the compromise to shift from the membership model proposed in the first two drafts, to the designator model.  

In their comments to this proposal, the Board agreed with the inclusion of the right, but recommended limiting its exercise to an escalation process, as required for other community powers. According to this proposal, exercise of this right would require following the escalation path of ‘Petition-Community Forum-Decision’, with support from at least three decisional participants at the decision stage. Most of the community disagreed with this, as it was felt that this right needed to be simple since it is absolutely essential for accountability and transparency. Requiring a lengthy process of support from multiple decisional participants was thought to be unnecessary for the exercise of this right.

Through further discussions over the calls, the Board explained that it could support an inspection request from a single SO/AC in matters relating to financial records and books of accounts, but would need a higher threshold for more complex matters. It was finally settled that the single threshold would apply for accounting records, while a higher threshold of three decisional participants would be required for investigations. Accordingly, a distinction has been drawn between the right to inspect and investigation right.

Therefore, the right to inspect will not be given to the Sole Designator, but be made available to Decisional Participants alone. This clarifies the process of exercise of the power, as it can be invoked by any one of the five participating SO/ACs, without having to resort to the escalation process. The new investigation right, suggested by the Board in its comments, is reserved for more complex matters like fraud or mismanagement, and would give the community transparency in such investigations. This is a community power, and as mentioned above, requires support from three decisional participants. It shall be added as a fundamental bylaw.

However, it must be noted that these powers are different from the Document Information Disclosure Policy (DIDP), under which any individual can file a request.

(ii) GAC as a Decisional Participant

Another significant issue raised in the public comments was over the role of the Advisory Committees as decisional participants, GAC in particular. While GAC itself has not confirmed one way or the other whether it will participate in the Empowered Community, the CCWG members and participants have been discussing whether it should even be allowed the choice.

The NCSG has been very vocal about its position- allowing GAC to be a decisional participant would mean that it would have a decision-making role, something it does not have at present, and one never envisaged for this Committee. Concerns were expressed that this would change the structure of ICANN, making it a government-led body, which is in violation of NTIA criteria. This position has been supported by the GNSO comments as well.  Other members also raised similar concerns and felt that GAC should be an advisory member to the Empowered Committee.

However, several others, including members of the GAC, felt that the CCWG-Accountability is creating a new structure, and GAC should be allowed to participate in it, if it so chooses. Concerns were also raised over the effect of removing GAC from the decisional participants, as current thresholds for the exercise of community powers were calculated on the assumption that there would be five decisional participants. Without GAC, this would be reduced to four, which some felt could threaten the entire model.

During the last call, it was decided that GAC will be allowed to be a decisional participant, despite the opposition by some. Dissenting members will be given the option of expressing their views in a minority statement, as has been done in the past, as this recommendation has now been finalised.

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

Ushered in through the third draft proposal, this recommendation introduced the Triple-E Approach, which was developed in Dublin to institute a requirement for the ICANN Board to engage with the community on any key decision that could potentially invoke the use of the community powers, through the three-step process of engagement, escalation and enforcement. Engagement refers to a public consultative process to gather community input before the Board takes any action on certain issues. Escalation consists of a series of steps, as visualized below. These mainly include a petition, conference call, community forum and decision. There must be certain thresholds of community support to move from one step to the next. Enforcement shall be considered only if the ICANN Board does not comply with the empowered community’s decision to use a particular power.

Source: https://www.icann.org/en/system/files/files/draft-ccwg-accountability-proposal-annex-2-30nov15-en.pdf

(i) Escalation timelines:

Unlike the previous recommendation, this one has not been subject to much criticism or debate. However, one aspect of concern to the community was the tight timelines in the Escalation process, which many thought was unrealistic. As mentioned above, the third draft proposal described an escalation process consisting of a petition, conference call and community forum, following which the Empowered Community would decide whether to exercise the community power in question. Multiple steps packed into the Escalation stage meant very tight timelines to organise the community towards making these crucial decisions. Not wanting to stretch out the process by extending the timelines for each stage, a compromise was reached and the escalation steps were modified. Now, the Conference Call and Community Forum stages have been merged (i.e., Steps 3, 4 and 6 in the figure above), so a longer timeline is available for organizing the forum. The petitioning SO/AC still has the option of requesting a Conference Call to discuss the issue before the Forum. However, since the Community Forum will be a virtual meeting, much like the Conference Call, it was felt that the two steps would duplicate the process and could be merged to save time.

(ii) Lowering of thresholds:

The merging of the steps also resulted in the amendment of the table outlining the  threshold levels for the escalation process, to remove the Conference Call column. Resultantly, the threshold levels for deciding whether to organise a Community Forum have been lowered to the level previously required for holding the conference call, with two exceptions. One, in the case of the power to recall the entire Board, there is still a requirement of support from four decisional participants, with no more than one objecting. The Board was very clear that it would not support the lowering of thresholds for this power, as it thought that exercise of this power must require full community support. Second, the power to approve changes to the fundamental bylaws only requires support from 3 decisional participants at the decisional stage, to provide a stronger protection to the fundamental bylaws. Therefore, if the Board approves a certain change in the fundamental bylaws, it would not pass unless at least three decisional participants also support this change.

(iii) Defining future thresholds:

Public comments also reflected the need to explain how the threshold levels will change in the event of a change in the number of decisional participants, for example, if one of the current decisional participants choose to not participate any more, or if the RSSAC, SSAC or any new SO/AC created wants to join as a decisional participant. The Board recommended that threshold levels be converted to percentages, to be applied when the number of decision participants changes in the future. However, members have expressed concerns that converting number thresholds to percentages could result in creating a higher or lower threshold than intended, depending on the number of participating SOs/ACs. The Board’s suggestion has been included as an option open to the Empowered Community if and when a new SO/AC is created (or removed).

Public comments also sought explanations for terms such as ‘engagement’ and ‘resolution’, which have now been provided. This modified recommendation has been suitably modified by the CCWG-Accountability legal counsel, and now awaits final comments from members and participants of this working group. We will keep you updated about the developments over the coming days, as this recommendation is finalised.