Intlnet Draft on IANA transition
This memo documents how the ICANN accountability to the USG is in the process of being transferred to the IAB through a transition mechanism that was prepared and agreed to 15 years ago that can now be seamlessly implemented over the coming years by the sole parking of "iana.arpa" at "iana.org".
- 1 1. Introduction
- 2 2. Transition principles
- 3 3. Background
- 3.1 3.1. DNS Parameters
- 3.2 3.2. The IANA
- 3.3 3.3. The IANA functions
- 3.4 3.4. The IANA IETF oversight
- 3.5 3.5. The NTIA
- 3.6 3.6. ICANN
- 4 4. IANAPLAN
- 5 5. Responding to general questions raised by ICANN
- 6 6. IANA Considerations
- 7 7. Security Considerations
- 8 8. References
- 9 9. Author
On March 14, 2014, the NTIA announced that, in order to "support and enhance the multistakeholder model of Internet policymaking and governance, the U.S. Commerce Department’s National Telecommunications and Information Administration (NTIA)", it intended, which would mark the final phase of the privatization of the DNS as outlined by the U.S. Government in 1997, "to transition key Internet domain name functions to the global multistakeholder community". As the first step, the NTIA asked the Internet Corporation for Assigned Names and Numbers (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's responsibility includes:
- the procedural role of administering changes to the CLASS "IN" authoritative root zone file – the database containing the lists of names and addresses of all CLASS "IN" top-level domains
- as well as serving as the historic steward of the DNS.
"The timing is right to start the transition process," said Assistant Secretary of Commerce for Communications and Information Lawrence E. Strickling.
1.1. the transition process
The NTIA considers that ICANN is uniquely positioned as the current contractor for IANA functions and the global coordinator for the CLASS “IN” DNS to be the appropriate party to convene the multistakeholder process to develop the transition plan. NTIA has, therefore, informed ICANN that it expected that in the development of the proposal, ICANN will work collaboratively with the directly affected parties, including:
- the Internet Engineering Task Force (IETF),
- the Internet Architecture Board (IAB),
- the Internet Society (ISOC),
- the Regional Internet Registries (RIRs),
- top level domain name operators,
- and other interested global stakeholders, i.e. the global communities identified by the IEEE, IAB, IETF, ISOC, and W3C in their OpenStand RFC 6852 joint "statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards" which have become known as the "OpenStand" principles.
1.2. The convergence of the internet governance
The target is to use a multistakeholder approach to make their proposals, practices, and competitive innovations converge along this OpenStand paradigm for standards where the economics of global markets, fueled by technological advancements, drive the global deployment of standards and cooperative agreements and practices regardless of their formal status.
In this paradigm, standards, governance cooperative agreements, and practices support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation in turn contributes to the creation of new markets and the growth and expansion of existing markets.
1.3. An orderly Transition
While stakeholders work through the ICANN-convened process to develop this transition proposal convergence calling for a minimum of change for the incumbent stakeholders and a simple adaption for the new entrants, the NTIA’s current role will remain unchanged, knowing that the current IANA functions contract expires September 30, 2015. Other conveners, with different transition perspectives for the Internet evolution within the Whole Digital Ecosystem (WDE), have engaged their own reflection concerning the internet evolution.
2. Transition principles
To be successful, the NTIA's transition of "key Internet domain name functions to the global multistakeholder community" demands the respect of five demands and nine principles that are well identified.
2.1. the demands and principles of the Modern Paradigm for Standards as listed by RFC 6852, which have made possible, with great speed and effectiveness, the huge bounty realized by the global economy due to the Internet and the World Wide Web, only because the key characteristics of their modern global standards paradigm.
- 2.1.1. Cooperation.
- 2.1.2. Adherence to five principles:
- Due process.
- Broad consensus.
- 2.1.3. Collective empowerment striving for standards that:
- based on technical merit as judged by the contributed expertise of each participant;
- provide global interoperability, scalability, stability, and resiliency;
- enable global competition;
- serve as building blocks for further innovation; and
- contribute to the creation of global communities, benefiting humanity.
- 2.1.4. Availability. Standards specifications are made accessible to all for implementation and deployment.
- 2.1.5. Voluntary adoption: voluntary adoption and success determined by the market.
2.2. the four required by the NTIA for the transition to have broad community support.
- Support and enhance the multistakeholder model;
- Maintain the security, stability, and resiliency of the Internet DNS;
- Meet the needs and expectations of the global customers and partners of the IANA services; and,
- Maintain the openness of the Internet.
The Domain Name System (DNS) is a critical component of the Internet infrastructure. It allows users to identify websites, mail servers, and other Internet destinations using easy-to-understand names (e.g. www.ntia.doc.gov) rather than the numeric network addresses (e.g. 184.108.40.206) necessary to retrieve information on the Internet.
3.1. DNS Parameters
RFC 6895 documents that the Domain Name System (DNS) provides replicated distributed secure hierarchical databases that store "resource records" (RRs) under domain names. DNS data is structured into CLASSes and zones that can be independently maintained (DNS CLASSes have been little used but constitute another dimension of the DNS distributed database. In particular, there is no necessary relationship between the namespace or root servers for one data CLASS and those for another data CLASS. The same DNS NAME can have completely different meanings in different CLASSes. The label types are the same, and the null label is usable only as a root in every CLASS. As global networking and DNS have evolved, the IN, or Internet, CLASS has dominated DNS use. There are currently two subcategories of DNS CLASSes: normal, data-containing classes; and QCLASSes that are only meaningful in queries or updates.
CLASSes numbers are assigned by the IETF. The "IN" CLASS that ICANN manages is the "01" CLASS. The IETF can assign 34,000 other CLASSes. 255 CLASSes are reserved for users’ private use.
3.2. The IANA
Registries of the parameter values for use in IETF protocols, like the DNS, protocols, IP address registries, etc. are stored and maintained for the IETF by the Internet Assigned Numbers Authority (IANA), and are the subject of the "IANA Considerations" section in many RFCs.
"The Internet Assigned Numbers Authority (IANA) [therefore] administers various protocol parameters used by IETF protocols, delegating this administration as appropriate. The IAB must approve the appointment of an organization to act as IANA on behalf of the IETF. The IANA takes technical direction on IETF protocols from the IESG" (RFC 2850).
3.3. The IANA functions
The Internet Assigned Numbers Authority (IANA) functions are a set of interdependent technical functions that enable the continued efficient operation of the Internet. The IANA functions include:
- (1) the coordination of the assignment of technical Internet protocol parameters;
- (2) the processing of change requests to the authoritative root zone file of the DNS and root key signing key (KSK) management;
- (3) the allocation of Internet numbering resources; and
- (4) other services related to the management of the ARPA and INT top-level domains (TLDs).
The IANA furnctions include the intellectual property protection of three names attached to their performance, namely ARPA, IANA and INTERNIC.
The related CLASS "IN" root zone management functions are the management of the CLASS "IN" root zone “zone signing key” (ZSK), as well as the implementation of changes to and distribution of the CLASS "IN" DNS authoritative root zone file, which is the authoritative registry containing the lists of names and addresses for all CLASS "IN" top level domains, effectively the Internet’s CLASS "IN" phone book.
The IANA functions were initially performed under a series of contracts between the Department of Defense’s Advanced Research Projects Agency (DARPA) and the University of Southern California (USC), as part of a research project known as the Terranode Network Technology (TNT). The role was delegated to NTIA when President Clinton issued a directive in 1997 to privatize and internationalize the coordination of the DNS.
Note: The operation of and responsibility for the three legacy top level domains associated with the U.S. Government (specifically .mil, .gov, and .edu) are not impacted by this transition as they are not part of the IANA and CLASS "IN" related root zone management functions.
3.4. The IANA IETF oversight
For a number of years, this IANA function has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). The IETF's relationship with ICANN over the IANA functions was formalized through:
1. a Memorandum of Understanding between the IETF and ICANN that was codified in June 2000 with the publication of RFC 2860.
2. the IAB RFC 3172 addresses the modalities of the .ARPA zone management, which the NTIA considers as an IANA function. As such, the Department of Commerce requests that (cf. Section 3.5.), as part of the IANA functions, ICANN undertake the administration of the arpa TLD in cooperation with the Internet technical community under the guidance of the IAB, as a limited use domain for Internet infrastructure applications, including the migration of Internet infrastructure applications that currently reside in the “.int” TLD.
Over time, processes and role definitions have evolved, have been documented in supplemental agreements, and have met delays.
3.5. The NTIA
NTIA is the Executive Branch agency that is principally responsible for advising the US President on telecommunications and information policy issues. NTIA’s programs and policymaking focus largely on ensuring that the Internet remains an engine for continued innovation and economic growth.
3.5.1. The NTIA role
NTIA’s role includes the procedural role of administering changes to the CLASS "IN" authoritative root zone file and serving as the historic steward of the CLASS "IN" DNS, a role that has helped provide confidence in the system. NTIA contracts with ICANN to carry out the IANA functions and has a cooperative agreement with VeriSign to perform the related CLASS "IN" root zone management functions. NTIA’s role is largely symbolic. NTIA has no operational role and does not initiate changes to the CLASS "IN" authoritative root zone file, assignment of protocol numbers, or allocation of Internet numbering resources.
NTIA’s role has been to smooth the transition of the IANA functions to the global multistakeholder community. NTIA’s role was always meant to be a temporary and transitional role only with the goal of completing the transition by 2000.
3.5.2. NTIA practical administration
Pursuant to a contract and a cooperative agreement administered by NTIA:
- the IANA functions are performed by the Internet Corporation for Assigned Names and Numbers (ICANN)
- VeriSign performs the related root zone management functions. The only potential change for Verisign, due to the transition of the key Internet domain name functions to the global multistakeholder community, will be the maintenance and publication of the CLASS "IN" Root Zone, which Verisign has performed as a community service spanning three decades, and that the NTIA thanks them for.
Aspects of the IANA functions contract are inextricably intertwined with the VeriSign cooperative agreement (i.e., CLASS "IN" authoritative root zone file management), which would require NTIA to coordinate a related and parallel transition in these responsibilities.
3.5.3. Jurisdictionnal transition
The transition of the current role played by NTIA in the coordination of the Internet’s domain name system (DNS) ,
(1) will result, in the USA, in a transfer of Internet DNS affairs from the Executive Branch (NTIA) to the common Legislative and Judiciary Branches (FCC). This transition has been engaged by US Executive (President) asking the FCC to enter into an internet "reclassification" process that may conflict with other US and/or foreign laws.
(2) possible impact on the WIPO UDRP in the case of US managed CLASS "IN" zones, the Working Goup has no competence to investigate.
ICANN is a not-for-profit public-benefit corporation that provides for the coordination of the Internet's CLASS "IN" naming system. As such, it has an important visibility. It provides the coordination of the operation of CLASS "IN" root name servers, oversees the Internet Protocol address spaces for IPv4 and IPv6 by the regional Internet registries, ensures the management of the .int DNS zone and has signed with the Internet Engineering Task Force a Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority (IANA) (RFC 2860) that makes it accountable to the IETF both for the provision of the IANA technical work and its cooperation concerning the management of the .arpa zone with the IAB (as organized by BPC 52).
RFC 2860 recognizes that ICANN may, through the IANA, provide similar services to other organizations with respect to protocols not within IETF's scope (i.e. registries not created by IETF or IRTF action); nothing in this MOU limits ICANN's ability to do so.
3.6.1. A mature and committed organization
The NTIA has acknowledged that ICANN as an organization has matured and taken steps in recent years to improve its accountability and transparency and its technical competence. An Affirmation of Commitments (AoC) reaffirms commitments relating to the global technical coordination of the DNS, and provides for global multistakeholder reviews of various aspects of ICANN’s operations.
- These reviews, and the underlying agreement between NTIA and ICANN, would not be impacted by any transition of the IANA and related root zone management functions.
- This Affirmation is an agreement that includes multistakeholder oversight mechanisms to address accountability and transparency in ICANN’s decision-making, the security, stability, and resiliency of the Internet DNS, as well as promote competition, consumer trust, and consumer choice. There are no plans to terminate the Affirmation of Commitments. NTIA supports the efforts to further globalize ICANN’s commitments, including multistakeholder accountability and oversight mechanisms.
3.6.2. ICANN accountability
There is a discussed difficulty resulting from the NTIA removal, which is the end of the perceived ultimate backstop with regard to ICANN's organization-wide accountability provided by the NTIA's role, such as the renewal process of the IANA functions contract.
There is, therefore, a need to evaluate if the systemic issues caused by the change in the DNS related historical relationship with the United States, against internal or external captures or takeovers, and safeguards against capture at all levels, are or are not addressed by the contracted accountability to the IETF in the IANA management.
This means that everything is to be made for:
- 1) the loss of the RFC 2860/RFC 3172 organized technical work concerning the IANA and .arpa to be in the future an equivalent deterrent to a non-renewal of the NTIA contract.
- 2) the internet community to trust there is a credible contingency alternative that would reduce the risks of conflict, in encouraging community responsible research and experimentation in the DNS area, as per the ICP-3 ICANN statement of the policy currently followed in administering the CLASS "IN" authoritative root of the Domain Name System.
As documented in this memo,
- ICANN has had a contract with the US Department of Commerce (DoC) undertaken through the National Telecommunications and Information Administration (NTIA)
- to provide the IANA function
- according to the technical work terms of RFC 2860
- to be managed by the IAB along with the RFC 3172 with some delays.
In March of 2014, NTIA announced its intention to transition out of its current role, meaning that NTIA would not need to renew its contract with ICANN when that contract expires on September 30, 2015. NTIA requested a transition proposal be prepared to outline the necessary arrangements. In the case of the elements of the IANA function concerning the IETF protocol registries, it is likely that the existing well-documented practices will continue and no or little new activity will be required
- once the BCP 52 framework has been finalized on the IAB/IETF side in a way that should not affect those practices.
- in a manner that can influence the practice of other SDO in their own dealing with the ICANN or other organizations as the operator of their own names, numbers, documentation, and parameters repository.
In addition, it is expected that like other stakeholders that are part of its multistakeholder model, that governments and the Libre intelligent internet oriented user communities will have an opportunity to provide input either via ICANN’s Governmental Advisory Committee (GAC) and IUse groups or as individual governments and lead users.
4.1. An IETF uncompleted situation
The IANAPLAN working group has been chartered to produce an IETF consensus document that describes the expected interaction between the IETF and the operator of IETF protocol parameters registries. This WG has concluded that:
1. the system in place today for the oversight of the IETF protocol registries component of the IANA function works well.
2. in terms of the ICANN accountability mechanism, it will be completed by the end of the NTIA oversight, as agreed by all of the parties in 2000 through:
- the RFC 2860 Section 4.2., which states: "In the event of technical dispute between the IANA and the IESG, both will seek guidance from the IAB whose decision shall be final."
- the last provision of RFC 2860 Section 4.3., which stipulates that: "In the event ICANN adopts a policy that prevents it from complying with the provisions of this Section 4 with respect to the assignments described in (a) - (c) above, ICANN will notify the IETF, which may then exercise its ability to cancel this MOU under Section 2 above.
- the RFC 3172 which states:
- 1) in its Section 2.1. that when the IANA considerations of an approved RFC proposes the use of an "arpa" sub-domain, "the IESG will ask the IAB to request the IANA to add the corresponding protocol object sub-domain domain to the "arpa" domain, in accordance with RFC 2860, with the administration of the sub-domain undertaken in accordance with the provisions described in this document." including its Section 4.3. above.
- 2) in its Section 5 that: "Any infrastructure domains that are located in a place other than in the DNS tree as sub-domains of "arpa", for historical or other reasons, should adhere to all of the requirements established in this document for the sub-domains of "arpa", and consideration should be given to migrating them into "arpa" as and when appropriate."
4.2. Actions to be planned
4.2.1. A minimal change in the oversight of the IETF protocol parameters registries is preferred in all cases and no change is preferred when possible, this fully addresses the external implications of moving the NTIA out of its current role with respect to IANA on the IETF protocol parameters registry function in simply finalizing the transparent continuation of the current 15 year old arrangements and their yearly updates since 2007.
This Working Group has not identified any need within its scope other than to consider that the NTIA transition is the appropriate time to complete the RFC 3172 Section 5 migration.
4.2.2. The "IETF/IANAPLAN" working group is being chartered solely with respect to the planning that is needed for the transition, and not to cover other topics related to IANA, and the required improvements outside that scope will be set aside for future consideration.
The Working Group considers that the migration will call for an ARPA permanent oversight by the IAB as implemented on Sept 1, 2014.
Fully documenting the resulting management procedures and interaction between the IETF and the operator of IETF protocol parameters registry, which are to be delegated to and handled by the IAB or IAOC, is out of the working group charter and it, therefore, requests the IAB or IAOC to provide them separately.
4.2.3. The mechanisms required to address the removal of the overarching NTIA contract may require additional documentation or agreements. The WG will identify, but not create, such required agreements.
This Working Group has identified none of them.
4.2.4. Should proposals be made by other communities regarding the transition of other IANA functions affect the IETF protocol parameter registries or the IETF, the WG may also review and comment on them.
The Working Group has been informed of the Libre Intelligent Internet Users Working Group proposal. It has identified that this proposal is orthogonal to the end to end IETF area as it only considers the fringe to fringe layers. However, it calls the IAB and IAOC attention to its implied full use of the RFC possibilities in terms of:
- other DNS CLASSes by other root administrators and users.
- the multiplicity of documentation, names, numbers, and protocol parameter registries.
The documentation provided by the IAB and IAOC as requested by section 4.2.2. SHOULD carefully consider the resulting technical, political, and legal possible positive and negative implications of this new state-of-the art internet.
5. Responding to general questions raised by ICANN
ICANN has formed an "IANA Stewardship Coordination Group" (ICG) to gather comments from those with direct operational or service relationships with the IANA functions operator, in connection with names, numbers, or protocol parameters)". The questions raised by the ICG are of interest to this Working Group when they are general enough to concern non-specific users or operators of the IETF technology, in particular in the context of Section 4.2.4 above.
5.1. The SDOs are not questioned
The ICG only considers the names, numbers, and protocol parameter communities. Not the documentation community. This might result from the past experience of the IANA repository which is separated from the RFC Editor.
There is a recurrent request of the IUser community for the presentation of an Internet Good Book consolidation maintained either by the IANA section of the IESG approved documents or by a separate Good Book section.
Attention should be paid by the IAB to such an IANA presentation, not only as tables of names, numbers, and parameters, but also by consolidated comprehensive documentation.
5.2. Description of Community’s Use and Arrangements of the IANA Functions
This memo does not attempt to discuss IETF specifics that are out of its charter.
5.3. Requested Post-Transition Oversight and Accountability Arrangements
This Working Group has not identified any other change due to the oversight transition that the appropriate time to accomplish the migration from the iana.org to the iana.arpa zone agreed on 15 years ago.
This migration can be carried progressively in having "iana.arpa" registered in the arpa.zone and redirected in parallel to iana.org for several years. New IANA considerations creating new "arpa" sub-domains should progressively lead to the migration of the different uses.
5.4. NTIA Requirements
NTIA has established that the transition proposal must:
- Support and enhance the multistakeholder model: an opportunity would be for the IAB to document the use of the "arpa" zone by other stakeholder and SDO registries.
- Maintain the security, stability, and resiliency of the Internet DNS: the migration is to consolidate and delegate the sub-domains of "arpa" in accordance with the "IANA Considerations" section of IETF Standards Track documents, under the scope of section 4 of the MoU between the IETF and ICANN concerning the IANA.
- Meet the needs and expectation of the global customers and partners of the IANA functions. The NTIA considers that the .arpa zone management is an IANA function. The agreement on this matter between IETF and ICANN is 15 years old. The NTIA oversight transition is the proper time to accomplish it. It confirms an acceptable response to the ICANN accountability issue.
- Maintain the openness of the Internet: the documentation, names, numbers, and protocol parameters are given an open and independent home conforming to BCP 52.
- Stay abreast of a government-led or an inter-governmental organization solution. This solution responds to the global interest of the IANA functions in keeping them solely dependent on the OpenStand SDOs, the internet global communities, and their stakeholders.
6. IANA Considerations
This memo is for proposing single technical proposals: the parking of the IAB owned "iana.arpa" domain name at "iana.org". There is a need to clarify the intellectual property protection mechanism of the non-protected ARPA name, of the IANA name, initially a registered trademark of ATT currently owned by the current IANA functions operator (ICANN), and of the INTERNIC name currently owned by the US Department of Commerce. Coordination of this issue should rest with IAB and NTIA.
As per RFC 2860, the current IANA functions operator (ICANN) has full authority to enlarge the IANA functions to provide similar services to other organisations with respect to protocols not within IETF's scope (i.e. registries not created by IETF or IRTF action). This is in full agreement with the RFC 6852 principles: it should help coordinating an environment which embraces "a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status".
7. Security Considerations
There is no security implication other than a further possible parking of the "iana.org" domain name at "iana.arpa" and what may result from the extension of the IANA functions discussed in the IANA considerations section.
[RFC1034] Mockapetris, P. (Domain names - concepts and facilities) STD 13 November 1987.
[RFC1958] Carpenter, B., Ed. (Architectural Principles of the Internet) June 1996.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts (Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority) June 2000.
[RFC3172] Huston, G., Ed. (Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain (arpa)) BCP 52, September 2001.
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB (The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture), March 2004.
[RFC5226] Narten, T. and H. Alvestrand (Guidelines for Writing an IANA Considerations Section in RFCs) BCP 26, May 2008.
[RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board (Defining the Role and Function of IETF Protocol Parameter Registry Operators), April 2011.
[RFC6761] S. Cheshire, M. Krochmal (Special-Use Domain Names), February 2013
[RFC6852] R. Housley, IETF Chair, S. Mills, IEEE-SA President, J. Jaffe, W3C CEO, B. Aboba, IAB Chair, L. St.Amour, ISOC President and CEO, (Affirmation of the Modern Paradigm for Standards), January 2013
J-F C. (Jefsey) Morfin
120 Chemin des Crouzettes
34730 Saint-Vincent de Barbeyrargues