ICANN’s Accountability and Transparency: A Retrospective on the IANA Transition

Editors note: On the 5 year anniversary of the IANA transition, a group of people began collaborating on this report. It is being released in conjunction with ICANN 75 in Kuala Lumpur

Keith Drazek, Verisign
Jordan Carter, auDA
Wolfgang Kleinwachter, Aarhus University, EuSSIG
Milton Mueller, Georgia Institute of Technology
Thomas Rickert, Rickert Rechtsanwaltsgesellschaft mbH

Tatiana Tropina, University of Leiden
Bruce Tonkin, auDA

The Internet Corporation for Assigned Names and Numbers (ICANN) is approaching its 25th anniversary, and the IANA Stewardship Transition (IANA transition) concluded more than five years ago. This point in time marks an important opportunity for the ICANN multi-stakeholder community to review and assess ICANN’s current governance model and key accountability and transparency mechanisms. That assessment includes taking stock of the implementation status of the key reforms required by the IANA transition, the multi-year process that initiated the most significant changes to ICANN’s governance structure in more than two decades.
ICANN and its multi-stakeholder community have evolved significantly over the last 20-plus years, and the IANA transition triggered the latest major update to ICANN’s articles of incorporation and bylaws. The co-authors of this paper were directly involved in extensive community engagement to prepare ICANN and its governing documents for the final transition of Internet Assigned Numbers Authority (IANA) functions stewardship from the U.S. government to the global internet community, as envisioned at the time of ICANN’s founding in 1998. In our collective view, the IANA transition and its required accountability and transparency reforms were positive and appropriate steps in ICANN’s evolution and appear to be working as intended since the transition’s completion in 2016.
Current ICANN governance structures have generally proven effective under routine operating conditions, as well as in exceptional circumstances such as the KSK roll-over and, more recently, the increased demand on the DNS and internet routing infrastructure during the COVID-19 pandemic. While ICANN and its multi-stakeholder community must continue the work to fully implement the remaining and post-transition obligations, the past five years have demonstrated not only ICANN’s compliance with its new bylaw obligations and support for the updated accountability and transparency reforms, but also evidence those reforms are effective in delivering on the promise of ICANN’s accountability to the broader community without an individual government in an oversight role.
ICANN continues to face systemic challenges from some governments that do not support the multi-stakeholder model for Internet Governance (IG), preferring a purely governmental approach to internet-related issues through national legislation, a treaty organization performing IANA functions, or a combination thereof. The global IG environment and ecosystem have continued to evolve over the last five years, and it is important for ICANN to solidify its maturation by finalizing implementation of existing commitments to transparency and accountability while supporting the broader multi-stakeholder community in its responsibilities.
A Brief History of ICANN’s Founding
ICANN was established in 1998, following a call for proposals and the subsequent execution of a Memorandum of Understanding (MOU) between the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) and ICANN. The MOU was the result of a year-long effort initiated by NTIA with the January 1998 “Green Paper,” formally titled A Proposal to Improve Technical Management of Internet Names and Addresses, and the June 1998 “White Paper,” which formalized U.S. policies related to managing the internet’s system of unique identifiers.
In the late 1990s, the United States recognized its legacy role managing the internet’s unique identifiers was not well suited to handle the fast-changing digital landscape, including the global coordination of increasingly important domain names and IP addresses. In the White Paper, NTIA enumerated the challenges and pressures to transition DNS management from the U.S. government to the global multi-stakeholder community – anticipating many of the policy and organizational challenges tackled by the ICANN community during the next two decades, including competition, the introduction of new top level domains, domain name/trademark conflicts, global stakeholder representation, the role of government, and the need for predictability and transparency.
As noted in the White Paper:
The Need for Change
From its origins as a U.S.-based research vehicle, the Internet is rapidly becoming an international medium for commerce, education and communication. The traditional means of organizing its technical functions need to evolve as well. The pressures for change are coming from many different quarters:
—There is widespread dissatisfaction about the absence of competition in domain name registration.
—Conflicts between trademark holders and domain name holders are becoming more common. Mechanisms for resolving these conflicts are expensive and cumbersome.
—Many commercial interests, staking their future on the successful growth of the Internet, are calling for a more formal and robust management structure.
—An increasing percentage of Internet users reside outside of the U.S., and those stakeholders want to participate in Internet coordination.
—As Internet names increasingly have commercial value, the decision to add new top-level domains cannot be made on an ad hoc basis by entities or individuals that are not formally accountable to the Internet community.
—As the Internet becomes commercial, it becomes less appropriate for U.S. research agencies to direct and fund these functions.
In the 16 years between ICANN’s founding and the 2014 announcement of the IANA transition, the ICANN MOU saw several updates, including the 2006 Joint Project Agreement (JPA) and the 2009 Affirmation of Commitments (AOC). The JPA and AOC helped set the stage and establish parameters for the eventual IANA transition and the continued maturation of ICANN and its multi-stakeholder community. To that end, the AOC established four key performance reviews later incorporated and formalized by ICANN to enable a timely IANA transition. During its accountability and transparency work in 2014 and 2015, the ICANN community recognized the value of three key AOC “specific reviews:” Accountability & Transparency; Competition, Consumer Trust, and Consumer Choice; and Security, Stability & Resiliency. ICANN worked to ensure the continuation of these obligations through the transfer from NTIA while keeping in mind the likelihood that ICANN would exercise its right to cancel the AOC after the IANA transition.
What is IANA?
The Internet Assigned Names Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and Internet protocol parameter assignments emerging from the IETF standardization process. As of ICANN’s establishment in 1998, IANA functions were contracted out to ICANN by NTIA. But after the original MOU was allowed to expire and the IANA transition was completed in 2016, the global multi-stakeholder internet community itself became the steward of ICANN’s performance of IANA functions. Prior to 2016, the key entities performing the IANA functions were NTIA; ICANN; Verisign, for domain names and root zone management; the IETF, for protocol parameters; and the Regional Internet Registries (RIRs), for IP addressing. Following the IANA transition, NTIA was removed from the equation, ICANN accepted responsibility for performing the IANA functions with enhanced community oversight, and Verisign agreed to perform the Root Zone Maintainer (RZM) functions under a bilateral subcontracting agreement with ICANN, rather than the original three-party partnership between NTIA, ICANN, and Verisign.
The transition originated with a March 2014 NTIA announcement of the agency’s intent to “transition key Internet domain name functions to the global multi-stakeholder community” and its request for ICANN to “convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet’s domain name system (DNS).”
NTIA also clearly laid out its core principles and expectation that any such proposal must: have broad community support; support and enhance the multi-stakeholder model; maintain the security, stability, and resiliency of the internet DNS; meet the needs and expectation of the global customers and partners of the IANA services; maintain the openness of the Internet; and not replace the NTIA role with a government-led or an inter-governmental organization solution.
The IG community at the time was energized over several related events and developments, all of which increased international and stakeholder pressure on ICANN and other active IG groups. The first was the 2012 World Conference on International Telecommunications (WCIT), where the U.N. International Telecommunication Union (ITU) 193 member-states debated, but ultimately did not agree to, a resolution that would have encouraged greater international governmental control over internet-related policy. The second energizing event was the 2013 disclosures of Edward Snowden, which fostered mistrust of the U.S. government’s role in Internet governance even though the NSA practices he revealed had nothing to do with ICANN. The initial NetMundial conference was called by the Brazilian government in April 2014, with particular focus on the Snowden revelations, and there was significant engagement by ICANN’s leadership to promote multi-stakeholder engagement globally over internet governance issues. Another energizing development was anticipation of the 2014 and 2015 United Nations WSIS+10 meetings, which ultimately produced an implementation review of original WSIS outcomes from 2005 and a ten-year renewal of the Internet Governance Forum charter.
In this broader context, 2014 was a year when pressure had built between supporters of governmental vs. multi-stakeholder and private-sector-led approaches to internet regulation, and the United States elected to transition IANA functions from the government to ICANN, clearly signaling its commitment to supporting the global, multi-stakeholder community.
Yet, the ICANN multi-stakeholder community was largely surprised by NTIA’s March 2014 announced intent to step away from its historical role and to seek a proposal from ICANN. While there was general support for a transition to the global multi-stakeholder community, many raised concerns about ICANN’s accountability, transparency, and organizational readiness to “stand alone” without NTIA’s legacy supervision. Two weeks after NTIA’s announcement, ICANN met in Singapore for ICANN49, where a dedicated transition-related session was held, planning for the IANA stewardship transition began in earnest, and the community was invited to provide input.
The key principles set out by ICANN and NTIA for community consideration included:

Transition process facilitated by ICANN to be globally inclusive and collaborative;
USG stewardship transition to accountability mechanisms (existing/new);
accountability mechanisms to provide transparency to all stakeholders globally (governments, private sector, civil society);
accountability mechanisms to be administered in a manner that is not government-led, or inter-governmental;
accountability mechanisms to support & enhance the bottom-up consensus-based multi-stakeholder model;
accountability mechanisms to maintain DNS security, stability, and resiliency;
accountability mechanisms to meet needs/expectations of global customers and partners; and
mechanisms to maintain openness of the internet.

Following ICANN49, the community effort was accompanied by several iterations of the ICANN transition plan, including an April 2014 scoping document and a June 2014 announcement concerning the formation of the cross-community IANA Stewardship Transition Coordination Group (ICG).
Because the IANA transition would impact multiple stakeholders across three distinct areas of responsibility – domain names, internet protocol numbers and protocol parameters – in June 2014, ICANN proposed and agreed to support the ICG to help coordinate and consolidate transition proposals from each of these impacted communities, and to support development of a comprehensive proposal for ICANN and NTIA consideration. The ICG became an important interface between the community and ICANN during the work to deliver on the shared goal of a strong and stable ICANN accountable to the global internet stakeholder community.
As noted by ICANN at the time, “it was determined that the transition proposals for each of the IANA functions should be developed by the directly affected communities: the IETF and IAB for IANA functions related to Internet Protocol Parameters; the NRO, the ASO, and the RIRs for functions related the management and distribution of numbering resources; and the GNSO and ccNSO for functions related to the Domain Name System.”
As such, the Community Working Group IANA Naming Functions Transition group, known as CWG-Stewardship, was formed to develop a proposal for the elements of the IANA Stewardship Transition directly impacting the naming community. Completion and acceptance of this group’s work was a prerequisite for the transition, along with the parallel technical proposals from the numbering and protocol parameter communities, but it did not include the necessary parallel work of ensuring ICANN’s accountability and transparency.
ICANN50: The Community Speaks Out for Accountability
While there was general support for the transition, the broader ICANN community had significant concerns about ICANN’s accountability, long-term legitimacy, and what appeared to be an accelerated process in the face of the external geopolitical pressures of the day.
At ICANN’s 2014 summer meeting in London (ICANN50), representatives of ICANN’s Generic Names Supporting Organization (GNSO) stakeholder and constituency groups developed and delivered the first joint statement in the history of the GNSO, which was further supported by other ICANN community groups during the ICANN50 Public Forum, calling for key accountability reforms and a process to ensure ICANN’s Board of Directors could be held accountable absent NTIA’s historical role and perceived backstop capability. The GNSO statement, coupled with the broader demand for an accountability and transparency effort, directly led to the eventual formation of the Cross-Community Working Group on ICANN’s Accountability and Transparency (CCWG-Accountability).
CCWG-Accountability was chartered to consider any necessary updates to ICANN’s accountability mechanisms in support of the IANA transition – eventually divided into two work tracks: Work Stream 1 for deliverables required prior to the IANA transition and Work Stream 2 for items that could be finalized and implemented after the transition. CCWG-Accountability’s work was an intense cross-community effort over three years that delivered significant value to the transition by developing accountability mechanisms that met the expectations of NTIA and the needs of the global ICANN multi-stakeholder community.
CCWG-Accountability, Stress Tests, and the Empowered Community
An important factor in the preparation for a successful IANA transition was the development of Stress Tests for various accountability tools under consideration. As noted by CCWG-Accountability in Annex 15, “‘Stress Testing’ is a simulation exercise where a set of plausible, but not necessarily probable, hypothetical scenarios are used to gauge how certain events will affect a system, product, company or industry.” The Stress Tests were considered an essential part of the CCWG-Accountability charter. “The exercise of applying stress tests identified changes to ICANN Bylaws that might be necessary to allow the CCWG-Accountability to evaluate proposed accountability mechanisms as adequate to meet the challenges identified,” the group wrote in Annex 15.
Thirty-eight individual stress tests were developed and demonstrated an important level of rigor in assessing the possible risks and benefits of each recommended accountability tool. The stress tests were grouped into five categories in the final report: Financial Crisis or Insolvency, Failure to Meet Operational Obligations, Legal/Legislative Action, Failure of Accountability and, Failure of Accountability to External Stakeholders. Most of the tests addressed concerns about capture by governments or powerful stakeholders, board action or inaction, the impact of government regulation, and the very deliberate and focused backstop role of the “Empowered Community.”
As noted, previously, the 2009 AOC created four reviews through which the community could hold ICANN accountable. Because the AOC could be canceled by ICANN at any time, the CCWG-Accountability required the AOC reviews be added to ICANN’s bylaws – a direct result of Stress Test #14: ICANN or NTIA Terminate the AOC. ICANN agreed to this community requirement and added all four reviews to the bylaws, including the Accountability and Transparency Review Team (ATRT), which measures ICANN’s performance against its obligations. The most recent review, ATRT-3, published its final report in May 2020 with five recommendations.
To the extent community members have concerns about ICANN’s ongoing performance against its current bylaws, these established reviews are an appropriate vehicle for engagement and identifying any structural accountability gaps or where ICANN’s delivery diverged from expectations following the CCWG-Accountability recommendations, stress tests, and implementation of the new bylaws.
The development of ICANN’s Empowered Community was another key outcome of the CCWG-Accountability, and one that became the foundation of ICANN’s ongoing legitimacy in the eyes of its community members. The Empowered Community (EC) is the mechanism through which ICANN’s Supporting Organizations (SO) and Advisory Committees (AC) can organize under California law to legally enforce enumerated community powers. As part of the IANA transition, community powers and the rules that govern the EC are defined in the ICANN Articles of Incorporation and Bylaws and include five community groups sharing nine enumerated powers:
The current members of the ICANN Empowered Community are:

Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)

