Internet Architecture Board(IAB) D. McPherson, Ed.
Internet-Draft O. Kolkman, Ed.
Obsoletes: 6220 (if approved) ISOC
Intended status: Informational J. Klensin, Ed.
Expires: April 21, 2019
G. Huston, Ed.
APNIC
IAB
October 18, 2018
Defining the Role and Function of IETF Protocol Parameter Registry
Operators
draft-ietf-iasa2-rfc6220bis-02
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.
[Cover Note]
[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). ]
Status of This Memo
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
McPherson, et al. Expires April 21, 2019 [Page 1]
Internet-Draft Role of Registry Operators October 2018
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 April 21, 2019.
Copyright Notice
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.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Roles and Responsibilities Concerning IETF Protocol Parameter
Registries . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Parameter Registry Operator Role . . . . . . . . 4
2.2. IAB Role . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Role of the IETF Trust . . . . . . . . . . . . . . . . . 8
2.5. Role of the IETF Administration Limited Liability
Company . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Miscellaneous Considerations . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. IAB members . . . . . . . . . . . . . . . . . . . . 11
Appendix C. Document Editing Details . . . . . . . . . . . . . . 11
C.1. Version Information . . . . . . . . . . . . . . . . . . . 12
C.1.1. draft-iab-iasa2-rfc6220-00 . . . . . . . . . . . . . 12
C.1.2. draft-iab-iasa2-rfc6220-01 . . . . . . . . . . . . . 12
C.1.3. draft-iab-iasa2-rfc6220-02 . . . . . . . . . . . . . 12
C.2. RCS information . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
McPherson, et al. Expires April 21, 2019 [Page 2]
Internet-Draft Role of Registry Operators October 2018
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 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.
McPherson, et al. Expires April 21, 2019 [Page 3]
Internet-Draft Role of Registry Operators October 2018
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.,
[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-struct]. 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.
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 are as follows:
o 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
McPherson, et al. Expires April 21, 2019 [Page 4]
Internet-Draft Role of Registry Operators October 2018
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.
o 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 Proposed, Draft, and
full Internet Standards, 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 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.
McPherson, et al. Expires April 21, 2019 [Page 5]
Internet-Draft Role of Registry Operators October 2018
* 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].
o 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 Protocol Parameter Registry Operator should
maintain a mailing list that enables the registry staff of the
Registry Operator to be contacted by email.
o 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.
o 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_SUPP2018] 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 [I-D.ietf-iasa2-struct], the Registry
McPherson, et al. Expires April 21, 2019 [Page 6]
Internet-Draft Role of Registry Operators October 2018
Operator will undertake periodic reports to IETF Plenary
meetings, or elsewhere as they may direct, 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.
o Intellectual Property Rights and the Registry Operator
* All assigned values are to be published and made available free
of any charges.
* The assignment values may be redistributed without
modification.
* 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
(BCP 101, currently [RFC4071] [RFC4371]).
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 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.
McPherson, et al. Expires April 21, 2019 [Page 7]
Internet-Draft Role of Registry Operators October 2018
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 [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.
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)
[I-D.ietf-iasa2-struct] is responsible for identifying a potential
vendor in a manner of its choosing, based on IAB consultation, and
McPherson, et al. Expires April 21, 2019 [Page 8]
Internet-Draft Role of Registry Operators October 2018
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 [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.
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.
McPherson, et al. Expires April 21, 2019 [Page 9]
Internet-Draft Role of Registry Operators October 2018
6. Informative References
[I-D.ietf-iasa2-rfc6635bis]
Kolkman, O., Halpern, J., and R. Hinden, "RFC Editor Model
(Version 2)", draft-ietf-iasa2-rfc6635bis-01 (work in
progress), August 2018.
[I-D.ietf-iasa2-struct]
Haberman, B., Hall, J., and J. Livingood, "Record of
Proposed Structure of the IETF Administrative Support
Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06
(work in progress), September 2018.
[MoU_SUPP2018]
"ICANN/IANA-IETF MoU Supplemental Agreement, 2018".
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[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>.
[RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the
IETF Administrative Support Activity (IASA)", BCP 101,
RFC 4071, DOI 10.17487/RFC4071, April 2005,
<https://www.rfc-editor.org/info/rfc4071>.
[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>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[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>.
McPherson, et al. Expires April 21, 2019 [Page 10]
Internet-Draft Role of Registry Operators October 2018
Appendix A. 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.
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.
Appendix B. IAB members
Internet Architecture Board Members at the time this document was
approved for publication were [To Be Confirmed]:
Jari Arkko,
Alissa Cooper,
Ted Hardie,
Christian Huitema,
Gabriel Montenegro,
Erik Nordmark,
Mark Nottingham,
Melinda Shore,
Robert Sparks,
Jeff Tantsura,
Martin Thomson,
Brian Trammell, and
Suzanne Woolf.
Appendix C. Document Editing Details
[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]
McPherson, et al. Expires April 21, 2019 [Page 11]
Internet-Draft Role of Registry Operators October 2018
[RFC Editor: in the XML version of this document there are a few
cref-comments with editorial questions]
C.1. Version Information
C.1.1. draft-iab-iasa2-rfc6220-00
Original RFC text back ported into XML. With only Editor
affiliation changed and IAB members section emptied
C.1.2. draft-iab-iasa2-rfc6220-01
o Changed references to IAOC to LLC
o While reviewing the section on the Trust: Modified reference to
RFC 4748 to reference to RFC4371, as that document establishes the
Trust while 4748 is technically an update of RFC 3978 (now
obsoleted).
o Updated reference to ICANN-IETF MoU to most recent version (2018)
[MoU_SUPP2018] .
C.1.3. draft-iab-iasa2-rfc6220-02
o Standardized on "IETF LLC" as the sort version for the entity (per
RFC style guide).
o Changed "At the request of the chair of the IETF, IAB, or LLC," to
"At the request of the chair of the IETF or IAB, or the IETF
Executive Director", in the same paragraph: The reporting of the
registry operator does not necessarily need to take place in IETF
Plenary, it may happen elsewhere. Text changed to reflect as
much.
o BCP101 is a better reference than exclusively referring to
RFC4371. The way the reference is provided needs RFC Editor
attention.
o IDnits complained about rfc5226 being obsoleted. One of the
rfc5226 references is used for historical context in the
acknowledgement section, in other places it was replaced by 8126.
o IDnits complained about rfc5620 being obsoleted. The reference to
5620 is replaced by rfc6635bis-rfc editor model (not including
rfc6548bis-independent rfc editor, as it just serves as an example
and does not intend to describe the full RFC Editor universe).
o Updated the Acknowledgement section
C.2. RCS information
$Id: rfc6220bis.xml,v 1.7 2018/10/18 11:08:56 olaf Exp $
McPherson, et al. Expires April 21, 2019 [Page 12]
Internet-Draft Role of Registry Operators October 2018
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
Internet Architecture Board
EMail: iab@iab.org
McPherson, et al. Expires April 21, 2019 [Page 13]