Civil Society and CCWG-Accountability: a report from IGF 2016

By Aarti Bhavana

The 11^th Internet Governance Forum (IGF) was held earlier this month in Guadalajara, Mexico. Established as a result of the Tunis Agenda, the IGF provides a space for discussing issues relating to the internet, where stakeholders can engage on an equal footing. Though it is not a decision-making forum, the IGF provides stakeholders the opportunity to share their work with others working in the same field.

CCG and the Non-Commercial Stakeholders Group (NCSG) organised a workshop that brought together active civil society participants from the IANA Transition to reflect on the process. The discussion was mainly centered around the Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), which has been summarised in this post. With a long line-up of panelists, this workshop touched upon issues that were important to civil society, as well as successes and failures that could help develop strategies for future engagement. While the transcript for this workshop is not available yet, the video recording can be viewed here.

It has been a little over two months since the IANA Transition was successfully completed. The CCWG-Accountability, formed to make recommendations on enhancing ICANN’s accountability, completed the first phase of its work before this. Known as Work Stream 1 (WS1), this phase dealt with all the topics that needed to be completed before transition could occur. Now, CCWG-Accountability has shifted its focus to Work Stream 2 (WS2) and is busy with 9 subgroups working on different issues that were left to be discussed after the transition. However, the IANA Transition was a historic event that brought with it a treasure trove of experiences, invaluable as a guide for future work. Drawing lessons from this experience would require taking a step back and looking at the process as a whole. Luckily, the IGF provides just such a space.

Key issues for civil society

When the IANA Transition was announced in March 2014, civil society was among the voices that demanded increased accountability and transparency of ICANN. As Robin Gross summarised, routine violations with bylaws, top-down policies, mission creep, staff interference and opacity were just some of the reasons for this push. The call for enhancing ICANN’s accountability received support across the board, and was something with which the US government also agreed. The concerns raised had more to do more with the accountability of policy-making processes than of the IANA Functions, Milton Mueller explained. Accordingly, the CCWG-Accountability was created where civil society actors from NCSG and (At-Large Advisory Committee (ALAC) were very active. As Gross stated, it was critical to get strong community powers in order to hold the Board of Directors accountable (such as right to recall board members, oversight over the budget, approval for bylaw changes, etc.). Accordingly, there was a constant push from civil society for stronger accountability measures, be it for the structure of the Empowered Community, the Independent Review Process (IRP), role of governments, human rights, staff and community accountability, or transparency. Many of these issues are still being discussed in WS2. However, as pointed out by Alan Greenberg, it must be remembered that civil society being a large collective of stakeholders with diverse interests, does not have a single agreed position on these issues.

Failures and successes

The various accountability issues are nuanced and complex, and require external experts to join the process. For example, transparency and human rights. However, joining these discussions pose their own set of challenges. As Matthew Shears summarised, many barriers to participation often seen at ICANN were also reflected in the CCWG-Accountability process as well, such as the high time commitment, language of acronyms, and the quick learning curve. Since this process required an understanding of how ICANN functions as a whole, these challenges became all the more significant. As a panelist, I noted that discussions often tended to be centralised around the same few people, which made it difficult for people to join the conversation. Additionally, Jan-Aart Scholte observed that the civil society participation was mainly from North America and Europe. He continued to discuss another significant challenge- the lack of complete openness. While the IANA transition and the CCWG-Accountability are lauded for proving that multistakeholderism can work, we must not ignore the politics involved. He highlighted that crucial discussions and deals took place behind closed doors, and were later presented at the publicly recorded calls, meetings and mailing lists. He also pointed out that civil society was on the sidelines when it came to these private discussions, which reduced its ability to influence the outcome, unlike the other stakeholders involved.

One of the biggest takeaways from this process was observing the bridging effect of a common goal. As Shears noted, this process saw diverse stakeholders talk through options when there were conflicting opinions, perspectives and interests. However, with the completion of the transition, the common goal has gone away and he observed that participants are now falling back into their stakeholder group “silos”.

Strategies for the future

While it may be a bit early to take a call on successes and failures, WS2 is still ongoing. It may be useful to try to replicate what went well, and learn from the challenges seen in WS1. Greenberg pointed out the utility of having regular informal discussions with members from other stakeholder groups in order to reach a compromise, something he recommended should be continued in WS2. The nature of the work being done by CCWG-Accountability requires finding a way to continue to work together, beyond just “looking for the lowest common denominator”, as Klaus Stoll suggested. Further, the range of issues being discussed in WS2 is diverse, and continues to require experts from outside the ICANN community to get involved. The strategy of clearly dividing the topics into separate issues was appreciated by Marilia Maciel, as it allows for easy identification of the different areas. She also pointed out that even though most of the discussion has been documented, it would be impossible to go through the tens of thousands of emails exchanged and hundreds of hours of calls. Drawing parallels with the effort required to understand the NetMundial Initiative retrospectively, she emphasised the need for documenting this process while it is still recent. CCG has attempted to do that over the past year, but the sheer volume of the discussions require more active participants to pen down their experiences and analysis to allow for a closer study later.

 

CCWG ploughs on with WS2: ICANN57

By Aarti Bhavana

With 3141 participants in attendance, ICANN57 (held from 3-9 November 2016) was the largest public meeting in its history. It was also the first meeting to be held after the successful completion of the IANA Transition. The transition greenlit the enforcement of the provisions of the IANA Stewardship Transition Proposal, which consisted of two documents: the IANA Stewardship Transition Coordination Group (ICG) proposal and the Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) Work Stream 1 Report. Our previous posts analysing these recommendations can be found here.

