ICANN Initiatives

ICANN's mission is to ensure the stable, secure, and resilient operation of the Internet's unique identifier systems. Its core values are to reflect the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making; ensure a bottom-up, multistakeholder Policy Development Process is used to ascertain the Global Public Interest; and make its processes accountable and transparent. ICANN's technical commitment is to maintain a single, global authoritative root.

ICANN's technical mission includes:

1. coordinating the allocation of the Internet's unique identifier systems, such as Domain Names, IP Addresses, autonomous system (AS) numbers and protocol port and parameter numbers;
2. coordinating and facilitating the stability, security and resiliency and policy of the aforementioned systems;
3. collaborating in these systems' technical protocol development;
4. maintaining and operating the L-root;
5. managing ICANN's operations and internal systems; and
6. providing a publicly accessible information resource on these functions for the greater Internet community.

Thus, its mission- and value-driven initiatives have come to include policies, organizational additions, operational improvements, and other strategies to ensure that ICANN's commitments are realized.

A Stable Internet

Timeline of ICANN's changing definitions of Internet stability

• 1998: Stability (as security, reliability, and reliance on U.S.-based technical expertise) is cast as the foremost fundamental principle of running ICANN and the DNS.

• 1/30/98: The Green Paper set out four principles to guide the evolution of the domain name system: stability, competition, private bottom-up coordination, and representation. “The Green Paper suggested that the new corporation be incorporated in the United States in order to promote stability and facilitate the continued reliance on technical expertise residing in the United States, including IANA staff at USC/ISI.”
• 06/05/1998: the White Paper: "Stability: The U.S. Government should end its role in the Internet number and name address system in a manner that ensures the stability of the Internet. The introduction of a new management system should not disrupt current operations or create competing root systems. During the transition and thereafter, the stability of the Internet should be the first priority of any DNS management system. Security and reliability of the DNS are important aspects of stability, and as a new DNS management system is introduced, a comprehensive security strategy should be developed.

• 1999-2001: Performing stability is central to ICANN’s proof of concept TLDs, which some criticized as relying on a highly subjective process and letting very few have a gTLD

• ICANN imposed high threshold requirements new gTLD application consideration and allowed only a select few test cases to ensure that no new TLD registry would fail as that would threaten Internet (ICANN) stability.
• October 1999: ICANN DNSO Working Group C brainstormed how expanding the namespace would factor into Internet stability, which fed into their determination of when and how new gTLDs should be added.
  
• August 2000: "Successful TLD applications should 'preserve the stability of the Internet': They should eliminate or minimize the effects of technical failures in registry or registrar operations, and they should steer clear of anything that challenged ICANN’s position as proprietor of the root zone. Staff will favor TLDs that help advance the “proof of concept” ICANN sought, providing useful information regarding the feasibility and utility of different types of new TLDs, procedures for launching them, registry-registrar models, business models, and internal policy structures."
• February 2001: the stability and functioning of the DNS and ICANN depend on setting and staying within stringent limits.

• Vint Cerf, Chairman of ICANN before the House Committee on Energy and Commerce Subcommittee on Telecommunications and the Internet states, ICANN has “achieved [its] accomplishments by hewing to its first and guiding principle -- to maintain a stable, functional DNS -- and within those limits by seeking to increase competitive options and efficient dispute resolution.”

• 2002-2004: Stability as a Value

“Users can accumulate equity in a particular identifier, which becomes closely associated with them and expensive to change. Changing a telephone number or e-mail address that has been used for many years can be burdensome because of the large number of personal contacts and records that contain the number. Thus, equity in an identifier raises switching costs for consumers, making them more likely to stay with the provider of that identifier.”

• 2008-2012: Emphasis on maintaining technical stability in the lead up to the New gTLD Program

• 2008:

