draft-iab-rfc7500-bis-00.txt   rfc8720.txt 
INTERNET-DRAFT R. Housley, Ed. Internet Architecture Board (IAB) R. Housley, Ed.
Internet Architecture Board (IAB) Vigil Security Request for Comments: 8720 O. Kolkman, Ed.
Obsoletes: 7500 (once approved) O. Kolkman, Ed. Obsoletes: 7500 February 2020
Intended Status: Informational Internet Society Category: Informational
Expires: 26 December 2019 26 June 2019 ISSN: 2070-1721
Principles for Operation of Principles for Operation of Internet Assigned Numbers Authority (IANA)
Internet Assigned Numbers Authority (IANA) Registries Registries
draft-iab-rfc7500-bis-00
Abstract Abstract
This document provides principles for the operation of Internet This document provides principles for the operation of Internet
Assigned Numbers Authority (IANA) registries. Assigned Numbers Authority (IANA) registries.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Architecture Board (IAB)
http://www.ietf.org/1id-abstracts.html 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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8720.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
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 Table of Contents
0. Cover Note ..................................................... 2 1. Introduction
1. Introduction ................................................... 2 2. Principles for the Operation of IANA Registries
2. Principles for the Operation of IANA Registries ................ 4 3. Discussion
3. Discussion ..................................................... 4 3.1. Ensuring Uniqueness, Stability, and Predictability
3.1. Ensuring Uniqueness, Stability, and Predictability ........ 4 3.2. Public
3.2. Public .................................................... 5 3.3. Open and Transparent
3.3. Open and Transparent ...................................... 5 3.4. Accountable
3.4. Accountable ............................................... 5 4. Security Considerations
4. Security Considerations ........................................ 6 5. Changes since RFC 7500
5. Changes Since RFC 7500 ........................................ 6 6. Informative References
6. Informative References ......................................... 6 IAB Members at the Time of Approval
IAB Members at the Time of Approval ............................... 8 Acknowledgements
Contributors and Acknowledgements ................................. 8 Authors' Addresses
Authors' Addresses ................................................ 8
0. Cover Note
{{ RFC Editor: Please remove this section prior to publication. }}
Section 3.4 is changed for alignment with the new structure for the
IETF Administrative Support Activity (IASA).
1. Introduction 1. Introduction
The Internet Engineering Task Force (IETF) and its predecessors have The Internet Engineering Task Force (IETF) and its predecessors have
traditionally separated the publication of protocol specifications in traditionally separated the publication of protocol specifications in
immutable Request for Comments (RFCs) and the registries containing immutable Request for Comments (RFCs) and the registries containing
protocol parameters. Traditionally, the registries are maintained by protocol parameters. Traditionally, the registries are maintained by
a set of functions known collectively as the Internet Assigned a set of functions known collectively as the Internet Assigned
Numbers Authority (IANA). Dating back to the earliest days of the Numbers Authority (IANA). Dating back to the earliest days of the
Internet, specification publication and the registry operations were Internet, specification publication and the registry operations were
tightly coupled: Jon Postel of the Information Sciences Institute tightly coupled: Jon Postel of the Information Sciences Institute
(ISI) of the University of Southern California (USC) was responsible (ISI) of the University of Southern California (USC) was responsible
for both RFC publication and IANA registry operation. This tight for both RFC publication and IANA registry operation. This tight
coupling had advantages, but it was never a requirement. Indeed, coupling had advantages, but it was never a requirement. Indeed,
today the RFC Editor and IANA registry operation are provided by today, the RFC Editor and IANA registry operation are provided by
different entities. different entities.
Internet registries are critical to the operation of the Internet, Internet registries are critical to the operation of the Internet
because they provide a definitive record of the value and meaning of because they provide a definitive record of the value and meaning of
identifiers that protocols use when communicating with each other. identifiers that protocols use when communicating with each other.
Almost every Internet protocol makes use of registries in some form. Almost every Internet protocol makes use of registries in some form.
At the time of writing, the IANA maintains more than two thousand At the time of writing, the IANA maintains more than two thousand
protocol parameter registries. protocol parameter registries.
Internet registries hold protocol identifiers consisting of constants Internet registries hold protocol identifiers consisting of constants
and other well-known values used by Internet protocols. These values and other well-known values used by Internet protocols. These values
can be numbers, strings, addresses, and so on. They are uniquely can be numbers, strings, addresses, and so on. They are uniquely
assigned for one particular purpose or use. Identifiers can be assigned for one particular purpose or use. Identifiers can be
maintained in a central list (such as a list of cryptographic maintained in a central list (such as a list of cryptographic
algorithms) or they can be hierarchically allocated and assigned by algorithms), or they can be hierarchically allocated and assigned by
separate entities at different points in the hierarchy (such as IP separate entities at different points in the hierarchy (such as IP
addresses and domain names). To maximize trust and usefulness of the addresses and domain names). To maximize trust and usefulness of the
IANA registries, the principles in this document should be taken into IANA registries, the principles in this document should be taken into
consideration for centralized registries as well as hierarchically consideration for centralized registries as well as hierarchically
delegated registries. In hierarchically delegated registries, delegated registries. In hierarchically delegated registries,
entries nearest to top level have broad scope, but lower-level entries nearest to top level have broad scope, but lower-level
entries have narrow scope. The Internet Architecture Board (IAB) entries have narrow scope. The Internet Architecture Board (IAB)
will encourage support for these principles in all delegations of will encourage support for these principles in all delegations of
Internet identifiers. Internet identifiers.
The registry system is built on trust and mutual cooperation. The The registry system is built on trust and mutual cooperation. The
use of the registries is voluntary and is not enforced by mandates or use of the registries is voluntary and is not enforced by mandates or
certification policies. While the use of registries is voluntary, it certification policies. While the use of registries is voluntary, it
is noted that the success of the Internet creates enormous pressure is noted that the success of the Internet creates enormous pressure
to use Internet protocols and the identifier registries associated to use Internet protocols and the identifier registries associated
with them. with them.
This document provides principles for the operation of IANA This document provides principles for the operation of IANA
registries, ensuring that protocol identifiers have consistent registries, ensuring that protocol identifiers have consistent
meanings and interpretations across all implementations and meanings and interpretations across all implementations and
deployments, and thus providing the necessary trust in the IANA deployments, thus providing the necessary trust in the IANA
registries. registries.
2. Principles for the Operation of IANA Registries 2. Principles for the Operation of IANA Registries
The following key principles underscore the successful functioning of The following key principles underscore the successful functioning of
the IANA registries, and they provide a foundation for trust in those the IANA registries, and they provide a foundation for trust in those
registries: registries:
Ensure Uniqueness: The same protocol identifier must not be used for Ensure Uniqueness:
more than one purpose. The same protocol identifier must not be used for more than one
purpose.
Stable: Protocol identifier assignment must be lasting. Stable:
Protocol identifier assignment must be lasting.
Predictable: The process for making assignments must not include Predictable:
unexpected steps. The process for making assignments must not include unexpected
steps.
Public: The protocol identifiers must be made available in well- Public:
known locations in a manner that makes them freely available to The protocol identifiers must be made available in well-known
locations in a manner that makes them freely available to
everyone. everyone.
Open: The process that sets the policy for protocol identifier Open:
The process that sets the policy for protocol identifier
assignment and registration must be open to all interested assignment and registration must be open to all interested
parties. parties.
Transparent: The protocol registries and their associated policies Transparent:
should be developed in a transparent manner. The protocol registries and their associated policies should be
developed in a transparent manner.
Accountable: Registry policy development and registry operations Accountable:
need to be accountable to the affected community. Registry policy development and registry operations need to be
accountable to the affected community.
3. Discussion 3. Discussion
The principles discussed in Section 2 provide trust and confidence in The principles discussed in Section 2 provide trust and confidence in
the IANA registries. This section expands on these principles. the IANA registries. This section expands on these principles.
3.1. Ensuring Uniqueness, Stability, and Predictability 3.1. Ensuring Uniqueness, Stability, and Predictability
Protocol identifier assignment and registration must be unique, Protocol identifier assignment and registration must be unique,
stable, and predictable. Developers, vendors, customers, and users stable, and predictable. Developers, vendors, customers, and users
depend on the registries for unique protocol identifiers that are depend on the registries for unique protocol identifiers that are
assigned in a stable and predictable manner. assigned in a stable and predictable manner.
A protocol identifier may only be reassigned for a different purpose A protocol identifier may only be reassigned for a different purpose
after due consideration of the impact of such a reassignment, and if after due consideration of the impact of such a reassignment and, if
possible, with the consent of the original assignee. possible, with the consent of the original assignee.
Recognizing that some assignments involve judgment, such as those Recognizing that some assignments involve judgment, such as those
involving a designated expert [RFC5226], a predictable process does involving a designated expert [RFC8126], a predictable process does
not require completion in a predetermined number of days. Rather, it not require completion in a predetermined number of days. Rather, it
means that no unexpected steps are introduced in the process of means that no unexpected steps are introduced in the process of
making an assignment. making an assignment.
3.2. Public 3.2. Public
Once assigned, the protocol identifiers must be made available in a Once assigned, the protocol identifiers must be made available in a
manner that makes them freely available to everyone without manner that makes them freely available to everyone without
restrictions. The use of a consistent publication location builds restrictions. The use of a consistent publication location builds
confidence in the registry. This does not mean that the publication confidence in the registry. This does not mean that the publication
location can never change, but it does mean that it must change location can never change, but it does mean that it must change
infrequently and only after adequate prior notice. infrequently and only after adequate prior notice.
3.3. Open and Transparent 3.3. Open and Transparent
The process that sets the policy for protocol identifier assignment The process that sets the policy for protocol identifier assignment
and registration must be open to all interested parties and operate and registration must be open to all interested parties and must
in a transparent manner. operate in a transparent manner.
When a registry is established, a policy is set for the addition of When a registry is established, a policy is set for the addition of
new entries and the updating of existing entries. While making new entries and the updating of existing entries. While making
additions and modifications, the registry operator may expose additions and modifications, the registry operator may expose
instances where policies lack clarity. When this occurs, the instances where policies lack clarity. When this occurs, the
registry operator should provide helpful feedback to allow those registry operator should provide helpful feedback to allow those
policies to be improved. In addition, the registry operator not policies to be improved. In addition, the registry operator not
being involved in establishing registry policy avoids the risks being involved in establishing registry policy avoids the risks
associated with (perceptions of) favoritism and unfairness. associated with (perceptions of) favoritism and unfairness.
Recognizing that some assignments involve judgment, such as those Recognizing that some assignments involve judgment, such as those
involving a designated expert [RFC5226], the recommendations by involving a designated expert [RFC8126], the recommendations by
designated experts must be visible to the public to the maximum designated experts must be visible to the public to the maximum
extent possible and subject to challenge or appeal. extent possible and subject to challenge or appeal.
3.4. Accountable 3.4. Accountable
The process that sets the policy for IANA registries and the The process that sets the policy for IANA registries and the
operation of the registries must be accountable to the parties that operation of the registries must be accountable to the parties that
rely on the protocol identifiers. Oversight is needed to ensure rely on the protocol identifiers. Oversight is needed to ensure
these are properly serving the affected community. these are properly serving the affected community.
In practice, accountability mechanisms for the registry operator may In practice, accountability mechanisms for the registry operator may
be defined by contract, memoranda of understanding, or service level be defined by a contract, memoranda of understanding, or service
agreements (SLAs). An oversight body uses these mechanisms to ensure level agreements (SLAs). An oversight body uses these mechanisms to
that the registry operator is meeting the needs of the affected ensure that the registry operator is meeting the needs of the
community. The oversight body is held accountable to the affected affected community. The oversight body is held accountable to the
community by vastly different mechanisms, for instance recall and affected community by vastly different mechanisms -- for instance,
appeal processes. recall and appeal processes.
For protocol parameters [RFC6220], the general oversight of the IANA For protocol parameters [RFC6220], the general oversight of the IANA
function is performed by the IAB as a chartered responsibility from function is performed by the IAB as a chartered responsibility from
[RFC2850]. In addition, the IETF Administration Limited Liability [RFC2850]. In addition, the IETF Administration Limited Liability
Company (IETF LLC), as part of the IETF Administrative Support Company (IETF LLC), as part of the IETF Administrative Support
Activity (IASA), is responsible for IETF administrative and financial Activity (IASA), is responsible for IETF administrative and financial
matters [I-D.ietf-iasa2-rfc4071bis], and in that role, the IETF LLC matters [RFC8711]. In that role, the IETF LLC maintains an SLA with
maintains a SLA with the current registry operator, the Internet the current registry operator, the Internet Corporation for Assigned
Corporation for Assigned names and Numbers (ICANN), thereby Names and Numbers (ICANN), thereby specifying the operational
specifying the operational requirements with respect to the requirements with respect to the coordination, maintenance, and
coordination, maintenance, and publication of the protocol parameter publication of the protocol parameter registries. Both the IAB and
registries. Both the IAB and the Board of the IETF LLC are the Board of the IETF LLC are accountable to the larger Internet
accountable to the larger Internet community and are being held community and are being held accountable through the IETF NomCom
accountable through the IETF NomCom process [BCP10]. process [RFC8713].
For the Internet Number Registries [RFC7249], oversight is performed For the Internet Number Registries [RFC7249], oversight is performed
by the Regional Internet Registries (RIRs) as described RFC 7020 by the Regional Internet Registries (RIRs) as described RFC 7020
[RFC7020]. The RIRs are member-based organizations, and they are [RFC7020]. The RIRs are member-based organizations, and they are
accountable to the affected community by elected governance boards. accountable to the affected community by elected governance boards.
Furthermore, per agreement between the RIRs and ICANN, the policy Furthermore, per agreement between the RIRs and ICANN, the policy
development for the global IANA number registries is coordinated by a development for the global IANA number registries is coordinated by a
community-elected number council and subject to process review before community-elected number council and subject to process review before
ratification by the ICANN Board of Trustees [ASOMOU]. ratification by the ICANN Board of Trustees [ASOMOU].
4. Security Considerations 4. Security Considerations
Internet Registries are critical to elements of Internet security. Internet registries are critical to elements of Internet security.
The principles described in this document are necessary for the The principles described in this document are necessary for the
Internet community to place trust in the IANA registries. Internet community to place trust in the IANA registries.
5. Changes Since RFC 7500 5. Changes since RFC 7500
Section 3.4 has been updated to align with the restructuring of the Section 3.4 has been updated to align with the restructuring of the
IETF Administrative Support Activity (IASA). Under the new IETF Administrative Support Activity (IASA). Under the new
structure, the IETF LLC maintains a SLA with the protocol parameter structure, the IETF LLC maintains an SLA with the protocol parameter
registry operator. Under the old structure, the SLA was maintained registry operator. Under the old structure, the SLA was maintained
by the IETF Administrative Oversight Committee (IAOC). by the IETF Administrative Oversight Committee (IAOC).
6. Informative References 6. Informative References
[ASOMOU] ICANN, "ICANN Address Supporting Organization (ASO) MoU", [ASOMOU] ICANN, "Address Supporting Organization (ASO) MoU",
October 2004, October 2004,
<http://archive.icann.org/en/aso/aso-mou-29oct04.htm>. <https://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>.
[I-D.ietf-iasa2-rfc4071bis]
Haberman, B., Hall, J., and J. Livingood, "Structure of
the IETF Administrative Support Activity, Version 2.0",
draft-ietf-iasa2-rfc4071bis-00 (work in progress),
December 2018.
[RFC2850] Internet Architecture Board and B. Carpenter, Ed., [RFC2850] Internet Architecture Board and B. Carpenter, Ed.,
"Charter of the Internet Architecture Board (IAB)", BCP "Charter of the Internet Architecture Board (IAB)",
39, RFC 2850, May 2000, BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
<http://www.rfc-editor.org/info/rfc2850>. <https://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., [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
Huston, G., Ed., and Internet Architecture Board, Huston, G., Ed., and Internet Architecture Board,
"Defining the Role and Function of IETF Protocol Parameter "Defining the Role and Function of IETF Protocol Parameter
Registry Operators", RFC 6220, April 2011, Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April
<http://www.rfc-editor.org/info/rfc6220>. 2011, <https://www.rfc-editor.org/info/rfc6220>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013, Internet Numbers Registry System", RFC 7020,
<http://www.rfc-editor.org/info/rfc7020>. DOI 10.17487/RFC7020, August 2013,
<https://www.rfc-editor.org/info/rfc7020>.
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249,
2014, <http://www.rfc-editor.org/info/rfc7249>. DOI 10.17487/RFC7249, May 2014,
<https://www.rfc-editor.org/info/rfc7249>.
[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>.
[RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and
Recall Process: Operation of the IETF Nominating and
Recall Committees", BCP 10, RFC 8713,
DOI 10.17487/RFC8713, February 2020,
<https://www.rfc-editor.org/info/rfc8713>.
IAB Members at the Time of Approval IAB Members at the Time of Approval
{{ RFC Editor: Fill in the current membership. }} 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
Contributors and Acknowledgements Acknowledgements
This text has been developed within the IAB IANA Evolution Program. This text has been developed within the IAB IANA Evolution Program.
The ideas and many text fragments, and corrections came from or were The ideas and many text fragments and corrections came from or were
inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, inspired by comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Alissa
Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, Cooper, Steve Crocker, John Curran, Leslie Daigle, Elise Gerich, John
John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, George
George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew Michaelson, Thomas Narten, Andrei Robachevsky, Andrew Sullivan, Dave
Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further Thaler, Brian Trammell, and Greg Wood. Further inspiration and input
inspiration and input was drawn from various meetings with IETF and was drawn from various meetings with the leadership of the Internet
other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership. community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB.
Please do not assume those acknowledged endorse the resulting text. Please do not assume those acknowledged endorse the resulting text.
Authors' Addresses Authors' Addresses
Russ Housley Russ Housley (editor)
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA United States of America
EMail: housley@vigilsec.com
Olaf Kolkman Email: housley@vigilsec.com
Olaf Kolkman (editor)
Internet Society Internet Society
Science Park 400 Science Park 400
Amsterdam 1098 XH 1098 XH Amsterdam
The Netherlands Netherlands
EMail: kolkman@isoc.org
Email: kolkman@isoc.org
 End of changes. 43 change blocks. 
136 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/