The meeting week was preceded by a full day face-to-face meeting of the CCWG-Accountability on the 2nd of November. The group met to continue its discussion on Work Stream 2 (WS2), which officially kicked off during the previous meeting in Helsinki. Rapporteurs from many of the WS2 Drafting Teams and subgroups presented updates on the progress of work in the preceding months. This post captures some of the key updates.

Jurisdiction

ICANN’s incorporation and physical location in California has long been a source of contention for governments and other stakeholders. Jurisdiction directly impacts the manner in which ICANN and its accountability mechanisms are structured (for example, the sole designator model arises from the California Corporations Code). Greg Shatan, co-rapporteur of the Jurisdiction subgroup presented an update document on the progress of this group. While the current bylaws state that ICANN shall remain headquartered in California, stakeholders were interested to see whether the subgroup would look into the matter of relocation. It was stated during this meeting that the subgroup has determined that it will not be investigating the issue of changing ICANN’s headquarters or incorporation jurisdiction. However, should a problem yield no other solution in the future, this option will then be examined.

A substantial issue found to be within the scope of this subgroup’s mandate is that of “the influence of ICANN’s existing jurisdictions relating to resolution of disputes (i.e., “Choice of Law” and “Venue”) on the actual operation of policies and accountability mechanisms”. The group’s working draft analysis of this issue can be accessed here. Another mandate from Annex 12 of the WS1 report requires the subgroup to study the ‘multilayer jurisdiction issue’. This has been discussed in some detail in the draft document, which can be accessed here.

One of the concerns raised during the discussion was that the subgroup would not recommend any change and conclude in favour of the status quo. Reassurance was sought that this would not be the case. The rapporteur stated in response that one cannot predict the outcome of the group as there are no internal preconceptions. It was also pointed out that since the discussion ran the risk of being purely academic, it was important to get external opinions. Accordingly, it was agreed that a survey would be sent out to hear from registries, registrars, and others. Advice will also be sought from ICANN Legal.

Transparency

ICANN has often been criticised for a lack of transparency in its functioning. This has largely been attributed to its hybrid structure, which is argued to not have the necessary active, passive, and participatory transparency structures. WS1 of the CCWG-Accountability attempted to address some of these concerns. The inclusion of inspection rights is one such example. However, a significant part of the work has been left for WS2.

This subgroup has made significant progress and shared the first draft of its report, which can be read here. This document discusses the right to information, ICANN’s Documentary Information Disclosure Policy (DIDP), proactive disclosures, and ICANN’s whistleblower protection framework. A suggestion was made to include requiring transparency in Board deliberations, which will be considered by the subgroup. There was also some discussion on increasing the scope of the proactive disclosures for greater transparency. Suggestions included disclosure of Board speaking fees and requiring disclosures of contracts of amounts lower than $1 million (the current threshold for disclosure) as well. There was also a discussion on ‘harm’ as an exception to disclosure, and the need to define it carefully. A revised draft of the report will be shared in the coming weeks, incorporating the points raised during this meeting.