• 02/06/2008: ICANN Staff and SSAC consider the possibility of instability in executing the GNSO’s recommendation to add new gTLDs.
• "Conformity to existing standards and syntax rules will be a requirement for any new TLD," including RFC 952 (“DOD Internet Host Table Specification); liberalized by RFC 1123; RFC 2181 (label number limit); and RFC 3696: labels must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. ICANN also expected to disallow any TLDs containing only numeric characters and allow hyphens in both the third and fourth positions of a label only in a valid Punycode string, where the currently approved IDNA prefix (currently xn) is used.
• ICANN was concerned that commonly-used file extensions as TLDs in the root might result in users or applications confusing URLs with filenames. SSAC explored the issue and reported that such collisions would result in user confusion but would not break the DNS
• the DNS should be able to function at its current level with at least 60 million TLDs. This allows significant room for large-scale expansion without concerns about a negative effect on stability.
• As the size of the zone increased, changing the AXFR (asynchronous full transfer zone) method to an Incremental Zone Transfer or IXFR was required. All of the large zones use an incremental method of updating to accommodate the larger zone file size. It involved administrative planning, work, and testing across all the root server operators and the distribution master to make this transition for the distribution of the root zone, but there was no technical limitation.
• The inclusion of a large number of signed TLD zones required more time and effort to generate and publish the root zone but did not impact performance or end-user experience.
• Any increase in traffic to the servers due to additional TLDs was expected to be minimal, as the main source of the traffic to root servers is not the number of TLDs but rather the number of end systems initiating queries. The root servers allow for much more traffic than their normal capacities for security reasons. Technical issues are unforeseen due to an increase in the number of queries.
• ICANN staff made a distinction between technical instability, which directly and adversely impacts the DNS, and operational impacts, which may not be harmful to the Internet technically but present challenges to DNS management and operation.
• ICANN staff acknowledge that (Before the new gTLD program), there was roughly one change per TLD per year.

• 2009:

• February 2009: the ICANN Board requested a study be undertaken to examine the impact of the inclusion of a number of new technologies (IPv6, DNSSEC, and IDNs) and the potential addition of significant numbers of new top-level domains to the root of the DNS as the stability of the DNS might be at risk if changes and additions were pursued without caution. two studies were performed, one focusing on the impact of the new technologies and TLD additions on one root server, the other taking a wider view and looking at all processes associated with the management of the root system.
• May 2009: ICANN releases the "Plan for Enhancing Internet Security, Stability, and Resiliency."
• June 2009: ICANN and the RIPE NCC affirmed their mutual commitment to coordinating DNS root name service operations through an open exchange of letters acknowledging that a single, unique DNS root was paramount to the stable operations of the Internet and ensuring that they would make it globally accessible.
• 09/30/2009: Affirmation of Commitments between NTIA and ICANN institutionalizes and memorializes ICANN's technical coordination of the DNS, emphasizing the importance of maintaining its stability (security, and resiliency).

• 2010:

• October 2010: Scaling the Root Study Findings:

1. The deployment of IPv6, DNSSEC, and IDNs to the root system has had no significant harmful impact.
2. With a cap of less than 1000 new gTLDs per year being added to the root zone, normal operational upgrade cycles and resource allocations will be sufficient to ensure that scaling of the root, both in terms of new technologies as well as new content, will have no significant impact on the stability of the root system.

• November 2010: ICANN updated its strategic plan for enhancing the SSR of the DNS.

• 2012:

• May 2012: ICANN defines its role in DNS stability as "the capacity to ensure that the system operates as expected, and that users of the unique identifiers have confidence that the system operates as expected."

A Secure Internet

Timeline of ICANN's interpretation of security threats and its reactions

• May 2012: ICANN defines it role in DNS Security as "the capacity to protect and prevent misuse of Internet unique identifiers."

A Resilient Internet

Timeline of ICANN Plans to Ensure the Internet Can Bounce Back

• 2012:

• 05/17/2012: In its draft response to Recommendations #1 and #3 from the Security, Stability & Resiliency Review Team (SSR RT), ICANN defined Resiliency as “the capacity of the unique identifier system to effectively withstand/tolerate/survive malicious attacks and other disruptive events without disruption or cessation of service.”

• 2013:

• March 2013: Activities for FY 14 focused on supporting a healthy ecosystem, to provide the foundation for a more stable, reliable, and resilient Internet for the global community. This approach focuses on an Internet that is sustainable or healthy, stable and resilient. A system that is sustainable for the future. We need to collectively concentrate on the ecosystem's "ability to maintain its structure and function over time in the face of external stress."

• 2016:

• October 01, 2016: The ICANN Bylaws are amended and the first references to "resiliency" are included in the following areas:

• "ICANN's scope is to coordinate the development and implementation of policies for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS"
• ICANN's pledged commitment is to "Preserve and enhance the administration of the DNS and the operational stability, reliability, security, global interoperability, resilience, and openness of the DNS and the Internet" and the "periodic review of ICANN's execution of its commitment to enhance the operational stability, reliability, resiliency, security, and global interoperability of the systems and processes, both internal and external, that directly affect and/or are affected by the Internet's system of unique identifiers"
• ICANN's board minutes concerning resolutions are to include "a discussion of the material impacts to the security, stability and resiliency of the DNS"...However, the board can redact the minutes if they "would present a material risk of negative impact to the security, stability or resiliency of the Internet"
• The Competition, Consumer Trust and Consumer Choice Review is to ensure that ICANN addresses "issues of competition, consumer protection, security, stability and resiliency, malicious abuse issues, sovereignty concerns, and rights protection" with every round of new gTLDs
• A majority or more of Interim Directors on the ICANN Board must consult SOs/ACs and follow the "process for a Rejection Action Community Forum (pursuant to Section 2.3 of Annex D) prior to taking any action that would, if implemented, materially change ICANN's strategy, policies or management, including replacement of the then-serving President" in order to preserve the SSR of the Internet
• All Stream 2 Recommendations must "maintain the security, stability and resiliency of the DNS" among other principles.

A Unified, Global Internet

Performing Accountability & Transparency: Reviews at ICANN

Although the organization's core mission and values have remained largely consistent throughout the organization's existence, certain events have resulted in amendments to the ICANN Bylaws to more precisely define ICANN's mission and values. For example, the IANA Functions Stewardship Transition expanded ICANN's mission slightly (to incorporate the oversight of the IANA functions and the PTI) as well as the Affirmation of Commitments into ICANN's bylaws, memorializing the structure and rules for Specific Reviews.

<timeline>

1. All measures are in pixels

ImageSize = width:1200 height:auto barincrement:25 PlotArea = left:20 right:20 bottom:20 top:20 AlignBars = early Legend = top:120 orientation:vertical columnwidth:150 left:50 DateFormat = mm/dd/yyyy Period = from:01/01/2001 till:01/01/2022 TimeAxis = orientation:horizontal Colors =

  id:grid value:rgb(0.9,0.9,0.9)
  id:bylaws value:rgb(0.3,0.3,0.3)
  id:atr value:skyblue legend:Accountability_and_Transparency
  id:ccp value:yellowgreen legend:Consumer_Choice_and_Protection
  id:ssr value:tan1 legend:Stability_of_the_DNS
  id:rds value:lightorange legend:Registration_Directory_Service

ScaleMajor = unit:year increment:1 start:01/01/2001

Define $dx = 25

BarData=

   Bar:Bylaws
   Barset:ATR
   Barset:CCP
   Barset:SSR
   Barset:RDS

PlotData=

  align:left textcolor:black fontsize:M mark:(line,black) width:15
  bar:Bylaws textcolor:bylaws
    at:12/15/2002 shift:(5,-5) color:bylaws width:10 text:"Evolution & Reform Amendments"
    at:05/27/2016 shift:(5,-5) color:bylaws width:10 text:"IANA Transition Amendments"

  barset:ATR color:atr textcolor:black mark:(line,black) width:15
    from:01/13/2010 till:01/29/2013 shift:(0,-5) text:"ATRT1"
    from:10/05/2012 till:12/31/2015 shift:(0,-5) text:"ATRT2"
    from:01/01/2017 till:01/01/2022 shift:(0,-5) text:"ATRT3"

  barset:CCP color:ccp
    from:06/29/2007 till:03/21/2009 shift:(50,-5) text:"RAA amended to include compliance audits"
    from:10/28/2011 till:06/27/2013 shift:(50,-5) text:"RAA amended based on law enforcement concerns"
    from:10/01/2015 till:01/01/2022 shift:(0,-5) text:"CCT1"
    
  barset:SSR color:ssr
    from:06/01/2010 till:12/31/2015 shift:(0,-5) text:"SSR1"
    from:06/01/2016 till:01/01/2022 shift:(0,-5) text:"SSR2"

  barset:RDS color:rds
    from:06/01/2010 till:12/31/2016 shift:(0,-5) text:"RDS1"
    from:11/01/2016 till:01/01/2022 shift:(0,-5) text:"RDS2"

</timeline>

Seeking Diversity, Equity, & Inclusion within ICANN

• Timeline of DEI efforts at ICANN

A Single Authoritative Root

• Timeline of ICANN's efforts to preserve and enhance the global interoperability, resilience, and openness of the DNS/Internet

• Timeline of ICANN's efforts to withstand attempts at splintering the Internet and outlast competitors

Internet Assigned Numbers Authority

Top-Level Domain

Deprecated. Domain Name Supporting Organization. Predecessor of the Generic Names Supporting Organization, which advised the Board with respect to policy issues relating to the Domain Name System (ICANN Bylaws).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Request For Comments