The IAB position on the IETF IANA Technical Parameter Function

This version:  March 6, 2006.

The work of the IETF in formulating and publishing Internet standards is heavily dependent upon the technical parameter assignment IANA function.  This is a “living document” which describes concerns with the existing management of that function, and the IAB’s guidance for resolving  those issues.

The IETF technical parameter assignment function and IANA

The IETF provided a public comment [1] on the US Department of Commerce’s RFI [2] for the IANA function.  The public comment provided some clarifications of the function.

Some History

In 1998, DoC signed an agreement with ICANN [6] to “coordinate” various activities, including “Coordination of the assignment of other Internet technical parameters as needed to maintain universal connectivity on the Internet;”. Following the February1999 clarification of ICANN’s understanding of “coordination” [7],  the IETF established an effort to undertake this work cooperatively with ICANN on the basis of a Memorandum of Understanding documented in RFC2860 [3]. This MoU was signed by the IETF and ICANN on March 1, 2000 and ratified by ICANN’s Board on March 10, 2000.

That MoU remains a constructive expression of the separation of responsibility for the entire set of activities that grew out of the original Internet Assigned Numbers Authority. The separation of the technical parameter assignment function that it established and which the current RFI recognizes (subject to the corrections noted in the IETF’s public response) has proved highly successful in separating technical and policy issues. However, in spite of the best intentions and efforts on both sides of the MoU, the IETF has had occasion to express dissatisfaction with the operational results [4].

In the interim, the situation has improved, but much work remains to be done.

The publication by the Department of Commerce puzzles us.  The RFI does not refer to or acknowledge RFC2860, and it was published without any discussion with the IETF. Further it appears to extend beyond “coordination” to “implementation”.  This suggests there is some expectation that the implementation of the technical protocol parameter assignment function may be assigned elsewhere, without the IETF’s involvement, even as we are working actively with ICANN to improve the existing operational relationship.  We find this peculiar because the IETF has responsibility for the technical parameter assignment as part of the IETF’s mission to develop standards for the Internet.

Moving forward

In 2005, the IETF established the IETF Administrative Support Activity (IASA), housed within the Internet Society (ISOC) [5], which has contractual relationships defined with two of the IETF’s three supporting organizations.  The IASA is the home of all IETF-related operational agreements going forward.

The IAB is working with the IASA to determine the best way to handle the IETF’s technical parameter assignment function going forward.  As noted in our comment on the RFI, our preferred path forward is for the Department of Commerce to separate the IANA technical paramter function out of the RFI material, and the IASA will establish appropriate contractual relations on behalf of the IETF for the IETF’s work.

References

[1] See Appendix

[2] http://www.fbo.gov/spg/DOC/OS/OAM/Reference%2DNumber%2DDOCNTIARFI0001/SynopsisR.html

[3] http://www.ietf.org/rfc/rfc2860.txt

[4] http://www.iab.org/documents/correspondence/2004-09-27-iana-concerns.html

[5] http://www.ietf.org/rfc/rfc4071.txt

[6] http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm

[7] http://www.icann.org/correspondence/bradner-dyson-25feb99.htm

Background:  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.

ISOC.  The Internet Society is a not-for-profit membership organization founded in 1992 to provide leadership in Internet related standards, education, and policy. With offices near Washington, DC, and in Geneva, Switzerland, it is dedicated to ensuring the open development, evolution and use of the Internet for the benefit of people throughout the world. ISOC is the organizational home of the IETF and other Internet-related bodies who together play a critical role in ensuring that the Internet develops in a stable and open manner. For over 13 years ISOC has run international network training programs for developing countries and these have played a vital role in setting up the Internet connections and networks in virtually every country connecting to the Internet during this time. See http://www.isoc.org

Appendix:  Public Comment on DOC Solicitation DOCNTIARFI0001, dated February 21, 2006.

March 6, 2006, Reston, VA and Geneva, Switzerland

Honorable John Kneuer (Assistant Secretary for Communications and
Information, US Department of Commerce)

DOC Solicitation DOCNTIARFI0001, dated February 21, 2006.

This is a public comment on the above cited solicitation (RFI) [1]
related to the Internet Assigned Numbers Authority (IANA). It is sent
jointly by the Internet Architecture Board (IAB) and the Internet
Engineering Task Force (IETF).

Clarification of technical parameter assignment function.

Specifically, the "technical parameters" portion of the IANA RFI [2]
describes the management of parameters defined by IETF standards. 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.

There is a factual error in the RFI's description of the current
technical parameter assignment function. It incorrectly associates
"reservation and direct allocation of space for special purposes, such
as multicast addressing, addresses for private networks, and globally
specified applications" with the IP address management function. These
allocations are in fact standards-based allocations developed and
controlled by the IETF. IANA’s function is to record these allocations.

We also point out a similar omission from the RFI's description of the
technical parameter assignment function. It fails to list assignments
of domain names for technical uses (such as domain names for inverse
DNS or ENUM lookup) which are also standards-based allocations
developed and controlled by the IETF, which IANA records.

Moving forward

In 1998, DoC signed an agreement with ICANN [3] to “coordinate” various
activities, including “Coordination of the assignment of other Internet
technical parameters as needed to maintain universal connectivity on
the Internet;”. This RFI appears to extend beyond “coordination” to
“implementation”, and we believe such an extension would impede the
IETF from meeting its responsibilities in developing global consensus-
based standards upon which the Internet depends.

Further information on our concerns and position on the IETF’s
technical protocol parameter assignment function is available on-line.
[4].

We suggest the DoC separate the technical parameter assignment function
(as corrected above) from the other two functions since that is carried
out for and at the direction of the IETF. In 2005, the IETF established
the IETF Administrative Support Activity (IASA) [5] housed within the
Internet Society (ISOC), and this entity already has contractual
relationships defined with two of the IETF's three administrative
support organizations. The IASA is the home of all IETF-related
operational agreements going forward – including the IETF technical
parameter assignment function.

We appreciate the DoC's continuing support for the IETF's work and we
look forward to establishing a close working relationship with the DoC
in this matter.

Sincerely,
Leslie Daigle, Chair, Internet Architecture Board
c/o Internet Society, 1775 Wiehle Ave., Suite 102 Reston, VA 20190
Brian Carpenter, Chair, Internet Engineering Task Force
c/o Internet Society, 4 rue des Falaises, 1205 Geneva, Switzerland

References

[1] http://www.fbo.gov/spg/DOC/OS/OAM/Reference%2DNumber%2DDOCNTIARFI0001/SynopsisR.html

[2] "First, the Contractor would coordinate the assignment of technical
protocol parameters. This function would involve the review and
assignment of unique values to numerous parameters (e.g., operation
codes, port numbers, object identifiers, protocol numbers) used in
various Internet protocols. This function would also include
dissemination of listings of assigned parameters through various means
(including on-line publication) and the review of technical documents
for consistency with assigned values."

[3] http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm

[4] http://www.iab.org/documents/correspondence/IANA-2006/IAB-IANA-Position.htm

[5] http://www.ietf.org/rfc/rfc4071.txt