Supporting Organisation (SO)/Advisory Committee (AC) Accountability

With the SOs and ACs being given greater powers under the Empowered Community, it is essential to ensure that they themselves do not remain unchecked. Accordingly, SO/AC reviews need to take place. This subgroup is tasked with the mandate of determining the most suitable manner of enhancing accountability. During this meeting, four identified tracks of activities were presented: (i) SO/AC effectiveness; (ii) evaluating the proposal of a ‘mutual accountability roundtable’; (iii) developing a detailed plan on how to increase SO/AC accountability; and (iv) assessing whether the Independent Review Process (IRP) should also apply to SO/AC activities.

Preliminary discussions have taken place on the first two tracks. It was decided that track 3 could not begin without some input from the SO/ACs. Accordingly, a list of questions was developed with the aim of better understanding the specific modalities of each organization. After a brief discussion, it was decided that this list would be sent to the SO/ACs.

Apart from these updates there was also a discussion on the Accountability and Transparency Review Team (ATRT) 3 and an interaction with the ICANN CEO.

ATRT3 and WS2:

During the Helsinki meeting, it was pointed out that the 3rd review of the Accountability and Transparency Review Team (ATRT3), scheduled to begin work in January, would have a significant overlap with WS2 topics (6 out of the 9 topics). After some discussion, it was decided that a letter would be sent to bring this to the attention of the ICANN Board. This letter also laid out possible ways to proceed:

1. Option 1- ATRT3 and WS2 work in parallel, with a procedure to reconcile conflicting recommendations.
2. Option 2- Delay ATRT3 until WS2 is completed.
3. Option 3- Limit the scope of ATRT3 to assessing the implementation of ATRT2. ATRT4 can then make a full assessment of accountability and transparency issues before 2022 (preferred path).
4. Option 4- ATRT3 continues with its full scope, with CCWG focusing only on the remaining issues. The ATRT recommendations could then be discussed by CCWG.

The Board’s response stated that while this was of concern, it was a decision to be made by the larger community, and brought it to the attention of the SOs and ACs. In Hyderabad it was decided that CCWG-Accountability will continue to follow up with the Board on this issue, while the SO/ACs deliberate internally as well.

Exchange with ICANN CEO

ICANN CEO Göran Marby’s meeting with CCWG-Accountability was arguably the most engaging session of the day. Central to this discussion was his recent announcement about a new office called the ICANN Complaints Officer. This person “will receive, investigate and respond to complaints about the ICANN organization’s effectiveness, and will be responsible for all complaints systems and mechanisms across the ICANN organization”. It was also stated that they would report to ICANN’s General Counsel. The last provision was not received well by members of the CCWG-Accountability, who stressed on the need for independence. It was pointed out that having the Complaints Officer report to the General Counsel creates a conflict of interest, as it is the legal team’s responsibility to protect ICANN. Though this was raised several times, Marby insisted that he did not think it was an issue, and asked that this be given a fair chance. This discussion was allotted extra time towards the end of the meeting, and there seemed to be a general agreement that the role and independence of the Complaints Officer needed greater thought and clarity. However, this remains the CEO’s decision, and any input provided by CCWG-Accountability will merely be advisory. It will be interesting to see whether he decides to take into account the strong concerns raised by this group.

The substantial discussions in WS2 are only just kicking off, with some subgroups (such as the Diversity subgroup) yet to begin their deliberations. The Transparency subgroup is making good progress with its draft document, on which CCWG-Accountability input is always welcome. It will be worth keeping an eye on the Jurisdiction subgroup, as this remains a divisive issue with political and national interests in the balance. Much remains to be done in the SO/AC Accountability subgroup, which is working to better understand the specific internal working of each SO/AC. This is an extremely important issue, especially in light of the new accountability structures created in WS1. CCWG-Accountability remains an open group that anyone interested can join as a participant or observer.

 

IANA Transition completed

By Aarti Bhavana

