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 article 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.
The last issue of dotmagazine’s “Building Trust” edition saw the first part of our report on “Transparency: A Retrospective on the IANA Transition” being published. The first part of this report not only covered the background to ICANN, IANA, and the IANA transition, but also delved into the Cross-Community Working Group on ICANN’s Accountability and Transparency (CCWG-Accountability), an introduction to stress tests, and the development of both ICANN’s Empowered Community and the Root Zone Maintainer Services Agreement.
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 current article 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.
Beyond Transition: Real-World Stress Tests
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 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 (GDPR). 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 addresses. 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 on October 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 October 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 that 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 that 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:
- Guidelines for Good Faith
- Framework of Interpretation – Human Rights Core Value
- Office of the Ombudsman
- SO/AC Accountability
- Staff Accountability
- 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 involved 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 that 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.”
“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.”
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, to understand the value and power of our accountability mechanisms, and to commit ourselves to fully implement, use when needed, and protect these important but necessarily limited powers from future misuse.
As vice president of public policy and government relations in the Naming and Registry Services organization at Verisign, Keith Drazek is responsible for actively and broadly participating in the development and advocacy of Verisign’s policy interests in multiple arenas involving Internet identifiers. Keith brings over 30 years of experience and leadership in the technical functions of the Internet and the Domain Name System (DNS), Internet policy development, government relations, external affairs and channel management.
Editor’s note: On the 5th year anniversary of the IANA transition, a group of people began collaborating on this report. It was released in conjunction with ICANN 75 in Kuala Lumpur. In addition to Keith Drazek, the co-authors included:
- 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
Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s own and do not reflect the view of the publisher, eco – Association of the Internet Industry.