summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7500.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7500.txt')
-rw-r--r--doc/rfc/rfc7500.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7500.txt b/doc/rfc/rfc7500.txt
new file mode 100644
index 0000000..59f31d0
--- /dev/null
+++ b/doc/rfc/rfc7500.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) R. Housley, Ed.
+Request for Comments: 7500 Vigil Security
+Category: Informational O. Kolkman, Ed.
+ISSN: 2070-1721 Internet Society
+ April 2015
+
+
+ Principles for Operation of
+ Internet Assigned Numbers Authority (IANA) Registries
+
+Abstract
+
+ This document provides principles for the operation of Internet
+ Assigned Numbers Authority (IANA) registries.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7500.
+
+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
+ (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.
+
+
+
+
+
+
+
+
+
+Housley & Kolkman Informational [Page 1]
+
+RFC 7500 TITLE* April 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Principles for the Operation of IANA Registries .................3
+ 3. Discussion ......................................................4
+ 3.1. Ensuring Uniqueness, Stability, and Predictability .........4
+ 3.2. Public .....................................................4
+ 3.3. Open and Transparent .......................................4
+ 3.4. Accountable ................................................5
+ 4. Security Considerations .........................................5
+ 5. Informative References ..........................................6
+ IAB Members at the Time of Approval ................................7
+ Contributors and Acknowledgements ..................................7
+ Authors' Addresses .................................................7
+
+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. Traditionally, the registries are maintained by
+ a set of functions 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,
+ because 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
+ addresses and domain names). To maximize trust and usefulness of the
+ IANA registries, the principles in this document should be taken into
+ consideration for centralized registries as well as hierarchically
+
+
+
+Housley & Kolkman Informational [Page 2]
+
+RFC 7500 TITLE* April 2015
+
+
+ delegated registries. In hierarchically delegated registries,
+ entries nearest to top level have broad scope, but lower-level
+ entries have narrow scope. The Internet Architecture Board (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 well-
+ known locations in a manner that makes them freely available to
+ everyone.
+
+ 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 Informational [Page 3]
+
+RFC 7500 TITLE* April 2015
+
+
+3. Discussion
+
+ The principles discussed in Section 2 provide trust and confidence in
+ the IANA registries. This section expands on these principles.
+
+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 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.
+
+
+
+
+
+
+Housley & Kolkman Informational [Page 4]
+
+RFC 7500 TITLE* April 2015
+
+
+ Recognizing that some assignments involve judgment, such as those
+ involving a designated expert [RFC5226], the recommendations by
+ 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. 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 of 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 Informational [Page 5]
+
+RFC 7500 TITLE* April 2015
+
+
+5. Informative References
+
+ [ASOMOU] ICANN, "ICANN Address Supporting Organization (ASO) MoU",
+ October 2004,
+ <http://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
+
+ [BCP10] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
+ Confirmation, and Recall Process: Operation of the
+ Nominating and Recall Committees", BCP 10, RFC 7437,
+ January 2015, <http://www.rfc-editor.org/info/bcp10>.
+
+ [BCP101] Austein, R., Ed., and B. Wijnen, Ed., "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.
+
+ <http://www.rfc-editor.org/info/bcp101>
+
+ [RFC2850] Internet Architecture Board and B. Carpenter, Ed.,
+ "Charter of the Internet Architecture Board (IAB)", BCP
+ 39, RFC 2850, May 2000,
+ <http://www.rfc-editor.org/info/rfc2850>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc2860>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+ [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", RFC 6220, April 2011,
+ <http://www.rfc-editor.org/info/rfc6220>.
+
+ [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
+ Internet Numbers Registry System", RFC 7020, August 2013,
+ <http://www.rfc-editor.org/info/rfc7020>.
+
+ [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
+ 2014, <http://www.rfc-editor.org/info/rfc7249>.
+
+
+
+
+
+Housley & Kolkman Informational [Page 6]
+
+RFC 7500 TITLE* April 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 Informational [Page 7]
+