Defining the Role and Function of IETF Protocol Parameter Registry OperatorsVerisign, Inc.dmcpherson@verisign.comInternet Societykolkman@isoc.orgjohn-ietf@jck.comAPNICgih@apnic.net
General
Internet Architecture Board (IAB)IANAGovernanceIASA
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
.
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
() 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
. Overview
. Roles and Responsibilities Concerning IETF Protocol Parameter Registries
. Protocol Parameter Registry Operator Role
. IAB Role
. IESG Role
. Role of the IETF Trust
. Role of the IETF Administration Limited Liability Company
. Miscellaneous Considerations
. Security Considerations
. IANA Considerations
. Informative References
IAB Members at the Time of Approval
Acknowledgements
Authors' Addresses
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 ) 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 .
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.
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., ). 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) . 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.
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 , 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:
a reference to the RFC document that describes the parameter
and the associated "IANA Considerations" concerning the
parameter, and
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
any other information specified as being included in the
registration data in the RFC document that describes the
parameter.
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"
.
Mailing Lists
The Registry Operator maintains public mailing lists as
specified in IANA Considerations . 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
to the "Memorandum of Understanding
Concerning the Technical Work of the Internet Assigned
Numbers Authority" 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 , 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 .
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.
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 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.
Role of the IETF Trust
The IETF Trust 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.
Role of the IETF Administration Limited Liability Company
The IETF Administration Limited Liability Company (IETF LLC)
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.
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 , 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.
Security Considerations
This document does not propose any new protocols and does not
introduce any new security considerations.
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.
Informative ReferencesThe Internet Standards Process -- Revision 3This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidance on Interoperation and Implementation Reports for Advancement to Draft StandardAdvancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Reducing the Standards Track to Two Maturity LevelsThis document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.Retirement of the "Internet Official Protocol Standards" Summary DocumentThis document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.Characterization of Proposed StandardsRFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.Increasing the Number of Area Directors in an IETF AreaThis document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).2019 ICANN-IETF MoU Supplemental AgreementIETF Administration LLCMemorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers AuthorityThis document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.BCP 101 Update for IPR TrustThis document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsMany 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 transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Structure of the IETF Administrative Support Activity, Version 2.0Update to the Process for Selection of Trustees for the IETF TrustRFC Editor Model (Version 2)The RFC Series and RFC EditorIAB Members at the Time of Approval
Internet Architecture Board Members at the time this document
was approved for publication were:
Acknowledgements
This document was originally adapted from "Guidelines for Writing an IANA
Considerations Section in RFCs" , 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
, ,
, ,
,
, ,
, , ,
and .
Authors' AddressesVerisign, Inc.dmcpherson@verisign.comInternet Societykolkman@isoc.orgjohn-ietf@jck.comAPNICgih@apnic.net