doc: Add RFC documents

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]
+