Skip to main content

Correspondence from the IAB to the National Telecommunications and Information Administration, US Department of Commerce regarding the ICANN/DoC Joint Project Agreement, 15 February 2008
statement-iab-2008-02-15-midterm-view-icann-doc-jpa-00

Document Type IAB Statement
Title Correspondence from the IAB to the National Telecommunications and Information Administration, US Department of Commerce regarding the ICANN/DoC Joint Project Agreement, 15 February 2008
Published 2008-02-15
Metadata last updated 2023-08-09
State Active
Send notices to (None)
statement-iab-2008-02-15-midterm-view-icann-doc-jpa-00
To: JPAMidTermReview@ntia.doc.gov 
From: IAB Chair <iab-chair@ietf.org>
Subject: Midterm review of the ICANN/DOC Joint Project Agreement. 
Date: Fri, 15 Feb 2008 01:27:12 -0800 (PST) 
Cc: iab@iab.org

For Ms. Suzanne R. Sene of the National Telecommunications and Information Administration, U.S. Department of Commerce.

This memo is in response of the Notice of Inquiry by the Honorable John Kneuer d.d. October 30, 2007, related to the midterm review of the ICANN/DOC joint project agreement (Docket No 071023616-7617-01).

With regard to the joint project agreement between ICANN and the DOC our main interest concerns the Internet’s system of unique identifiers other than Domain Names and IP addresses. Our comments are therefore primarily addressed to question #1 in the DoC’s Request for Comments [1].

The IANA Function from the IETF Perspective

The Internet Engineering Task Force (IETF), which develops and maintains the specifications for key Internet technologies (such as the Internet Protocol, IP), reviews and assigns unique values to numerous parameters. These parameters need to be unique and stable in order to guarantee interoperability of devices and applications on the Internet and are therefore subject to registration in a registry under the control of the IETF.

Historically recording the allocation of new values for technical parameters, maintenance of the tables of registered values, and dissemination of the current tables has been delegated to an IETF function known as IANA. ICANN currently carries out this IANA function under the terms of an agreement between ICANN and the IETF[2].

In 2005, the IETF established the IETF Administrative Support Activity (IASA) [3] housed within the Internet Society (ISOC), and this entity now executes and administers contracts with the IETF’s administrative support organizations including the organization providing the IANA function. Oversight of these contracts is provided by the IAOC (IETF Administrative Oversight Committee).

The IAOC reviews the operation of the service level agreement that forms part of the ICANN/IETF agreement once per year and receives monthly reports which are also available to the wider community. Recent reviews have confirmed that IANA is meeting the SLA and making progress towards more ambitious targets. From that we conclude that the agreement is working satisfactorily and we do not believe that any changes in the agreement are necessary at this time.

IETF and the Technical Parameters

Stability of the technical parameter registry is of paramount importance for the development and deployment of interoperable technologies and applications on the Internet. The JPA concluded between DoC and ICANN on 29 September 2006, continued the task (as lined out in the 25 November 1998 MoU) of ‘coordination’ of the Internet’s system of unique identifiers. This included the requirement “to ensure the stable and secure operation of the Internet’s unique identifier systems”. As we have noted above and have stated in previous submissions to the DoC relating to the ICANN agreement [4, 5, 6], the IETF maintains that any extension of the responsibilities of ICANN beyond coordination as it is currently implemented through the IANA MoU into the area of implementation would impede the IETF from meeting its responsibilities in developing global consensus-based standards upon which the Internet depends.

The IETF responsibilities with respect to the technical parameters are that as part of its standards specification process, each new parameter type definition includes a specification of the method of allocation of parameter values, as well as provision for appropriate technical review and acceptance. Where specific expertise will be required to evaluate any request, the IETF provides a “designated expert” to support the allocation function. These specifications are developed in the IETF’s usual international, open, consensus-based e-mail discussion venues. Dispute resolution, when needed, occurs within the IETF organization.

Towards Private Sector Handoff

We appreciate the current implementation of the relation between the IETF and ICANN with respect to the IANA function. However, to complete the private sector handoff and bring the JPA to successful closure, the rightful role of the IETF must be clearly articulated and addressed in any agreements. The DNS Whitepaper Project has given ICANN only the task of coordinating technical protocol parameter assignment, and ICANN currently carries out assignment of those parameters only under the terms of a separate agreement between ICANN and the IETF. The IETF expects that ICANN will continue, as part of its coordination activity, to honor that agreement both in spirit and letter. However, the IETF retains the right to terminate that agreement and move its protocol assignment function elsewhere, without prejudice of its support of the ICANN implementation of the DNS whitepaper private sector model.

For the IAB,

Olaf M. Kolkman, IAB Chair.

About the Organizations

IAB

The Internet Architecture Board has a long history but is currently viewed as a senior committee in the IETF which has both technical (architectural) functions and oversight functions for the development of the Internet. The latter include oversight of IANA functions performed for the IETF. See http://www.iab.org/.

IETF

The Internet Engineering Task Force is a worldwide and open organization whose mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. See

http://www.ietf.org/.

IASA

The IETF Administrative Support Activity was created in 2005. It provides the administrative structure required to support the IETF standards process and to support the IETF’s technical activities. The IETF expects the IASA to contract this work from others and to manage these contractual relationships to achieve efficiency, transparency, and cost effectiveness. IASA is housed within ISOC.