Independent Submission                                         A. Farrel
Request for Comments: 8726                Independent Submissions Editor
Category: Informational                                    November 2020
ISSN: 2070-1721


How Requests for IANA Action Will Be Handled on the Independent Stream

Abstract

  The 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
  https://www.rfc-editor.org/info/rfc8726.

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
  (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.

Table of Contents

  1.  Introduction
  2.  Allocations from Existing Registries
  3.  Changing Policies of Existing Registries
  4.  Creating New IANA Registries
  5.  Assigning Designated Experts
  6.  Transfer of Control
  7.  IANA Considerations
  8.  Security Considerations
  9.  References
    9.1.  Normative References
    9.2.  Informative References
  Acknowledgements
  Author's Address

1.  Introduction

  The 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
  https://www.iana.org/protocols.

  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 [RFC8126].

  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 [RFC4846].  The Independent Stream is under
  the care of the Independent Submissions Editor (ISE).

  This document complements [RFC4846] 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.

2.  Allocations from Existing Registries

  Each 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 [RFC8126].

  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" [RFC8126] is not available to
  Independent Stream documents.

3.  Changing Policies of Existing Registries

  From 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 Section 4).

4.  Creating New IANA Registries

  Sometimes 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 [URL-URIschemes].  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" [URL-telURI].

  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 Section 5
     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 [RFC5742], 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.

5.  Assigning Designated Experts

  Some 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
  Section 5 of [RFC8126].

  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.

6.  Transfer of Control

  Very 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.

7.  IANA Considerations

  This document is all about IANA actions but makes no request for IANA
  action.

8.  Security Considerations

  There 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.

9.  References

9.1.  Normative References

  [RFC4846]  Klensin, J., Ed. and D. Thaler, Ed., "Independent
             Submissions to the RFC Editor", RFC 4846,
             DOI 10.17487/RFC4846, July 2007,
             <https://www.rfc-editor.org/info/rfc4846>.

  [RFC5742]  Alvestrand, H. and R. Housley, "IESG Procedures for
             Handling of Independent and IRTF Stream Submissions",
             BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
             <https://www.rfc-editor.org/info/rfc5742>.

  [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>.

9.2.  Informative References

  [URL-telURI]
             "tel URI Parameters",
             <https://www.iana.org/assignments/tel-uri-parameters>.

  [URL-URIschemes]
             "Uniform Resource Identifier (URI) Schemes",
             <https://www.iana.org/assignments/uri-schemes>.

Acknowledgements

  Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge,
  Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz,
  Michael Richardson, Colin Perkins, Stephen Farrell, Barry Leiba, and
  Benjamin Kaduk for suggestions and advice.

Author's Address

  Adrian Farrel
  Independent Submissions Editor

  Email: [email protected]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.