The EC has the power to:

reject ICANN and IANA budgets, and ICANN operating and strategic plans;
reject standard bylaw amendments;
reject Public Technical Identifiers (PTI) governance actions;
approve fundamental bylaw and article amendments, and asset sales;
recall the entire ICANN board;
appoint and remove individual ICANN board directors (other than the president);
require the ICANN board to review its rejection of IANA Function Review (IFR), special IFR, Separation Cross-Community Working Group (SCWG) creation, and SCWG recommendation decisions;
initiate community reconsideration request, mediation, or Independent Review Process (IRP); and
hold the rights of inspection and investigation.

The EC was designed to hold the ICANN board and management accountable, without contradicting the board’s exercise of its fiduciary responsibilities, and to create a limited and proportional capability for ensuring the board meets its obligations and does so in the public interest, within its bylaws, and on behalf of its global multi-stakeholder community. As such, the role of the EC is carefully limited to provide checks and balances while avoiding interference in matters correctly left to the board of directors, as the representative of the broader ICANN community.
A key factor in the EC’s development was to establish a threshold for action that would be balanced and executable but would not undermine the board’s ability to act in a decisive and timely manner. As such, the EC was provided specific triggers requiring varying levels of support to initiate action, depending on the issue and community power.
Fortunately, as of this writing, the ICANN community has not yet been sufficiently concerned to exercise any of the EC’s enumerated powers. After more than five years, this fact is a testament to the detailed, rigorous, and careful approach the ICANN community took in supporting the IANA transition with the necessary accountability and transparency reforms as a pre-condition for transition.
The existence of the EC has helped to foster constructive engagement among the ICANN board, organization and community for the past five years, but ICANN community members must be continuously reminded of the powers, triggers, and obligations associated with this important, and still relatively new, accountability structure.
Root Zone Management and Accountability at the Root
In March of 2015, to prepare for the IANA transition implementation, NTIA asked Verisign and ICANN to submit a proposal for how best to remove the NTIA’s administrative role in root zone management while maintaining the security, stability, and resiliency of the internet’s domain name system. ICANN and Verisign submitted a joint proposal in August 2015, offering a high-level plan for transitioning the NTIA role along with recommendations on the way forward. The proposal resulted in the 2016 development of the Root Zone Maintainer Services Agreement (RZMA), establishing a bilateral relationship between ICANN and Verisign while removing NTIA from its legacy “approver” role for updates to the root zone file.
While working with Verisign on the RZMA, ICANN was simultaneously working with the broader multi-stakeholder community in 2015 and 2016 to develop and deliver the proposals that would enable completion of the IANA transition. The entire process took one year longer than originally envisioned by NTIA and ICANN, but the result was more robust and better able to withstand significant political pressure and scrutiny.
Following the acceptance and signing of the RZMA, Verisign and ICANN deployed updated root zone management systems that removed the requirement for NTIA approvals while maintaining essential accountability and transparency functions. The new system ran in parallel with the old one for 90 days, in a well-documented trial, to ensure the new system would operate as expected and produce root zone files identical to the old one.
The new RZMA placed new service-level requirements on Verisign as the Root Zone Maintainer, including RZMS service availability, root zone distribution service availability, root zone publication frequency, time to publish normal change requests, and time to publish emergency change requests. Verisign continues to provide monthly reports to ICANN demonstrating compliance with these service level agreement requirements.
In support of Root Zone Management accountability, the community via the CWG-Transition, recommended establishment of a standing Root Zone Evolution Review Committee (RZERC) to provide advice on moving forward with any future architectural changes. Since its creation in 2016, the RZERC has produced a statement in support of the KSK rollover, recommendations for adding data protections to the root zone, and recommendations to study signed root zone name server data. After its first five years, RZERC is conducting a review of its own charter.
To ensure operational and technical security and stability at the time of the transition, ICANN, Verisign and NTIA agreed Verisign, at a nominal fee, would continue to provide services for root zone maintenance, root zone signing management of the root zone’s zone signing key, and distribution of the root zone file and related files to the root zone operators. The RZMA has an eight-year term, with the intention of promoting the security, stability, and resiliency of root zone maintenance operations by having Verisign continue its current role for that term. As an important additional accountability mechanism, the RZMA also provides the community the ability – through a consensus-based, community-driven process – to require ICANN to transition the root zone maintenance function to another service provider after three years. It also allows for the community to recommend changes to service level agreements and the RZMS, as root zone management evolves.
Beyond Transition: Real-World Stress Tests
Following the 2016 IANA transition, ICANN and its multi-stakeholder community have faced and effectively managed several regulatory, technical, logistical, and governance challenges that were identified and stress tested during the community’s work in support of the transition. The remainder of this paper examines several key real-world situations that have arisen since the transition and takes stock of whether the mechanisms in place have been adequate for addressing situations hypothesized in our stress tests. Using this pre-existing score card, we can evaluate whether ICANN met these challenges as envisioned by the IANA transition.
It is vital not to conflate successful crisis navigation with a lack of controversy. The mechanisms described in the stress tests were designed to prevent acute and systemic retreat from the multi-stakeholder model, not necessarily to deter controversy. Nor should our evaluations confuse the successful resolution of an issue with parochial notions of “winners” and “losers.” Indeed, the success or failure of the transition cannot be determined by whether a situation was controversial nor by which side prevailed. For these purposes, the IANA transition must be assessed on whether the structures put in place, including the new bylaws, enabled ICANN to successfully navigate difficult issues without triggering the problems the stress tests sought to avoid.
Here, we will look at three particularly difficult post-transition challenges ICANN faced – each contemplated by our stress tests – and examine how and why ICANN successfully resolved each of them, under the new bylaws and related accountability obligations of the IANA transition.
Case Study: GDPR and Stress Test #4
Perhaps the most significant challenge to ICANN’s technical coordination role in the last five years has been the introduction and enforcement of the EU’s General Data Protection Regulation (GDRP). GDPR has a direct impact on ICANN and its gTLD registry and registrar agreements which, before 2018, required the collection, transfer, and public display of domain name registrant contact data, including email addresses, phone numbers and street address.  After extensive consultations with stakeholder groups, the ICANN board introduced a Temporary Specification to remove explicit conflicts between ICANN’s agreements and GDPR, and to prevent legal and financial exposure for ICANN and its contracted parties while maintaining some access for legitimate requestors of registrant data. The Generic Names Supporting Organization (GNSO) then initiated a multi-year, community-wide Expedited Policy Development Process (EPDP) to ratify or modify the Temporary Specification. The EPDP Phase 1 policy work concluded in 2019 and has been approved by the ICANN board; its implementation work is still underway.
Fortunately, the IANA transition process anticipated possible future challenges from national regulation via stress tests, several of which evaluated how ICANN could navigate the complex challenges presented when regulatory requirements in one jurisdiction conflict with others and/or with ICANN’s global policies for generic TLDs. Stress Test #4 anticipated a situation such as GDPR:
Stress Test #4:  New regulations or legislation.
For example, a government could cite anti-trust or consumer protection laws and find unlawful some rules that ICANN imposes on TLDs. That government could impose fines on ICANN, withdraw from the GAC, and/or force ISPs to use a different root, thereby fragmenting the Internet.
After ICANN’s Board responded to the regulation (litigate or change policy/implementation), the community would have several response options:

