Movatterモバイル変換

Internet Architecture Board (IAB)                        R. Housley, Ed.Request for Comments: 7500                                Vigil SecurityCategory: Informational                                  O. Kolkman, Ed.ISSN: 2070-1721                                         Internet Society                                                              April 2015Principles for Operation ofInternet Assigned Numbers Authority (IANA) RegistriesAbstract   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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 2015Table of Contents1. Introduction ....................................................22. Principles for the Operation of IANA Registries .................33. Discussion ......................................................43.1. Ensuring Uniqueness, Stability, and Predictability .........43.2. Public .....................................................43.3. Open and Transparent .......................................43.4. Accountable ................................................54. Security Considerations .........................................55. Informative References ..........................................6   IAB Members at the Time of Approval ................................7   Contributors and Acknowledgements ..................................7   Authors' Addresses .................................................71.  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 hierarchicallyHousley & 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 20153.  Discussion   The principles discussed inSection 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 describedRFC 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 20155.  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,RFC4071, 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)",BCP39,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 2015IAB 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 TrammellContributors 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.orgHousley & Kolkman             Informational                     [Page 7]