| Internet Architecture Board(IAB) | D. McPherson, Ed. |
| Internet-Draft | O. Kolkman, Ed. |
| Obsoletes: 6220 (if approved) | ISOC |
| Intended status: Informational | J. Klensin, Ed. |
| Expires: June 13, 2019 | |
| G. Huston, Ed. | |
| APNIC | |
| IAB | |
| December 10, 2018 |
Defining the Role and Function of IETF Protocol Parameter Registry Operators
draft-ietf-iasa2-rfc6220bis-03
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.
[The IASA2 WG asks the IAB to publish this replacement for RFC 6220. This document is changed for alignment with the new structure for the IETF Administrative Support Activity (IASA). ]
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2019.
Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 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 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 [RFC2026] to allow for an orderly implementation by the IETF Administration Limited Liability Company (IETF LLC), and others as needed, under guidance from the IAB.
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.
The IETF's longstanding practice is to outsource the management and implementation of some important functions (e.g., [I-D.ietf-iasa2-rfc6635bis]). 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) [I-D.ietf-iasa2-rfc4071bis]. 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 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.
The IETF Protocol Parameter Registry function is undertaken under the auspices of the Internet Architecture Board.
The roles of the Protocol Parameter Registry Operator are as follows:
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 Protocol Parameter 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.
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 [RFC4844] 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.
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.
The IETF Administration Limited Liability Company (IETF LLC) [I-D.ietf-iasa2-rfc4071bis][CREF3]olaf: Note this is the second time this is expanded 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.
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 [RFC4844], 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 Operator, this document does not exclude having different Operators for different protocol registries when justified by the circumstances.
This document does not propose any new protocols and does not introduce any new security 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.
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.
In 2018 the document was updated under auspicies of the IASA2.0 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, Alfred Hoenes, Paul Hoffman, Alexey Melnikov, Thomas Narten, and Ray Pelletier.
Internet Architecture Board Members at the time this document was approved for publication were [To Be Confirmed]:
[Text between square brackets starting with initials are editor notes. Any other text between square brackets assumes an action by the RFC editor prior to publication as an RFC. In most cases this will be removal, sometimes a stylistic or editorial choices ore question is indicated]
[This section and its subsections should be removed at publication as RFC, so should the Cover Note]
[RFC Editor: in the XML version of this document there are a few cref-comments with editorial questions]
$Id: rfc6220bis.xml,v 1.8 2018/12/10 19:42:34 olaf Exp $