Internet DRAFT - draft-iab-iana-principles
draft-iab-iana-principles
Internet Architecture Board (IAB) R. Housley (editor)
Internet-Draft Vigil Security
Intended status: Informational O. Kolkman (editor)
Internet Society
Expires: 26 August 2015 26 February 2015
Principles for Operation of
Internet Assigned Numbers Authority (IANA) Registries
draft-iab-iana-principles-05
Abstract
This document provides principles for the operation of Internet
Assigned Numbers Authority (IANA) registries.
{{{ RFC Editor: Please delete the note prior to publication. }}}
Note: This Internet-Draft was developed by the IAB IANA Evolution
Program, and it should be discussed on the InternetGovtech@iab.org
mail list. See http://www.iab.org/mailman/listinfo/internetgovtech
for subscription details.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 August 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Housley & Kolkman Expires 26 August 2015 [Page 1]
Internet-Draft IANA Registry Principles February 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
0. Document Background
{{{ RFC Editor: Please delete this section prior to publication. }}}
This document is a split off from draft-iab-iana-framework-02. This
document contains principles that were scattered in various places in
the IANA Framework, pulling them into one place.
The IANA Framework has been under discussion since February 2011.
1. Introduction
The Internet Engineering Task Force (IETF) and its predecessors have
traditionally separated the publication of protocol specifications in
immutable Request for Comments (RFCs) and the registries containing
protocol parameters. The latter is maintained by a set of functions
traditionally known collectively as the Internet Assigned Numbers
Authority (IANA). Dating back to the earliest days of the Internet,
specification publication and the registry operations were tightly
coupled: Jon Postel of the Information Sciences Institute (ISI) of
the University of Southern California (USC) was responsible for both
RFC publication and IANA registry operation. This tight coupling had
advantages, but it was never a requirement. Indeed, today the RFC
Editor and IANA registry operation are provided by different
entities.
Internet registries are critical to the operation of the Internet,
since they provide a definitive record of the value and meaning of
identifiers that protocols use when communicating with each other.
Almost every Internet protocol makes use of registries in some form.
At the time of writing, the IANA maintains more than two thousand
protocol parameter registries.
Internet registries hold protocol identifiers consisting of constants
and other well-known values used by Internet protocols. These values
can be numbers, strings, addresses, and so on. They are uniquely
assigned for one particular purpose or use. Identifiers can be
maintained in a central list (such as a list of cryptographic
algorithms) or they can be hierarchically allocated and assigned by
separate entities at different points in the hierarchy (such as IP
Housley & Kolkman Expires 26 August 2015 [Page 2]
Internet-Draft IANA Registry Principles February 2015
addresses and domain names). To maximize trust and usefulness, the
principles in this document should be taken into consideration for
centralized registries as well as hierarchically delegated
registries. In hierarchically delegated registries, entries nearest
to top-level have broad scope, but lower-level entries have narrow
scope. The IAB will encourage support for these principles in all
delegations of Internet identifiers.
The registry system is built on trust and mutual cooperation. The
use of the registries is voluntary and is not enforced by mandates or
certification policies. While the use of registries is voluntary, it
is noted that the success of the Internet creates enormous pressure
to use Internet protocols and the identifier registries associated
with them.
This document provides principles for the operation of IANA
registries, ensuring that protocol identifiers have consistent
meanings and interpretations across all implementations and
deployments, and thus providing the necessary trust in the IANA
registries.
2. Principles for the Operation of IANA Registries
The following key principles underscore the successful functioning of
the IANA registries, and they provide a foundation for trust in those
registries:
Ensure Uniqueness: The same protocol identifier must not be used for
more than one purpose.
Stable: Protocol identifier assignment must be lasting.
Predictable: The process for making assignments must not include
unexpected steps.
Public: The protocol identifiers must be made available in a manner
that makes them freely available to everyone in well-known
locations.
Open: The process that sets the policy for protocol identifier
assignment and registration must be open to all interested
parties.
Transparent: The protocol registries and their associated policies
should be developed in a transparent manner.
Accountable: Registry policy development and registry operations
need to be accountable to the affected community.
Housley & Kolkman Expires 26 August 2015 [Page 3]
Internet-Draft IANA Registry Principles February 2015
3. Discussion
The principles discussed in Section 2 provide trust and confidence in
the IANA registries.
3.1. Ensuring Uniqueness, Stability, and Predictability
Protocol identifier assignment and registration must be unique,
stable, and predictable. Developers, vendors, customers, and users
depend on the registries for unique protocol identifiers that are
assigned in a stable and predictable manner.
A protocol identifier may only be reassigned for a different purpose
after due consideration of the impact of such a reassignment, and if
possible, with the consent of the original assignee.
Recognizing that some assignments involve judgment, such as those
involving a designated expert [RFC5226], a predictable process does
not require completion in a predetermined number of days. Rather, it
means that no unexpected steps are introduced in the process of
making an assignment.
3.2. Public
Once assigned, the protocol identifiers must be made available in a
manner that makes them freely available to everyone without
restrictions. The use of a consistent publication location builds
confidence in the registry. This does not mean that the publication
location can never change, but it does mean that it must change
infrequently and only after adequate prior notice.
3.3. Open and Transparent
The process that sets the policy for protocol identifier assignment
and registration must be open to all interested parties and operate
in a transparent manner.
When a registry is established, a policy is set for the addition of
new entries and the updating of existing entries. While making
additions and modifications, the registry operator may expose
instances where policies lack of clarity. When this occurs, the
registry operator should provide helpful feedback to allow those
policies to be improved. In addition, the registry operator not
being involved in establishing registry policy avoids the risks
associated with (perceptions of) favoritism and unfairness.
Recognizing that some assignments involve judgment, such as those
involving a designated expert [RFC5226], the recommendations by
Housley & Kolkman Expires 26 August 2015 [Page 4]
Internet-Draft IANA Registry Principles February 2015
designated experts must be visible to the public to the maximum
extent possible and subject to challenge or appeal.
3.4. Accountable
The process that sets the policy for IANA registries and the
operation of the registries must be accountable to the parties that
rely on the protocol identifiers. Oversight is needed to ensure
these are properly serving the affected community.
In practice accountability mechanisms for the registry operator may
be defined by contract, memoranda of understanding, or service level
agreements (SLAs). An oversight body uses these mechanisms to ensure
that the registry operator is meeting the needs of the affected
community, but the oversight body is held accountable to the affected
community by vastly different mechanisms, for instance recall and
appeal processes.
For protocol parameters [RFC6220], the general oversight over the
IANA function is performed by the IAB as a chartered responsibility
from [RFC2850]. In addition the IETF Administrative Oversight
Committee (IAOC), a body responsible for IETF administrative and
financial matters [BCP101], maintains an SLA with the current
registry operator, the Internet Corporation for Assigned names and
Numbers (ICANN), thereby specifying the operational requirements with
respect to the coordination, maintenance, and publication of the
protocol parameter registries. Both the IAB and the IAOC are
accountable to the larger Internet community and are being held
accountable through the IETF Nomcom process [BCP10].
For the Internet Number Registries [RFC7249], oversight is performed
by the Regional Internet Registries (RIRs) as described RFC 7020
[RFC7020]. The RIRs are member-based organizations, and they are
accountable to the affected community by elected governance boards.
Furthermore, per agreement between the RIRs and ICANN, the policy
development for the global IANA number registries is coordinated by a
community-elected number council and subject to process review before
ratification by the ICANN Board of Trustees [ASOMOU].
4. Security Considerations
Internet Registries are critical to elements of Internet security.
The principles described in this document are necessary for the
Internet community to place trust in the IANA registries.
Housley & Kolkman Expires 26 August 2015 [Page 5]
Internet-Draft IANA Registry Principles February 2015
5. IANA Considerations
{{{ RFC Editor: Please delete this section prior to publication. }}}
This document does not contain updates to any registries.
6. Informative References
[ASOMOU] Published by ICANN, "ICANN Address Supporting Organization
(ASO) MoU", October 2004,
<http://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
[BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
Dawkins, S., "Nominating Committee Process: Earlier
Announcement of Open Positions and Solicitation of
Volunteers", BCP 10, RFC 5633, August 2009.
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005.
Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for
IPR Trust", BCP 101, RFC 4371, January 2006.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and
Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013.
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
2014.
Housley & Kolkman Expires 26 August 2015 [Page 6]
Internet-Draft IANA Registry Principles February 2015
IAB Members at the Time of Approval
Jari Arkko (IETF Chair)
Mary Barnes
Marc Blanchet
Joel Halpern
Ted Hardie
Joe Hildebrand
Russ Housley
Eliot Lear
Xing Li
Erik Nordmark
Andrew Sullivan
Dave Thaler
Brian Trammell
Contributors and Acknowledgements
This text has been developed within the IAB IANA Evolution Program.
The ideas and many text fragments, and corrections came from or were
inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve
Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich,
John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson,
George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew
Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further
inspiration and input was drawn from various meetings with IETF and
other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership.
Please do not assume those acknowledged endorse the resulting text.
Authors' Addresses
Russ Housley
918 Spring Knoll Drive
Herndon, VA 20170
USA
Email: housley@vigilsec.com
Olaf Kolkman
Science Park 400
Amsterdam 1098 XH
The Netherlands
EMail: kolkman@isoc.org
Housley & Kolkman Expires 26 August 2015 [Page 7]