The much-discussed IANA transition has finally been completed, now that the U.S. Government’s contract with ICANN for IANA Functions has expired. This brings to an end the governmental oversight of these functions, a plan outlined back in 1998, and transfers it to a global multistakeholder community. The Centre for Communication Governance’s coverage of the transition over the last two years can be accessed here. In addition, our recent report on multistakeholderism discusses the role Indian stakeholders have played in ICANN over the last 5 years. It is a useful introduction to the way policy is made in ICANN’s multistakeholder model.

In March 2014, National Telecommunications and Information Administration (NTIA) under the U.S. Department of Commerce announced its intent to transfer the oversight of key Internet domain name functions to a global multistakeholder community. In the months that followed, working groups were set up to develop proposals both for the stewardship transition, as well for enhancing ICANN’s accountability. Both proposals were finalized and sent to the ICANN Board of Directors to be transmitted to NTIA. On 9^th June 2016, after careful evaluation, the NTIA announced that the proposals met the criteria outlined by the NTIA in March 2014.

Despite meeting all the requirements set out, the weeks leading up to today have been far from smooth. Last week, the U.S. Senate Judiciary Sub-committee held a hearing on “Protecting Internet Freedom: Implications of Ending U.S. Oversight of the Internet.” The opposition from the Republicans, led by Sen. Cruz, has also been supported by Donald Trump. There were also attempts to delay the transition by including a rider in the U.S. Government funding bill. This was ultimately not added, leaving the path clear for the transition.

However, in a dramatic twist two days ago, four U.S. states filed a lawsuit in Texas to block the transition. The motion for a temporary injunction was heard by the federal court a few hours ago, and denied. This officially brings a two year long process to a successful end. Many Indian stakeholders participated in the transition process as members of the multistakeholder community. However, as our report on multistakeholderism shows, there is scope for greater Indian engagement with ICANN and its policy processes.

In the midst of this celebration, it must be remembered that the work is not over. Efforts at increasing ICANN’s accountability are still ongoing with Work Stream 2, and consist of several critical topics like transparency, diversity and human rights that require the same level of effort as the transition. As discussed in our report‘s on ICANN Chapter, accountability is an issue on which ICANN has faced serious complaints in the past. The next stages of the transition offers stakeholders an opportunity to address these questions.

 

CCWG-Accountability WS2: An update

By Aarti Bhavana

In the weeks leading up to the finalisation of the CCWG-Accountability Work Stream 1 Report, we traced the evolution of each recommendation. While things have been quiet on the drafting front, there has been a lot of activity towards completing and implementing Work Stream 1 recommendations, to clear the path for Work Stream 2.

Over the past few months, the finalised IANA Stewardship Transition Proposal and the CCWG-Accountability Work Stream 1 Report were submitted to the ICANN Board, transmitted, to and approved by the NTIA. Alongside this, the bylaws were amended to reflect the changes recommended in the proposals, and these new bylaws were adopted as part of Work Stream 1 implementation.

With Work Stream 1 completed, the attention now shifts to the next set of topics that required further discussion, but weren’t urgent enough to need to be completed prior to the transition- Work Stream 2. The CCWG-Accountability face-to-face meeting at ICANN56 officially kicked off Work Stream 2, with a series of lightning talks aimed to introduce each topic. In the weeks since, dedicated subgroups have been created for each topic, with rapporteurs appointed to help facilitate the discussions. This post briefly introduces each topic and outlines what will be discussed in the months to come. Since the substantive work hasn’t started yet, this is a great time for those not following the process closely, to join in.[1]

Human Rights: The recently introduced human rights bylaw committing ICANN to respect internationally recognized human rights, will only take effect once a framework of interpretation (FOI) is in place to help inform how this bylaw is to be interpreted and implemented. This FOI shall be discussed and developed in Work Stream 2. This topic promises to bring forth some interesting discussions, as it was fairly contentious even at the stage of drafting the bylaw in Work Stream 1.

Jurisdiction: ICANN’s incorporation and physical location in California has long been a source of contention for governments and individuals alike. Jurisdiction directly impacts the manner in which ICANN and its accountability mechanisms are structured (for example, the sole designator model arises from the California Corporations Code). Over the coming months, this subgroup will analyse the effect of jurisdiction on ICANN’s operations and accountability mechanisms. While the current bylaws do state that ICANN will remain headquartered in California, it remains to be seen whether this subgroup will be tackling the issue of relocation. This multi-layered issue will be a controversial one, as it involves political and national interests.