The community could develop new policies that respond to the regulation.
Another measure would give the community standing to file for Reconsideration or file an IRP challenging ICANN action or inaction that is inconsistent with the Articles, Bylaws, and ICANN’s established policies. However, it is highly unlikely that Reconsideration or an IRP could be used by the community to cause ICANN to act contrary to the decision of a court or regulator. Note also that generally the community will not be able to use an IRP to reopen matters that are within the core powers and fiduciary judgment of the ICANN Board.
An Advisory Committee or Affirmation of Commitments review team could develop recommendations to address this scenario. An ICANN Board decision against those recommendations could be challenged with a Reconsideration and/or IRP.

The community’s analysis for Stress Test #4 concluded the post-transition ICANN bylaws provided new and adequate powers for the community to challenge ICANN’s board if its decisions violated the bylaws. In fact, accountability measures like the Community IRP and Community Reconsideration are triggered by agreement of just three of the five Empowered Community participants.
More than five years after the IANA transition, and more than three years since GDPR’s effective date, ICANN and its contracted parties have responded by following applicable law, without incurring potentially massive fines for violating GDPR, and continue to work within the multi-stakeholder community to address alternatives for access and disclosure.
While ICANN’s response to GDPR was not as prompt as it might have been, once engaged, the ICANN board’s actions, including the promulgation of the Temporary Specification, ensured the community was at least minimally prepared to comply with the new obligations established in GDPR. Policy development was subsequently undertaken via the Generic Names Supporting Organization (GNSO) to address the conflicts between GDPR and ICANN’s gTLD contracts with registries and registrars and to confirm the board’s decision to trigger the Temporary Specification.
Though some community members remain unsatisfied with ICANN’s response to GDPR, no EC member has petitioned to invoke community powers to overturn the board’s decisions.
Case Study: Root Zone Key-Signing-Key Rollover and Stress Tests #1, 2, 11, 17, & 21
Rollover of the DNSSEC Key-Signing-Key (KSK) was necessary to ensure the trust and security of the root zone. During the IANA transition, the community identified this concern and designed five separate stress tests — #1, 2, 11, 17, and 21 — to mitigate ICANN’s potential failure to meet DNS operational expectations. Specifically, these five stress tests examined scenarios in which ICANN fails to process change or delegation requests to the IANA Root Zone or executes a change or delegation despite objections of stakeholders, such as Significantly Interested Parties.
Under intense pressure to conclude the IANA transition, ICANN’s original timeline for processing the KSK roll was aggressive, but ICANN worked with the community within the established process to delay and mitigate potential catastrophic impacts.
The first root zone KSK rollover was initially scheduled to take place Oct. 11, 2017. In the months leading up to it, the community expressed concerns about rollover readiness due to telemetry data observations from a protocol developed by a Verisign engineer. Over the course of the following year, members of the community, ICANN, and others reached out to impacted parties and studied the situation in detail. The KSK rollover successfully occurred exactly one year later than originally planned, on Oct. 11, 2018. ICANN maintained the security, stability, and resiliency of the root zone for the benefit of the entire internet community. The progress of the rollover was closely monitored and comprehensive analysis of the first ever DNSSEC root KSK rollover was published.
ICANN and the root zone maintainer continue to work closely to generate the DNSSEC signatures necessary to maintain the trust and security of the root zone, including quarterly key signing ceremonies. The CWG-Stewardship transition proposal included a recommendation for a formal study examining the operational procedures governing changes to the root zone after NTIA’s involvement ceased.
Case Study: Reassigning .org Agreement, Stress Tests #3 & 15
Some community members have expressed concerns that ICANN has not lived up to its governance obligations or that ICANN’s new accountability mechanisms have fallen short. Examples cited include: the assignment of TLDs previously operated by UniRegistry, the controversy around .africa; and the proposed sale of the .org domain contract.
The proposed sale of .org by its operator PIR is a prime example of how the stress tests led to the design of new accountability mechanisms that have helped ICANN make decisions both within its mandate and accountable to the global internet community.
Stress Test #3 considered legal action arising from conflicts between laws or regulation and public policy decisions made by ICANN, such as the intervention of California’s Attorney General when ICANN was considering the transfer of the .org contract as recommended by ICANN legal staff. As anticipated in Stress Test #3, when faced with such an intervention, the ICANN board would decide whether to litigate, concede, or settle.
In the .org example, following significant stakeholder input and reaction as provided for in the .org Registry Agreement, the Board chose to concede, preventing transfer. If the board had chosen differently and decided to proceed with the transfer, under post-transition strictures, it could have quickly been challenged by the EC via IRP or Request for Reconsideration. In effect, the prospect of a community challenge cast a long shadow over board deliberations, to the extent that potential accountability mechanisms provided motivation without requiring EC mobilization.
Stress Test #15 considered the risk of “ICANN terminates its legal presence in a nation where Internet users or domain registrants are seeking legal remedies for ICANN’s failure to enforce contracts, or other actions.” More specifically, Stress Test #15 anticipated a hypothetical future ICANN board that might seek to avoid being subject to pressure from California’s Attorney General in a situation similar to the .org transfer.
This stress test led to a change in ICANN’s Articles of Incorporation, so that the Board could not change ICANN’s jurisdiction from California:
Any amendment to these Articles shall require (a) the affirmative vote of at least three-fourths of the directors of the Corporation, and (b) approval in writing by the Empowered Community, a California nonprofit association established by the Bylaws.
As previously noted, the EC was never envisioned to replace the appropriate roles of ICANN’s executives and board in managing normal operations and making decisions, even when facing delicate and difficult decisions. The EC is a backstop mechanism to ensure the ICANN Board remains accountable to the organization’s articles of incorporation and bylaws, and to its global multi-stakeholder community. As such, the triggers and thresholds for EC action were carefully designed and the powers are available, provided a sufficient majority of the ICANN community feels the board must be held to account for straying from the bylaws or failing to consider the global public interest in its decision-making. ICANN and its board are keenly aware of the new mechanisms and limited scope, and have, to date, generally avoided decisions that would prompt the EC to challenge and overturn. Second, the EC was well aware of the range of opinions on the matters being questioned, yet not a single EC member sought a petition to invoke the accountability powers.
It’s also important to note that the EC is not unduly constrained by a need to reach consensus among all five members. Annex D of ICANN’s new bylaws enables accountability measures to challenge board decisions if just 60% of decisional participants agree. The EC has an effect without having to mobilize, since the ICANN board is aware of the relatively low threshold and significant powers of the EC. If no EC members have called for mobilization, it’s because none believed ICANN, or the board, have violated the mission or bylaws.
Next Steps: Work Stream 2 Implementation, Jurisdiction, and More
Starting with the stress tests during IANA transition planning, and through the multi-year transition implementation, and the challenges ICANN has met head on in these early years post-transition, much work has been done to help ensure the security, stability, and resiliency of key internet infrastructure and services while maintaining accountability to the ICANN multi-stakeholder community. But there is still more work to do.
This multi-stakeholder governance experiment requires ongoing care to ensure it delivers on the original vision of private-sector-led management of the DNS. To continue the protection and promotion of the multi-stakeholder model, and to ensure its responsiveness and efficacy, it is important ICANN and its community understand and implement — and be prepared to use, if needed — the accountability and transparency mechanisms from the CCWC-Accountability. These reforms were intended to work as a package to create a system of checks and balances ensuring the ICANN board remains compliant with ICANN’s bylaws, capable of performing its fiduciary duties, and fully accountable to the broader ICANN community.
In October 2021, ICANN published a detailed status update, “Implementing Work Stream 2,” providing the broader community with a road map for unfinished implementation, some of which is the responsibility of the ICANN community groups themselves. The list of accountability categories still requiring implementation includes:

