doc: Add RFC documents

1 files changed, 345 insertions, 0 deletions

diff --git a/doc/rfc/rfc8720.txt b/doc/rfc/rfc8720.txt
new file mode 100644
index 0000000..bb30b76
--- /dev/null
+++ b/doc/rfc/rfc8720.txt
@@ -0,0 +1,345 @@
+
+
+
+
+Internet Architecture Board (IAB)                        R. Housley, Ed.
+Request for Comments: 8720                               O. Kolkman, Ed.
+Obsoletes: 7500                                            February 2020
+Category: Informational                                                 
+ISSN: 2070-1721
+
+
+ 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 candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8720.
+
+Copyright Notice
+
+   Copyright (c) 2020 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
+   (https://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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Principles for the Operation of IANA Registries
+   3.  Discussion
+     3.1.  Ensuring Uniqueness, Stability, and Predictability
+     3.2.  Public
+     3.3.  Open and Transparent
+     3.4.  Accountable
+   4.  Security Considerations
+   5.  Changes since RFC 7500
+   6.  Informative References
+   IAB Members at the Time of Approval
+   Acknowledgements
+   Authors' Addresses
+
+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
+   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, 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.
+
+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 [RFC8126], 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 must
+   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.
+
+   Recognizing that some assignments involve judgment, such as those
+   involving a designated expert [RFC8126], 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 a 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 Administration Limited Liability
+   Company (IETF LLC), as part of the IETF Administrative Support
+   Activity (IASA), is responsible for IETF administrative and financial
+   matters [RFC8711].  In that role, the IETF LLC 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 Board of the IETF LLC are accountable to the larger Internet
+   community and are being held accountable through the IETF NomCom
+   process [RFC8713].
+
+   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.
+
+5.  Changes since RFC 7500
+
+   Section 3.4 has been updated to align with the restructuring of the
+   IETF Administrative Support Activity (IASA).  Under the new
+   structure, the IETF LLC maintains an SLA with the protocol parameter
+   registry operator.  Under the old structure, the SLA was maintained
+   by the IETF Administrative Oversight Committee (IAOC).
+
+6.  Informative References
+
+   [ASOMOU]   ICANN, "Address Supporting Organization (ASO) MoU",
+              October 2004,
+              <https://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
+
+   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
+              "Charter of the Internet Architecture Board (IAB)",
+              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
+              <https://www.rfc-editor.org/info/rfc2850>.
+
+   [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, DOI 10.17487/RFC6220, April
+              2011, <https://www.rfc-editor.org/info/rfc6220>.
+
+   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
+              Internet Numbers Registry System", RFC 7020,
+              DOI 10.17487/RFC7020, August 2013,
+              <https://www.rfc-editor.org/info/rfc7020>.
+
+   [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249,
+              DOI 10.17487/RFC7249, May 2014,
+              <https://www.rfc-editor.org/info/rfc7249>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
+              the IETF Administrative Support Activity, Version 2.0",
+              BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
+              <https://www.rfc-editor.org/info/rfc8711>.
+
+   [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
+              Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and
+              Recall Process: Operation of the IETF Nominating and
+              Recall Committees", BCP 10, RFC 8713,
+              DOI 10.17487/RFC8713, February 2020,
+              <https://www.rfc-editor.org/info/rfc8713>.
+
+IAB Members at the Time of Approval
+
+      Jari Arkko
+      Alissa Cooper
+      Stephen Farrell
+      Wes Hardaker
+      Ted Hardie
+      Christian Huitema
+      Zhenbin Li
+      Erik Nordmark
+      Mark Nottingham
+      Melinda Shore
+      Jeff Tantsura
+      Martin Thomson
+      Brian Trammell
+
+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 by comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
+   Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Alissa
+   Cooper, Steve Crocker, John Curran, 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 the leadership of the Internet
+   community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB.
+
+   Please do not assume those acknowledged endorse the resulting text.
+
+Authors' Addresses
+
+   Russ Housley (editor)
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   United States of America
+
+   Email: housley@vigilsec.com
+
+
+   Olaf Kolkman (editor)
+   Internet Society
+   Science Park 400
+   1098 XH Amsterdam
+   Netherlands
+
+   Email: kolkman@isoc.org