Transparency: Accountability isn’t possible without transparency and the demands for greater transparency have only been increasing. This subgroup will be looking at improving transparency, with a focus on ICANN’s Documentary Information Disclosure Policy (DIDP), whistleblower policy, transparency of Board deliberations and ICANN’s interaction with governments.

Diversity: Public comments in Work Stream 1 highlighted the need for diversity to ensure better representation of the global internet community. Discussions in Helsinki showed that this issue isn’t going to be as simple as one might have thought. This subgroup will study the present diversity requirements and suggest improvements accordingly.

SO/AC Accountability: With the Supporting Organizations (SO) and Advisory Committees (AC) being given greater powers under the Empowered Community, it is essential to ensure that they themselves don’t go unchecked. Accordingly, SO/AC reviews will take place, and the subgroups will determine the most suitable manner of enhancing accountability based on various suggestions made, such as a mutual accountability roundtable.

Staff Accountability: In a similar vein of ensuring organizational accountability, WS2 will also be looking at staff accountability. Here, the subgroup will work on clearly understanding the role of ICANN staff in reference to the ICANN Board and Community. It will also work on developing a code of conduct, transparency criteria, training and independent audits. This work will tie in to the next subgroup on enhancing the Ombudsman’s role.

Ombudsman: Work Stream 1 already enhanced the Ombudsman’s role through the Request for Reconsideration process. In Work Stream 2, the subgroup will consider how to enhance the role of Ombudsman’s office, including evaluating the Ombudsman Charter, and recommend changes necessary for the adequate independence of this office.

While not considered separately at the time of Work Stream 1, there are two additional subgroups that will be working as part of Work Stream 2. The Guidelines on Good Faith Conduct in Participating in Board Removal Discussions subgroup will be looking at the removal of Board members and indemnity provisions. The Reviewing the Cooperative Engagement Process (CEP) subgroup shall be a continuation of improving the Independent Review Process (IRP), by reviewing the CEP, which is the first step of filing an IRP.

Timeline:

All WS2 topics will kick off simultaneously, but the timeline for discussions and output will depend on whether it has been identified as a ‘Simple’ or ‘Complex’ topic. The simple topics are expected to be short term, with public comment process in October. The complex topics will be more long term, with a public comment period in May and final report expected by June 2017. Whether a topic is simple or complex is something that needs to be communicated by the rapporteurs of each subgroup.

Simple Topics – Short Term

• June 2016: sub-groups agreed, commence work on docs for public input
• Aug 2016: first discussion with CCWG
• Sep 2016: refining work
• Oct 2016: CCWG agrees for public input
• 20 Oct-30 Nov: Public Input comment period
• Dec 2016: Analyze public comment staff/subgroups
• Jan 2017: Sub-groups refines and revises output
• Feb 2017: CCWG agrees final Output for consideration by community FOR ADOPTION at Copenhagen (ICANN58)

Complex Topics – Intermediate/Long Term

• Jun 2016: sub-groups agreed
• Sep-Oct 2016: first discussion with CCWG – identifies whether and how to update community at Hyderabad
• Nov-Dec 2016: second discussion with CCWG (first SUBSTANTIVE)
• Jan 2017: refining work
• Feb 2017: CCWG agrees docs for public input
• 1 Mar to 10 Apr: Public Input comment period
• Apr 2017: Analyze public comment staff/subgroups
• May 2017: Sub-groups refines and revises output
• May/Jun 2017: CCWG agrees final Output for consideration by community

[1]  To sign up as either an active participant or an observer in any of the Subgroups, a request can be sent to acct-staff@icann.org.

 

Heading into Helsinki: Core issues at ICANN56

By Aarti Bhavana

The upcoming 56^th ICANN meeting shall be held in Helsinki, Finland from 27-30^th June 2016. This is the first ‘Meeting B’ as per the new meeting strategy, which means a shorter, 4-day meeting focusing solely on policy work and outreach, and no public forum or public board meeting. A full schedule of this meeting can be found here. This post briefly highlights some of the core issues that will be discussed over the week.

