ICANN Initiatives: Difference between revisions
No edit summary |
|||
(53 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
ICANN' | {|align=right | ||
|__TOC__ | |||
|} | |||
'''[[ICANN]] Initiatives''' are designed to fulfill | |||
# ICANN's mission of ensuring the [[SSR|stable, secure, and resilient]] operation of the Internet's unique identifier systems<ref>[https://www.icann.org/resources/pages/governance/bylaws-en/#article1 Section 1.1, ICANN Bylaws]</ref>; | |||
# ICANN's core values, which 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 Model|multistakeholder]] [[Policy Development Process]] is used to ascertain the [[Global Public Interest]]; and make its processes accountable and transparent; and | |||
# ICANN's technical commitment to maintaining a single, global authoritative root.<ref>[https://www.icann.org/resources/pages/governance/bylaws-en/#article1 Section 1.2, ICANN Bylaws]</ref> | |||
==Overview== | |||
Technically, ICANN must do no more or less than | |||
# coordinate the allocation of the Internet's unique identifier systems, such as [[Domain Name]]s, [[IP Address]]es, autonomous system (AS) numbers and protocol port and parameter numbers; | |||
# coordinate and facilitating the [[SSR|stability, security and resiliency]] and policy of the aforementioned systems; | |||
# collaborate with the [[:Category:Technical Community|technical community]] in developing these systems' protocols; | |||
# maintain and operate the [[Root Server Operator|L-root]]; | |||
# manage [[ICANN Organization|ICANN's operations and internal systems]]; and | |||
# provide a [[Information Transparency Initiative|publicly accessible information resource]] on these functions for the [[ICANN Community|greater Internet community]].<ref>[https://www.icann.org/en/public-comment/proceeding/draft-statement-of-icanns-role-and-remit-in-security-stability-and-resiliency-of-the-internets-unique-identifier-systems-17-05-2012 Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN]</ref> | |||
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''<br/> | |||
* '''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.” <ref>https://www.ntia.doc.gov/federal-register-notice/1998/statement-policy-management-internet-names-and-addresses</ref> | |||
:* 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. <ref>[https://cyber.harvard.edu/pressbriefings/icann/briefingbook/WhitePaper-Principles.html White Paper Principles, ICANN Briefing Book]</ref> | |||
* '''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.<ref>[https://arxiv.org/ftp/cs/papers/0109/0109099.pdf Jonathan Weinberg, "ICANN, 'Internet Stability,' and New Top Level Domains," Arxiv, pg. 30]</ref> | |||
:* 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.<ref>[http://www.dnso.org/dnso/notes/19991023.NCwgc-report.html Interim Report of Working Group C of the Domain Name Supporting Organization, 10/23/1999]</ref><br/> | |||
:* 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."<ref>[http://www.icann.org/tlds/tld-criteria-15aug00.html Criteria for Assessing TLD Proposals (Aug. 15, 2000)]</ref><ref>[https://arxiv.org/ftp/cs/papers/0109/0109099.pdf Jonathan Weinberg, "ICANN, 'Internet Stability,' and New Top Level Domains,' footnote 72]</ref> | |||
:* 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.”<ref>[https://www.icann.org/resources/unthemed-pages/cerf-testimony-2001-02-08-en Cerf Testimony 02/08/01, ICANN]</ref> | |||
* '''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.” <ref>[https://www.nap.edu/read/11258/chapter/4#62 Signposts in Cyberspace: The Domain Name System and Internet Navigation, pg. 62]</ref> | |||
* '''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.<ref>[http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm New gTLDs WG Final Report May 2007, GNSO, ICANN]</ref> | |||
::* 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.<ref>[https://archive.icann.org/en/topics/dns-stability-draft-paper-06feb08.pdf DNS Stability, 2008, ICANN Archives]</ref> | |||
::* 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.<ref>[https://archive.icann.org/en/topics/dns-stability-draft-paper-06feb08.pdf DNS Stability, 2008, ICANN Archives pg. 4]</ref> | |||
::* 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.<ref>[https://archive.icann.org/en/topics/dns-stability-draft-paper-06feb08.pdf DNS Stability, 2008, ICANN Archives pg. 5]</ref> | |||
:* 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.<ref>[https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf Summary of Impact of Root Zone Scaling, 10/06/2010, ICANN Archives]</ref> | |||
::* May 2009: ICANN releases the "[https://www.icann.org/en/system/files/files/ssr-draft-plan-16may09-en.pdf Plan for Enhancing Internet Security, Stability, and Resiliency]."<ref>[https://www.icann.org/en/announcements/details/plan-for-enhanced-internet-security-stability-and-resiliency-21-5-2009-en ICANN releases Plan for Enhancing SSR, ICANN Announcements]</ref> | |||
::* 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.<ref>[https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf RSSAC023: History of the Root Server System, pg. 28]</ref><ref>[https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/ripe-ncc-and-icann-commit-to-ongoing-dns-root-name-service-coordination RIPE NCC and ICANN Commit to Ongoing DNS Root Name Service Coordination, RIPE NCC New Archives]</ref> | |||
::* 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).<ref>[https://www.icann.org/en/announcements/details/icann-ceo-talks-about-the-new-affirmation-of-commitments-30-9-2009-en CEO talks about New AoC 2009, ICANN Announcements]</ref><ref>[https://www.icann.org/en/system/files/files/strategic-ssr-initiatives-09feb10-en.pdf 2010 Strategic SSR Initiatives, ICANN]</ref> | |||
:* 2010: | |||
::* October 2010: Scaling the Root Study Findings: | |||
::# The deployment of IPv6, DNSSEC, and IDNs to the root system has had no significant harmful impact. | |||
::# 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.<ref>[https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf Summary of Impact of Root Zone Scaling, 10/06/2010, ICANN Archives]</ref> | |||
::* November 2010: ICANN updated its strategic plan for enhancing the SSR of the DNS.<ref>[https://www.icann.org/en/system/files/files/ssr-plan-fy11-clean-23nov10-en.pdf SSR Plan FY11, ICANN]</ref> | |||
:* 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."<ref>[https://www.icann.org/en/public-comment/proceeding/draft-statement-of-icanns-role-and-remit-in-security-stability-and-resiliency-of-the-internets-unique-identifier-systems-17-05-2012 Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN]</ref> | |||
==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."<ref>[https://www.icann.org/en/public-comment/proceeding/draft-statement-of-icanns-role-and-remit-in-security-stability-and-resiliency-of-the-internets-unique-identifier-systems-17-05-2012 Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN]</ref> | |||
==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.”<ref>[https://www.icann.org/en/public-comment/proceeding/draft-statement-of-icanns-role-and-remit-in-security-stability-and-resiliency-of-the-internets-unique-identifier-systems-17-05-2012 Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN]</ref> | |||
* 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."<ref>[https://www.icann.org/en/system/files/files/ssr-plan-fy14-06mar13-en.pdf SSR Plan FY 2014, ICANN]</ref> | |||
*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 Board|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." If there is a majority or more of Interim Directors, the [[ICANN Board]] must consult [[SO]]s/[[AC]]s 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 | |||
::* ''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 | |||
::* ''All [https://gac.icann.org/activity/gac-involvement-in-work-stream-2-recommendations-implementation|Work Stream 2] Recommendations'' must "maintain the security, stability and resiliency of the DNS" among other principles.<ref>[https://www.icann.org/resources/pages/bylaws-2016-09-30-en ICANN Bylaws as Amended on 10/01/2016, ICANN Bylaws Archives]</ref> | |||
==Accountable and Transparent Governance of Names, Numbers, and Protocols== | |||
[[ICANN Accountability]] has been an ongoing topic since the birth of the organization. Article 4 of the [[ICANN Bylaws]] states: "In carrying out its Mission, ICANN shall be accountable to the community for operating in accordance with the Articles of Incorporation and these Bylaws, including the Mission set forth in Article 1 of these Bylaws."<ref>[https://www.icann.org/resources/pages/governance/bylaws-en/#article4 Article 4, ICANN Bylaws], as amended November 28, 2019</ref> | |||
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. The [[2002 Evolution and Reform Process]] resulted in the creation of Article 4, along with the establishment of ICANN's [[Reconsideration]] mechanism, the [[Independent Review Panel]], and the office of the [[ICANN Ombudsman]].<ref>[https://www.icann.org/resources/unthemed-pages/bylaws-2002-12-15-en#IV Article 4, ICANN Bylaws], as revised December 15, 2002</ref> The [[IANA Functions Stewardship Transition]] expanded ICANN's mission slightly (to incorporate the oversight of the IANA functions and the creation of the [[PTI]]), as well as incorporating the [[Affirmation of Commitments]] into ICANN's bylaws, memorializing the structure and rules for [[ICANN Reviews#Specific Reviews|Specific Reviews]]. | |||
===Amendments to Bylaws & Specific Review Processes=== | |||
<timeline> | <timeline> | ||
# All measures are in pixels | # All measures are in pixels | ||
Line 9: | Line 85: | ||
PlotArea = left:20 right:20 bottom:20 top:20 | PlotArea = left:20 right:20 bottom:20 top:20 | ||
AlignBars = early | AlignBars = early | ||
Legend = top: | Legend = top:120 orientation:vertical columnwidth:150 left:50 | ||
DateFormat = mm/dd/yyyy | DateFormat = mm/dd/yyyy | ||
Period = from:01/01/2001 till:01/01/2022 | Period = from:01/01/2001 till:01/01/2022 | ||
Line 18: | Line 94: | ||
id:atr value:skyblue legend:Accountability_and_Transparency | id:atr value:skyblue legend:Accountability_and_Transparency | ||
id:ccp value:yellowgreen legend:Consumer_Choice_and_Protection | id:ccp value:yellowgreen legend:Consumer_Choice_and_Protection | ||
id:ssr value:tan1 legend: | id:ssr value:tan1 legend:Stability_of_the_DNS | ||
id:rds value:lightorange legend:Registration_Directory_Service | id:rds value:lightorange legend:Registration_Directory_Service | ||
Line 44: | Line 120: | ||
barset:CCP color:ccp | barset:CCP color:ccp | ||
from: | 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:"[[First Competition, Consumer Trust, and Consumer Choice Review|CCT1]]" | from:10/01/2015 till:01/01/2022 shift:(0,-5) text:"[[First Competition, Consumer Trust, and Consumer Choice Review|CCT1]]" | ||
barset:SSR color:ssr | barset:SSR color:ssr | ||
from:06/01/2010 till:12/31/2015 shift:(0,-5) text:"[[First Security, Stability, and Resiliency Review|SSR1]]" | from:06/01/2010 till:12/31/2015 shift:(0,-5) text:"[[First Security, Stability, and Resiliency Review|SSR1]]" | ||
Line 57: | Line 133: | ||
</timeline> | </timeline> | ||
==A Unified, Global Internet== | |||
ICANN's core values are meant to reflect and encourage the functional, geographic, and cultural diversity of the Internet. | |||
===Seeking Diversity, Equity, & Inclusion=== | |||
* Timeline of [[Global Inclusion Initiatives|DEI efforts at ICANN]] | |||
* [[Coalition for Digital Africa]] | |||
===A Single Authoritative Root=== | |||
* Timeline of ICANN's efforts to preserve and enhance the global interoperability, resilience, and openness of the DNS/Internet<ref>[https://www.icann.org/resources/pages/governance/bylaws-en/#article1 Section 1.2, ICANN Bylaws]</ref> | |||
* Timeline of ICANN's efforts to withstand attempts at splintering the Internet and outlast [[Alternative Roots|competitors]] | |||
==References== | |||
[[Category:ICANN Initiatives]] |
Latest revision as of 17:39, 20 January 2023
ICANN Initiatives are designed to fulfill
- ICANN's mission of ensuring the stable, secure, and resilient operation of the Internet's unique identifier systems[1];
- ICANN's core values, which 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; and
- ICANN's technical commitment to maintaining a single, global authoritative root.[2]
Overview[edit | edit source]
Technically, ICANN must do no more or less than
- coordinate 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;
- coordinate and facilitating the stability, security and resiliency and policy of the aforementioned systems;
- collaborate with the technical community in developing these systems' protocols;
- maintain and operate the L-root;
- manage ICANN's operations and internal systems; and
- provide a publicly accessible information resource on these functions for the greater Internet community.[3]
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[edit | edit source]
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.” [4]
- 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. [5]
- 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.[6]
- 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.[7]
- 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."[8][9]
- 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.”[10]
- 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.” [11]
- 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.[12]
- 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.[13]
- 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.[14]
- 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.[15]
- 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.[16]
- May 2009: ICANN releases the "Plan for Enhancing Internet Security, Stability, and Resiliency."[17]
- 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.[18][19]
- 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).[20][21]
- 2010:
- October 2010: Scaling the Root Study Findings:
- The deployment of IPv6, DNSSEC, and IDNs to the root system has had no significant harmful impact.
- 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.[22]
- November 2010: ICANN updated its strategic plan for enhancing the SSR of the DNS.[23]
- 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."[24]
A Secure Internet[edit | edit source]
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."[25]
A Resilient Internet[edit | edit source]
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.”[26]
- 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."[27]
- 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." If there is a majority or more of Interim Directors, 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
- 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
- All Stream 2 Recommendations must "maintain the security, stability and resiliency of the DNS" among other principles.[28]
Accountable and Transparent Governance of Names, Numbers, and Protocols[edit | edit source]
ICANN Accountability has been an ongoing topic since the birth of the organization. Article 4 of the ICANN Bylaws states: "In carrying out its Mission, ICANN shall be accountable to the community for operating in accordance with the Articles of Incorporation and these Bylaws, including the Mission set forth in Article 1 of these Bylaws."[29]
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. The 2002 Evolution and Reform Process resulted in the creation of Article 4, along with the establishment of ICANN's Reconsideration mechanism, the Independent Review Panel, and the office of the ICANN Ombudsman.[30] The IANA Functions Stewardship Transition expanded ICANN's mission slightly (to incorporate the oversight of the IANA functions and the creation of the PTI), as well as incorporating the Affirmation of Commitments into ICANN's bylaws, memorializing the structure and rules for Specific Reviews.
Amendments to Bylaws & Specific Review Processes[edit | edit source]
<timeline>
- 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>
A Unified, Global Internet[edit | edit source]
ICANN's core values are meant to reflect and encourage the functional, geographic, and cultural diversity of the Internet.
Seeking Diversity, Equity, & Inclusion[edit | edit source]
- Timeline of DEI efforts at ICANN
- Coalition for Digital Africa
A Single Authoritative Root[edit | edit source]
- Timeline of ICANN's efforts to preserve and enhance the global interoperability, resilience, and openness of the DNS/Internet[31]
- Timeline of ICANN's efforts to withstand attempts at splintering the Internet and outlast competitors
References[edit | edit source]
- ↑ Section 1.1, ICANN Bylaws
- ↑ Section 1.2, ICANN Bylaws
- ↑ Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN
- ↑ https://www.ntia.doc.gov/federal-register-notice/1998/statement-policy-management-internet-names-and-addresses
- ↑ White Paper Principles, ICANN Briefing Book
- ↑ Jonathan Weinberg, "ICANN, 'Internet Stability,' and New Top Level Domains," Arxiv, pg. 30
- ↑ Interim Report of Working Group C of the Domain Name Supporting Organization, 10/23/1999
- ↑ Criteria for Assessing TLD Proposals (Aug. 15, 2000)
- ↑ Jonathan Weinberg, "ICANN, 'Internet Stability,' and New Top Level Domains,' footnote 72
- ↑ Cerf Testimony 02/08/01, ICANN
- ↑ Signposts in Cyberspace: The Domain Name System and Internet Navigation, pg. 62
- ↑ New gTLDs WG Final Report May 2007, GNSO, ICANN
- ↑ DNS Stability, 2008, ICANN Archives
- ↑ DNS Stability, 2008, ICANN Archives pg. 4
- ↑ DNS Stability, 2008, ICANN Archives pg. 5
- ↑ Summary of Impact of Root Zone Scaling, 10/06/2010, ICANN Archives
- ↑ ICANN releases Plan for Enhancing SSR, ICANN Announcements
- ↑ RSSAC023: History of the Root Server System, pg. 28
- ↑ RIPE NCC and ICANN Commit to Ongoing DNS Root Name Service Coordination, RIPE NCC New Archives
- ↑ CEO talks about New AoC 2009, ICANN Announcements
- ↑ 2010 Strategic SSR Initiatives, ICANN
- ↑ Summary of Impact of Root Zone Scaling, 10/06/2010, ICANN Archives
- ↑ SSR Plan FY11, ICANN
- ↑ Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN
- ↑ Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN
- ↑ Draft Statement of ICANN's role/remit in SSR, Public Comment Proceedings, ICANN
- ↑ SSR Plan FY 2014, ICANN
- ↑ ICANN Bylaws as Amended on 10/01/2016, ICANN Bylaws Archives
- ↑ Article 4, ICANN Bylaws, as amended November 28, 2019
- ↑ Article 4, ICANN Bylaws, as revised December 15, 2002
- ↑ Section 1.2, ICANN Bylaws