Diversity
Guidelines for Good Faith
Framework of Interpretation – Human Rights Core Value
Jurisdiction
Office of the Ombudsman
SO/AC Accountability
Staff Accountability
Transparency
IRP Standing Panel (prior obligation)

One of the more challenging discussion points during the IANA transition process, and more specifically the community’s deliberations around ICANN’s accountability, concerned ICANN’s legal jurisdiction. While fundamentally settled as an issue during the transition with new bylaw text requiring ICANN to remain headquartered in California, concerns remain around important issues such as the impact of international sanction regimes and possible political influence on ICANN’s leadership due to ICANN’s place of incorporation. On these issues, further work may be required to fulfill long-standing Work Stream 2 jurisdiction obligations and to help inform the community about the current status, next steps, and the potential benefit and risk to ICANN’s mission from further action – or inaction.
Jurisdictional challenges have been acknowledged, and while not immediately concerning, are still in need of attention. For example, discussions of sanctions and ICANN’s incorporation in California during the CCWG-Accountability work on Work Stream 1 and Work Stream 2, including the recognition of certain complexities around compliance with the requirements of the U.S. Office of Foreign Asset Controls and potential avenues for securing general or specific licenses.
Also, the .org transfer situation raised additional jurisdictional concerns among some in the ICANN community, particularly about potential political influence on ICANN’s Board, such as the possibility of the California Attorney General’s office exerting pressure on ICANN and that interested parties may choose to lobby the office in an attempt to achieve policy goals outside the established ICANN multi-stakeholder process.
It is clear ICANN would be subject to similar concerns and challenges anywhere it might be incorporated. As such, it is important that future ICANN boards and leadership maintain and reinforce the positions here and resist pressures to act outside of established processes or in conflict with ICANN’s bylaw obligations and limitations. More work is needed to fully implement the Work Stream 2 commitments related to jurisdiction, but ICANN accountability obligations have been built on a stable foundation with predictable processes that must be protected.
More recently, following the Russian Federation’s February 2022 invasion of Ukraine, the government of Ukraine sent a letter to ICANN’s CEO requesting the revocation of ccTLDs, SSL certificates and root server instances associated with or located in Russia. ICANN’s March 2 response appropriately stated:
“ICANN is an independent technical organization that manages the Internet’s unique identifiers. ICANN is a facilitator of the security, stability, and resiliency of these identifiers with the objective of a single, global, interoperable Internet. In our role as the technical coordinator of unique identifiers for the Internet, we take actions to ensure that the workings of the Internet are not politicized, and we have no sanction-levying authority. Essentially, ICANN has been built to ensure that the Internet works, not for its coordination role to be used to stop it from working.”
and
“Within our mission, we maintain neutrality and act in support of the global Internet. Our mission does not extend to taking punitive actions, issuing sanctions, or restricting access against segments of the Internet – regardless of the provocations. ICANN applies its policies consistently and in alignment with documented processes. To make unilateral changes would erode trust in the multistakeholder model and the policies designed to sustain global Internet interoperability.”
Conclusions
The establishment of ICANN and the multi-stakeholder model of private-sector-led internet policy development was a visionary development in 1998 that has proven to be resilient and generally responsive over its 24-year history. The IANA transition was a natural progression of ICANN’s evolution, an outcome envisioned by its founders.
ICANN has evolved significantly over the last two decades and the IANA transition, as initiated by the NTIA announcement in 2014, triggered the latest significant update to ICANN’s bylaws and accountability mechanisms. IANA functions themselves, including Root Zone Management, have been well-served by the transition and the new accountability structures designed and developed by the ICANN community continue to ensure the security, stability, and resiliency of the internet’s unique identifiers.
To date, ICANN’s accountability mechanisms are functioning, but more work is required to finish implementation of the obligations required by the ICANN Board’s 2016 acceptance of the CCWG-Accountability recommendations in Work Streams 1 and 2. The entire ICANN community needs to dedicate energy to ensuring full implementation of these important accountability mechanisms, and to ensuring the EC powers are available when the requisite majority agrees to invoke the powers.
The EC was not intended to replace the ICANN board and fiduciary responsibilities and is expected to be activated only in extreme cases, where the board has lost the confidence of most of the ICANN community – a situation that has not occurred since the transition’s completion in 2016. During the last five years, the EC has been available to exercise its oversight/back-stop role creating a soft check on the ICANN Board and its decisions – precisely the purpose and intent of this and other mechanisms designed and implemented during the transition.
Some have recently suggested ICANN’s accountability mechanisms and the EC have not lived up to expectations, usually because the specific and narrow interests of one party were at odds with another. But our view is that ICANN and its board have adjusted well to the new bylaws and related accountability obligations. Over the last five years, ICANN overall and its board have been keenly aware of the new mechanisms and limited scope and have avoided making decisions that would prompt the EC to challenge and potentially overturn the board decisions.
While ICANN’s multi-stakeholder processes and accountability structures are functioning, even in the face of a global pandemic that has interrupted our ability to gather and engage in person, this multi-stakeholder governance experiment requires ongoing care to ensure it delivers on the original vision of private-sector-led management of the DNS. All members of the ICANN community have an obligation to recall the history of the IANA transition, understand the value and power of our accountability mechanisms, and commit ourselves to fully implement, use when needed, and protect these important but necessarily limited powers from future misuse.The post ICANN’s Accountability and Transparency: A Retrospective on the IANA Transition first appeared on Internet Governance Project.The post ICANN’s Accountability and Transparency: A Retrospective on the IANA Transition appeared first on Internet Governance Project.
Source: Internet Governance Forum