CCWG-Accountability

On the Sunday before the meeting officially begins, the Cross-Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) shall be having a day-long open session to discuss accountability-enhancing topics that were left for Work Stream 2.

At the end of ICANN55, the chartering organizations and the ICANN Board approved Work Stream 1 recommendations. A detailed analysis of these recommendations can be found here. Along with the IANA Stewardship Transition Proposal, the CCWG-Accountability Work Stream 1 Report was then transmitted to the U.S. National Telecommunication and Information Administration (NTIA) to be reviewed. In the mean time, Work Stream 1 implementation was in full swing, with the ICANN Board passing a resolution to adopt the new bylaws, which were amended to reflect the changes recommended by the proposals. With this, the final step of the transition was completed from ICANN’s end. On June 10^th, it was announced that the proposals met the criteria set out by the NTIA, and was therefore accepted by the Executive Branch of the U.S. Government.

That being done, the focus now shifts to Work Stream 2 topics. These are a list of issues that are necessary to enhance ICANN’s accountability, but not deemed urgent enough to be completed prior to the transition. However, this is not to mean that these topics are any less important. One might even say that some of the most critical accountability issues have been left to be dealt with once the pressure of the transition has been lifted. Taking off from Helsinki, the work will be divided into subgroups on the themes of: Human Rights, Jurisdiction, Transparency, Diversity, SO/AC Accountability, Staff Accountability, Ombudsman, Guidelines on Good Faith Conduct in Participating in Board Removal Discussions and Reviewing the CEP.

Active Policy Development Processes (PDPs)

Since this meeting will be focusing on policy work within ICANN, the PDPs take on an extremely important role, with multiple sessions dedicated to discussing these issues. The three big PDPs to watch out for at ICANN 56 are:

• New gTLD Subsequent Procedures : This PDP was initiated by the GNSO after the closure of the first round of new gTLD applications. The aim was to evaluate and learn from the experiences of the first round, and make policy recommendations and changes for subsequent rounds. The process began with the setting up of a discussion group that identified issues and areas of policy development for subsequent procedures. This process then culminated in the preliminary issue report and the final issue report. The GNSO Council then passed a resolution to initiate the PDP and set up a working group. More information on this PDP can be found here.

• Next Generation gTLD Registration Directory Service (RDS) : This Board-initiated PDP is the latest step in 15 years of efforts to develop a stronger WHOIS policy. WHOIS discussions usually revolve around issues of accuracy, purpose, availability, privacy, anonymity, cost, policing, intellectual property concerns and malicious use. This PDP will be analysing all these issues, with the aim of answering these questions- (1) what are the fundamental requirements for gTLD registration data; and (2) is there a need for a new RDS to replace the existing WHOIS policy. This work is expected to take place over three phases. More information on this PDP can be found here.

• Review of All Rights Protection Mechanisms in All gTLDs: Since the new gTLD Program, several new Rights Protection Mechanisms (RPMs) have been developed taking into account potential trademarks concerns that could arise from the increase of gTLDs: the Uniform Rapid Suspension Dispute Resolution Procedure (URS); the Trademark Clearinghouse (TMCH) and the associated availability through the TMCH of Sunrise periods and the Trademark Claims notification service; and the Post-Delegation Dispute Resolution Procedures (PDDRPs). This focus of this PDP is to conduct a review of all RPMs in all gTLDs in two phases: Phase One will focus on a review of all the RPMs that were developed for the New gTLD Program, and Phase Two will focus on a review of the Uniform Dispute Resolution Policy (UDRP). More information on this PDP can be found here.

Being the first of its kind, it will be interesting to see how well this new meeting structure works, especially in the absence of public sessions and public Board meetings. Watch this space for more updates from the meeting over the coming days.

ICANN and Human Rights

By Aarti Bhavana

The topic of human rights on the Internet has been one of significant interest, right from finding mention in the WSIS Declaration of Principles in 2003, to the UN Human Rights Council’s First Resolution on Internet Free Speech, which declared that the rights available to people offline must also be protected online. These have subsequently also been reaffirmed by UN General Assembly’s resolution on the right to privacy in the digital age, and the NETmundial outcome document, which called for human rights to underpin the principles of Internet governance.

