summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8722.txt')
-rw-r--r--doc/rfc/rfc8722.txt549
1 files changed, 549 insertions, 0 deletions
diff --git a/doc/rfc/rfc8722.txt b/doc/rfc/rfc8722.txt
new file mode 100644
index 0000000..1ef87c0
--- /dev/null
+++ b/doc/rfc/rfc8722.txt
@@ -0,0 +1,549 @@
+
+
+
+
+Internet Architecture Board (IAB) D. McPherson, Ed.
+Request for Comments: 8722 Verisign, Inc.
+Obsoletes: 6220 O. Kolkman, Ed.
+Category: Informational ISOC
+ISSN: 2070-1721 J. Klensin, Ed.
+
+ G. Huston, Ed.
+ APNIC
+ February 2020
+
+
+ Defining the Role and Function of IETF Protocol Parameter Registry
+ Operators
+
+Abstract
+
+ Many Internet Engineering Task Force (IETF) protocols make use of
+ commonly defined values that are passed in messages or packets. To
+ ensure consistent interpretation of these values between independent
+ implementations, there is a need to ensure that the values and
+ associated semantic intent are uniquely defined. The IETF uses
+ registry functions to record assigned protocol parameter values and
+ their associated semantic intentions. For each IETF protocol
+ parameter, it is current practice for the IETF to delegate the role
+ of Protocol Parameter Registry Operator to a nominated entity. This
+ document provides a description of, and the requirements for, these
+ delegated functions. This document obsoletes RFC 6220 to replace all
+ references to the IETF Administrative Support Activity (IASA) and
+ related structures with those defined by the IASA 2.0 Model.
+
+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/rfc8722.
+
+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. Overview
+ 2. Roles and Responsibilities Concerning IETF Protocol Parameter
+ Registries
+ 2.1. Protocol Parameter Registry Operator Role
+ 2.2. IAB Role
+ 2.3. IESG Role
+ 2.4. Role of the IETF Trust
+ 2.5. Role of the IETF Administration Limited Liability Company
+ 3. Miscellaneous Considerations
+ 4. Security Considerations
+ 5. IANA Considerations
+ 6. Informative References
+ IAB Members at the Time of Approval
+ Acknowledgements
+ Authors' Addresses
+
+1. Overview
+
+ Many IETF protocols make use of commonly defined values that are
+ passed within messages or packets. To ensure consistent
+ interpretation of these values between independent implementations,
+ there is a need to ensure that the values and associated semantic
+ intent are uniquely defined. The IETF uses registries to record each
+ of the possible values of a protocol parameter and their associated
+ semantic intent. These registries, their registration policy, and
+ the layout of their content are defined in the so-called "IANA
+ Considerations" sections of IETF documents.
+
+ The organizational separation between the IETF and its Protocol
+ Parameter Registry Operators parallels ones that are fairly common
+ among standards development organizations (SDOs) although less common
+ among technology consortia and similar bodies. These functions have
+ been separated into different organizations for several reasons.
+ They include dealing with administrative issues, addressing concerns
+ about maintaining an adequate distance between basic policy and
+ specific allocations, and avoiding any potential conflicts of
+ interest that might arise from commercial or organizational
+ relationships. For example, most ISO and ISO/IEC JTC1 standards that
+ require registration activities specify a Registration Authority (RA)
+ or Maintenance Agency (MA) that, in turn, control the actual
+ registration decisions. The databases of what is registered for each
+ standard may then be maintained by a secretariat or database function
+ associated with the RA or MA or, less frequently, by the secretariat
+ of the body that created and maintains the standard itself.
+
+ This structural separation of roles exists within several places in
+ the IETF framework (e.g., the RFC Editor function). The Internet
+ Architecture Board (IAB), on behalf of the IETF, has the
+ responsibility to define and manage the relationship with the
+ Protocol Parameter Registry Operator role. This responsibility
+ includes the selection and management of the Protocol Parameter
+ Registry Operator, as well as management of the parameter
+ registration process and the guidelines for parameter allocation.
+
+ As with other SDOs, although it may delegate authority for some
+ specific decisions, the IETF asserts authority and responsibility for
+ the management of all of its protocol parameters and their
+ registries, even while it generally remains isolated from the
+ selection of particular values once a registration is approved. This
+ document describes the function of these registries as they apply to
+ individual protocol parameters defined by the IETF Internet Standards
+ Process (see RFC 6410 [BCP9]) to allow for an orderly implementation
+ by the IETF Administration Limited Liability Company (IETF LLC), and
+ others as needed, under guidance from the IAB. This document
+ obsoletes RFC 6220 to replace all references to the IASA and related
+ structures with those defined by the IASA 2.0 Model [RFC8711].
+
+ Below we provide a description of the requirements for these
+ delegated functions, which the IETF traditionally refers to as the
+ Internet Assigned Numbers Authority (IANA) function.
+
+2. Roles and Responsibilities Concerning IETF Protocol Parameter
+ Registries
+
+ The IETF's longstanding practice is to outsource the management and
+ implementation of some important functions (e.g., [RFC8728]). The
+ protocol parameter registry function falls into this category of
+ outsourced functions, and what follows here is the description of the
+ roles and responsibilities with respect to the registration of IETF
+ protocol parameters.
+
+ Specifically, this document describes the operation and role of a
+ delegated IETF Protocol Parameter Registry Operator, to be selected
+ and administered by the IETF Administrative Support Activity (IASA)
+ [RFC8711]. While there is generally a single Protocol Parameter
+ Registry Operator, additional Operators may be selected to implement
+ specific registries, and that has been done occasionally. Having a
+ single Protocol Parameter Registry Operator facilitates coordination
+ among registries, even those that are not obviously related, and also
+ makes it easier to have consistency of formats and registry
+ structure, which aids users of the registries and assists with
+ quality control.
+
+ Many protocols make use of identifiers consisting of constants and
+ other well-known values. Even after a protocol has been defined and
+ deployment has begun, new values may need to be assigned (e.g., for a
+ new option type in DHCP, or a new encryption or authentication
+ algorithm for IPsec). To ensure that such quantities have consistent
+ values and interpretations in different implementations, their
+ assignment must be administered by a central authority. For IETF
+ protocols, that role is provided by a delegated Protocol Parameter
+ Registry Operator. For any particular protocol parameter there is a
+ single delegated Registry Operator.
+
+2.1. Protocol Parameter Registry Operator Role
+
+ The IETF Protocol Parameter Registry function is undertaken under the
+ auspices of the Internet Architecture Board.
+
+ The roles of the Protocol Parameter Registry Operator (Registry
+ Operator) are as follows:
+
+ * Review and Advise
+
+ - A Registry Operator may be requested to review Internet-Drafts
+ that are being considered by the Internet Engineering Steering
+ Group (IESG), with the objective of offering advice to the IESG
+ regarding the contents of the "IANA Considerations" section,
+ whether such a section, when required, is clear in terms of
+ direction to the Registry Operator, and whether the section is
+ consistent with the current published Registry Operator
+ guidelines.
+
+ * Registry
+
+ - To operate a registry of protocol parameter assignments.
+
+ - The delegated Registry Operator registers values for Internet
+ protocol parameters only as directed by the criteria and
+ procedures specified in RFCs, including Standards Track
+ documents [BCP9], Best Current Practice documents, and other
+ RFCs that require protocol parameter assignment.
+
+ If values for Internet protocol parameters were not specified,
+ or in case of ambiguity, the Registry Operator will continue to
+ assign and register only those protocol parameters that have
+ already been delegated to the Registry Operator, following past
+ and current practice for such assignments, unless otherwise
+ directed in terms of operating practice by the IESG. In the
+ case of ambiguity, the Registry Operator is expected to
+ identify the ambiguity to the IAB or IESG as appropriate and
+ either suggest better text or ask the appropriate parties for
+ clarification.
+
+ - For each protocol parameter, the associated registry includes:
+
+ o a reference to the RFC document that describes the parameter
+ and the associated "IANA Considerations" concerning the
+ parameter, and
+
+ o for each registration of a protocol parameter value, the
+ source of the registration and the date of the registration,
+ if the date of registration is known, and
+
+ o any other information specified as being included in the
+ registration data in the RFC document that describes the
+ parameter.
+
+ o If in doubt or in case of a technical dispute, the Registry
+ Operator will seek and follow technical guidance exclusively
+ from the IESG. Where appropriate, the IESG will appoint an
+ expert to advise the Registry Operator.
+
+ - The Registry Operator will work with the IETF to develop any
+ missing criteria and procedures over time, which the Registry
+ Operator will adopt when so instructed by the IESG.
+
+ - Unless special circumstances apply to subsets of the data and
+ specific rules are established by IETF consensus, each protocol
+ parameter registry operates as a public registry, and the
+ contents of the registry are openly available to the public,
+ on-line and free of charge.
+
+ - The Registry Operator assigns protocol parameter values in
+ accordance with the policy associated with the protocol
+ parameter, such as "First Come First Served" or "Expert Review"
+ [RFC8126].
+
+ * Mailing Lists
+
+ - The Registry Operator maintains public mailing lists as
+ specified in IANA Considerations [RFC8126]. Such lists are
+ designated for the purpose of review of assignment proposals in
+ conjunction with a designated expert review function. In
+ addition, each Registry Operator should maintain a mailing list
+ that enables the registry staff of the Registry Operator to be
+ contacted by email.
+
+ * Liaison Activity
+
+ - The Registry Operator will nominate a liaison point of contact.
+ The Registry Operator, through this liaison, may be requested
+ to provide advice to the IESG on IETF protocol parameters as
+ well as the "IANA Considerations" section of each Internet-
+ Draft that is being reviewed for publication as an RFC. Where
+ appropriate the IESG will appoint an expert to advise the
+ Registry Operator.
+
+ * Reporting
+
+ - The Registry Operator will submit periodic reports to the IAB
+ concerning the operational performance of the registry
+ function. As an example of the requirements for such reports,
+ the reader is referred to a supplement [MoU_SUPP2019] to the
+ "Memorandum of Understanding Concerning the Technical Work of
+ the Internet Assigned Numbers Authority" [RFC2860] that
+ provides service level agreement (SLA) guidelines under which
+ ICANN, the current protocol parameter registry, must operate.
+
+ - At the request of the chair of the IETF or IAB, or the IETF
+ Executive Director [RFC8711], the Registry Operator will
+ undertake periodic reports to IETF Plenary meetings or
+ elsewhere as directed, concerning the status of the registry
+ function.
+
+ - The Registry Operator will publish an annual report describing
+ the status of the function and a summary of performance
+ indicators.
+
+ * Intellectual Property Rights and the Registry Operator
+
+ Unless special circumstances apply (see above):
+
+ - All assigned values are to be published and made available free
+ of any charges.
+
+ - The assignment values may be redistributed without
+ modification.
+
+ In any case,
+
+ - any intellectual property rights of the IETF protocol parameter
+ assignment information, including the IETF protocol parameter
+ registry and its contents, are to be held by the IETF Trust
+ [RFC8711] [RFC8714].
+
+2.2. IAB Role
+
+ An Operator of an IETF protocol parameter registry undertakes the
+ role as a delegated function under the authority of the IAB.
+
+ The IAB has the responsibility to review the current description of
+ the registry function from time to time and direct the Registry
+ Operator to adopt amendments relating to its role and mode of
+ operation according to the best interests of the IETF and the
+ Internet community in general.
+
+ The IAB has the responsibility to appoint an organization to
+ undertake the delegated functions of the Registry Operator for each
+ IETF protocol parameter. Specifically, the IAB defines the role and
+ requirements for the desired functions. The IETF LLC is responsible
+ for identifying a potential vendor, and once under agreement,
+ managing the various aspects of the relationships with that vendor.
+ To be clear, the IAB is in the deciding role (e.g., for appointment
+ and termination), but must work in close consultation with the IETF
+ LLC.
+
+ The IAB has the responsibility to determine the terms and conditions
+ of this delegated role. Such terms and conditions should ensure that
+ the registry operates in a manner that is fully conformant to the
+ functions described in this document. In addition, such terms and
+ conditions must not restrict the rights and interests of the IETF
+ with respect to the registry contents and maintenance.
+
+2.3. IESG Role
+
+ The IESG is responsible for the technical direction regarding entries
+ into IETF protocol parameter registries and maintaining the policies
+ by which such technical directions are given. Technical direction
+ itself is provided through the adoption of directives within the
+ "IANA Considerations" section of IETF Stream RFCs or through stand-
+ alone "IANA Considerations" RFCs.
+
+ The IESG shall verify that Internet-Drafts that are offered for
+ publication as IETF Stream RFCs [RFC8729] include "IANA
+ Considerations" sections when needed, and that "IANA Considerations"
+ sections conform to the current published guidelines.
+
+ Since technical assessment is not generally a responsibility of the
+ Registry Operator, as part of providing the technical direction the
+ IESG is responsible for identifying the technical experts that are
+ required to, where appropriate, review registration requests or
+ resolve open technical questions that relate to the registration of
+ parameters.
+
+ At its discretion, the IESG will organize the liaison activities with
+ the Registry Operator's liaison point of contact so as to facilitate
+ clear communications and effective operation of the registry
+ function.
+
+2.4. Role of the IETF Trust
+
+ The IETF Trust [RFC4371] was formed to act as the administrative
+ custodian of all copyrights and other intellectual property rights
+ relating to the IETF Standards Process, a function that had
+ previously been performed by the Internet Society (ISOC) and the
+ Corporation for National Research Initiatives (CNRI).
+
+ Any intellectual property rights of IETF protocol parameter
+ assignment information, including the registry and its contents, and
+ all registry publications, are to be held by the IETF Trust on behalf
+ of the IETF.
+
+ The IETF Trust may make such regulations as appropriate for the
+ redistribution of assignment values and registry publications.
+
+2.5. Role of the IETF Administration Limited Liability Company
+
+ The IETF Administration Limited Liability Company (IETF LLC)
+ [RFC8711] is responsible for identifying a potential vendor in a
+ manner of its choosing, based on IAB consultation, and for managing
+ the various aspects of the relationships with that vendor.
+
+ In addition, the IETF LLC has the responsibility to ensure long-term
+ access, stability, and uniqueness across all such registries. This
+ responsibility is of particular significance in the event that a
+ relation with a Protocol Parameter Registry Operator is terminated.
+
+3. Miscellaneous Considerations
+
+ While this document has focused on the creation of protocols by the
+ IETF, the requirements provided are generically applicable to the
+ extended IETF community as well (e.g., Internet Research Task Force
+ (IRTF)).
+
+ The IESG is responsible for the technical direction of the IETF
+ protocol parameter registries and maintaining the policies by which
+ such technical directions are given. The IESG is responsible, as
+ part of the document approval process associated with the IETF Stream
+ RFCs [RFC8729], for "IANA Considerations" verification. For the
+ other RFC streams, the approval bodies are responsible for verifying
+ that the documents include "IANA Considerations" sections when
+ needed, and that "IANA Considerations" sections conform to the
+ current published guidelines. In the case that IANA considerations
+ in non-IETF document streams lead to a dispute, the IAB makes the
+ final decision.
+
+ This document talks about "Registry Operator" (singular), and while
+ there are stability and economy-of-scale advantages for one single
+ Registry Operator, this document does not exclude having different
+ Registry Operators for different protocol registries when justified
+ by the circumstances.
+
+4. Security Considerations
+
+ This document does not propose any new protocols and does not
+ introduce any new security considerations.
+
+5. IANA Considerations
+
+ This document requires no direct IANA actions in terms of the
+ creation or operation of a protocol parameter registry. However,
+ this document does define the roles and responsibilities of various
+ bodies who are responsible for, and associated with, the operation of
+ protocol parameter registration functions for the IETF.
+
+6. Informative References
+
+ [BCP9] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ Dusseault, L. and R. Sparks, "Guidance on Interoperation
+ and Implementation Reports for Advancement to Draft
+ Standard", BCP 9, RFC 5657, September 2009.
+
+ Housley, R., Crocker, D., and E. Burger, "Reducing the
+ Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+ October 2011.
+
+ Resnick, P., "Retirement of the "Internet Official
+ Protocol Standards" Summary Document", BCP 9, RFC 7100,
+ December 2013.
+
+ Kolkman, O., Bradner, S., and S. Turner, "Characterization
+ of Proposed Standards", BCP 9, RFC 7127, January 2014.
+
+ Dawkins, S., "Increasing the Number of Area Directors in
+ an IETF Area", BCP 9, RFC 7475, March 2015.
+
+ <https://www.rfc-editor.org/info/bcp9>
+
+ [MoU_SUPP2019]
+ IETF Administration LLC, "2019 ICANN-IETF MoU Supplemental
+ Agreement", 31 July 2019,
+ <https://www.ietf.org/media/documents/FINAL_2019-IETF_MoU_
+ Supplemental_Agreement_Signed_31July19.pdf>.
+
+ [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+ Understanding Concerning the Technical Work of the
+ Internet Assigned Numbers Authority", RFC 2860,
+ DOI 10.17487/RFC2860, June 2000,
+ <https://www.rfc-editor.org/info/rfc2860>.
+
+ [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for
+ IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371,
+ January 2006, <https://www.rfc-editor.org/info/rfc4371>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <https://www.rfc-editor.org/info/rfc5226>.
+
+ [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>.
+
+ [RFC8714] Arkko, J. and T. Hardie, "Update to the Process for
+ Selection of Trustees for the IETF Trust", BCP 101,
+ RFC 8714, DOI 10.17487/RFC8714, February 2020,
+ <https://www.rfc-editor.org/info/rfc8714>.
+
+ [RFC8728] Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
+ "RFC Editor Model (Version 2)", RFC 8728,
+ DOI 10.17487/RFC8728, February 2020,
+ <https://www.rfc-editor.org/info/rfc8729>.
+
+ [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and
+ RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February
+ 2020, <https://www.rfc-editor.org/info/rfc8729>.
+
+IAB Members at the Time of Approval
+
+ Internet Architecture Board Members at the time this document was
+ approved for publication were:
+
+ 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 document was originally adapted from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC5226], and has been modified
+ to include explicit reference to Intellectual Property Rights and the
+ roles of the IAB and IESG in relation to the IETF Protocol Parameter
+ Registry function.
+
+ The document was updated under auspices of the IASA2 working group to
+ reflect the reorganization of IETF Administrative Support Activity.
+
+ The Internet Architecture Board acknowledges the assistance provided
+ by reviewers of drafts of this document, including Scott Bradner,
+ Brian Carpenter, Leslie Daigle, Adrian Farrel, Bob Hinden, Alfred
+ Hoenes, Paul Hoffman, Benjamin Kaduk, Alexey Melnikov, Thomas Narten,
+ and Ray Pelletier.
+
+Authors' Addresses
+
+ Danny McPherson (editor)
+ Verisign, Inc.
+
+ Email: dmcpherson@verisign.com
+
+
+ Olaf Kolkman (editor)
+ Internet Society
+
+ Email: kolkman@isoc.org
+
+
+ John C Klensin (editor)
+
+ Email: john-ietf@jck.com
+
+
+ Geoff Huston (editor)
+ APNIC
+
+ Email: gih@apnic.net