How Requests for IANA Action Will Be Handled on the Independent StreamIndependent Submissions Editorrfc-ise@rfc-editor.orgIANAIndependent Submission StreamISEThe Internet Assigned Numbers Authority (IANA) maintains registries
to track code points used
by protocols such as those defined by the IETF and documented in RFCs developed on the IETF
Stream.The Independent Submission Stream is another source of documents that can be published as
RFCs. This stream is under the care of the Independent Submissions Editor (ISE).This document complements RFC 4846 by providing a description of how the ISE currently
handles documents in the Independent Submission Stream that request actions from IANA.
Nothing in this document changes existing IANA registries or their allocation policies, nor
does it change any previously documented processes.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor 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
. Introduction
. Allocations from Existing Registries
. Changing Policies of Existing Registries
. Creating New IANA Registries
. Assigning Designated Experts
. Transfer of Control
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Author's Address
IntroductionThe Internet Assigned Numbers Authority (IANA) maintains registries
to track code points used
by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
A full list of registries and code points can be found at
.Requests may be made to IANA for actions to create registries or to allocate code points from
existing registries. Procedures for these operations are described in .Many requests for IANA action are included in documents that are progressed for publication as RFCs.
RFCs may be sourced from within the IETF (on the IETF Stream) but may also be sourced from other
streams, including the Independent Submission Stream (the Independent Stream), as described in
. The Independent Stream is under the care of the Independent Submissions Editor
(ISE).This document complements by providing a description of how the ISE
currently handles documents in the Independent Stream that request actions from IANA. Nothing
in this document changes existing IANA registries or their allocation policies, nor does it change
any previously documented processes.If a case arises that is not precisely covered by this document, the ISE may discuss
a solution with the interested parties, including IANA, the IESG, the stream managers for other streams,
and the authors of an Independent Submission that requests IANA action.Allocations from Existing RegistriesEach IANA registry is governed by an allocation policy -- the rules that IANA applies to determine
which code points can be allocated and under what circumstances. These policies are described in
.Documents proceeding from the Independent Stream will always follow the assignment policies defined
for the registries from which they request allocations. Similarly, all code point assignments are
subject to the oversight of any designated expert (DE) appointed for the registry.It should be noted that documents on the Independent Stream can never result in Standards Track
RFCs and Independent Stream documents are never subject to IETF review. Thus, a registry whose
policy is "IETF Review" or "Standards Action" is not available to Independent Stream
documents.Changing Policies of Existing RegistriesFrom time to time, a decision is made to change the allocation policy for a registry. Such changes
are normally only made using the allocation policy of the registry itself and usually require documentation
from the same stream that created the registry.Independent Stream RFCs will not seek to change the allocation policies of any registries except
those created by documents from the Independent Stream. The list of such registries is itself
very limited (see ).Creating New IANA RegistriesSometimes registries are needed to track a new set of code points for a new protocol or an extension to an existing protocol.In general, documents on the Independent Stream cannot request the
creation of a new IANA registry.The only exception to this rule is when a document to be published in
the Independent Submission Stream requests the allocation of a code
point from an existing registry with the allocation policy Specification
Required, Expert Review, RFC Required, or First Come First Served.
Then the document to be published may also need to create a registry
that is tied to that specific code point and is used for
interpreting a sub-code.Consider, for example, the "Uniform Resource Identifier (URI)
Schemes" registry . From time to time, a URI scheme
may need a registry of associated parameters; for example, consider
the tel URI scheme that has a register of parameters called the "tel
URI Parameters" .Such examples are rare and only exist to support the allocation from
the base registry. In such cases, where there is an appointed DE for
the existing base registry, the assignment of the individual code
point from the existing base registry and the creation of the new
registry can only happen if the DE approves both actions.There are several further constraints on the new registry:
The allocation policy for the new registry may only be First Come
First Served, RFC Required, Experimental, or Private Use. In
particular, no registry may be created that would require IETF
action to achieve a future code point allocation. See for an explanation of why the application of Specification
Required and Expert Review are not acceptable policies for any
registry created from a document in the Independent Stream.
If the allocation policy for the new registry is First Come First Served,
the document must contain a brief statement and explanation of the expected arrival rate of new registrations over time.
The new registry must contain a clear statement of the escalation
process for any issues that arise with the registry. A model for
this statement is as follows:
This registry was created by [RFCXXXX], which was published on
the Independent Submission Stream. Any issues that arise with
the management of this registry will be resolved by IANA in
consultation with the Independent Submissions Editor.
The IESG will be invited to provide its opinions about the
advisability of the creation of any new registries during its
conflict review of the document , and the ISE will give
full consideration to such opinions.
Authors of Independent Submission Stream documents should consider
the most appropriate venue to host such registries, taking into
account where the expertise for managing and reviewing registry
assignments may be found. In some cases, this may mean that
registries are hosted by organizations other than IANA.Assigning Designated ExpertsSome IANA allocation policies (specifically, Specification Required and Expert Review) utilize
the review of a DE. The procedures applicable to the appointment and actions of a DE are
described in .When a DE is appointed, the position must be maintained and supported by whoever designated the
DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone
must provide a backstop in case the appointed DEs are unresponsive.The ISE will not appoint a DE. That means that no subregistry created for Independent Stream
documents will require the review of a DE. That means that no new subregistry can be
created that uses the Specification Required or Expert Review policies.Transfer of ControlVery rarely, it may be desirable to transfer "ownership" of an IANA registry from the Independent
Stream to the IETF Stream. This might happen, for example, if a protocol was originally
documented in the Independent Stream but has been adopted for work and standardization
in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the
registry and will require discussion and agreement with the ISE.Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream.IANA ConsiderationsThis document is all about IANA actions but makes no request for IANA action.Security ConsiderationsThere are no direct security considerations arising from this document. It may be noted that some IANA
registries relate to security protocols, and the stability and proper management of those registries
contribute to the stability of the protocols themselves. That is a benefit for the security of the
Internet and the users of the Internet.ReferencesNormative ReferencesIndependent Submissions to the RFC EditorThere is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.IESG Procedures for Handling of Independent and IRTF Stream SubmissionsThis document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.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.Informative Referencestel URI ParametersUniform Resource Identifier (URI) SchemesAcknowledgementsThanks to , , , , , , , , , , ,
, and for suggestions and advice.Author's AddressIndependent Submissions Editorrfc-ise@rfc-editor.org