However, the issue of human rights in the specific context of Internet architecture is one that has gained significant traction only in the recent past. As the entity responsible for the technical coordination of the domain name system (DNS), ICANN’s impact on human rights is not one to be underestimated. While it is a corporation bound by California corporate law, it also functions as a global governance body that develops Internet policy.^[1] As a result, a human rights study from an ICANN perspective not only includes the Universal Declaration of Human Rights (UDHR), International Covenant on Economic, Social and Cultural Rights (ICESCR) and the International Covenant on Civil and Political Rights (ICCPR), but also the UN Guiding Principles on Business and Human Rights (UNGP), which sets out corporate responsibilities to respect human rights.

ICANN policy processes and human rights

ICANN policies have a significant impact on internationally recognized human rights, such as freedom of expression, privacy, due process and freedom of association. There are also three major policy development processes (PDP) concerning issues with far-reaching human rights impacts:

New gTLD subsequent procedure: one of the biggest functions carried out by ICANN is deciding when to introduce new gTLDs^[2] After the first round of new gTLD applications, a review was undertaken to determine whether adjustments needed to be made for subsequent application procedures. This PDP will examine the set of issues identified from the experiences of the 2012 round of new gTLD Program and address related policy concerns. The will also include looking into various issues which will have substantial human rights impact, such as the freedom of expression, freedom of association, economic and social rights, and privacy.

Next-Generation gTLD Registration Directory Services to Replace Whois: also known as new WHOIS, next-gen WHOIS or WHOIS2, this PDP is the culmination of over 15 years of efforts to address the many issues related to gTLD registration data. The collection and public access to registration data has long been a cause for concern, and this PDP will have to focus on data protection and the right to privacy.

Review of all Rights Protection Mechanisms (RPMs) in all gTLDs: this PDP shall be assessing the effectiveness of the Rights Protection Mechanisms for all gTLDs, such as Uniform Dispute Resolution Policy (UDRP), Trademark Clearinghouse (TMCH) and Uniform Rapid Suspension 
Procedure (URS), among others. The right to freedom of expression and due process are directly impacted by RPMs, and any review must take this into account.

The IANA Transition

Apart from the individual policy processes, there has also been some work on developing an overarching human rights framework for ICANN. The IANA Transition, expected to take place in September of this year, required an enhancement of ICANN’s accountability and transparency. This involved several discussions on ICANN’s principles, values and mission, which led to a discussion of human rights.^[3] Article 4 of the Articles of Incorporation commits ICANN to “carrying out its activities in conformity with relevant principles of international law and applicable international conventions and local law.” Whether this includes international human rights instruments, is open to interpretation, and there was a demand for the bylaws to be amended to explicitly reflect human rights principles. The Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) worked on developing a human rights bylaw that explicitly commits ICANN to respect internationally recognized human rights. The bylaw language is currently being finalized, along with the rest of the CCWG-Accountability recommendations. (A detailed explanation tracing the evolution of CCWG-Accountability work on human rights can be found here).

Ongoing work on human rights

Work Party 4 of CCWG-Accountability continues its work on developing ICANN’s commitment to human rights. Future work in this area will be in the form of understanding how the proposed human rights bylaw is to be interpreted, specific to ICANN’s structure.

Further, there are groups dedicated to understanding the intricacies of human rights and ICANN’s policy work. The Cross-Community Working Party on ICANN’s Corporate and Social Responsibility to Respect Human Rights (CCWP-HR) and the GAC Working Group on Human Rights and International Law (HRIL) are two such examples. The work of these groups become even more significant with the three PDPs currently underway, as there needs to be a constant check to ensure that the policies respect internationally recognized human rights.

^[1] https://www.article19.org/data/files/medialibrary/38148/ICANN_CS_to_respect_HR_report_ALL_FINAL-PDF.pdf

^[2] Dr. Monika Zalnieriute and Thomas Schneider, ‘A Council of Europe Analysis on ICANN’s Procedures and Policies in the Light of Human Rights, Fundamental Freedoms and Democratic Values.’ Council of Europe, Strasbourg, DGI (2014)12.

^[3] https://www.article19.org/data/files/medialibrary/38148/ICANN_CS_to_respect_HR_report_ALL_FINAL-PDF.pdf

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