Network Working Group                                          A. Farrel
Internet-Draft                            Independent Submissions Editor
Updates: 4846 (if approved)                              August 13, 2019
Intended status: Informational
Expires: February 14, 2020


 How Requests for IANA Action Will be Handled on the Independent Stream
                        draft-ise-iana-policy-00

Abstract

   The Internet Assigned Numbers Authority (IANA) maintains registries
   to track codepoints used by protocols defined by the IETF and
   documented in RFCs developed on the IETF Stream.

   The Independent Submissions 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 updates RFC 4846 by describing how the current ISE will
   handle documents in the Independent Submissions Stream that request
   actions from the IANA.  Nothing in this document changes existing
   IANA registries and their allocation policies.

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
   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 February 14, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Farrel                  Expires February 14, 2020               [Page 1]


Internet-Draft       IANA and the Independent Stream         August 2019


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Allocations from Existing Registries  . . . . . . . . . . . .   3
   3.  Changing Policies of Existing Registries  . . . . . . . . . .   3
   4.  Creating New IANA Registries  . . . . . . . . . . . . . . . .   3
   5.  Assigning Designated Experts  . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The Internet Assigned Numbers Authority (IANA) maintains registries
   to track codepoints used by protocols 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 on the
   Independent Submissions Stream (the Independent Stream) as described
   in [RFC4846].  The Independent Stream is under the care Independent
   Submissions Editor (ISE).

   This document updates [RFC4846] describes how the current ISE will
   handle documents in the Independent Stream that request actions from
   the IANA.  Nothing in this document changes existing IANA registries
   and their allocation policies.





Farrel                  Expires February 14, 2020               [Page 2]


Internet-Draft       IANA and the Independent Stream         August 2019


   In the event that 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, 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 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 allocation
   policy of the registry itself, and usually require documentation from
   the same stream as 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 new registries are needed to track a new set of codepoints
   for a new protocol or an extension to an existing protocol.  In
   general, documents on the Independent Stream can not request the
   creation of a new registry.

   The only exception to this rule is the creation of a sub-registry
   that is specifically tied to a code point allocated for the same
   document from an existing registry where the allocation policy for
   that document is Specification Required, Expert Review, or RFC
   Required.  Furthermore, where there is an appointed Designated Expert
   (DE) for the parent registry, that DE must approve the creation of



Farrel                  Expires February 14, 2020               [Page 3]


Internet-Draft       IANA and the Independent Stream         August 2019


   the sub-registry.  Additionally, the allocation policy for the new
   sub-registry may only be First Come First Served or RFC Required.  In
   particular, no sub-registry may be created that would require IETF
   action to achieve a future codepoint allocation.  See Section 5 for
   an explanation of why the application of Specification Required and
   Expert Review are not acceptable policies for any sub-registry
   created from a document in the Independent Stream.

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 all sub-registries
   created for Independent Stream documents will not require the review
   of a DE.  That means that no new sub-registry can be created that
   uses the Specification Required or Expert Review policies.

6.  IANA Considerations

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

7.  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 contributes to the stability of the protocols themselves.
   That is a benefit for the security of the Internet and the users of
   the Internet.

8.  Acknowledgements

   Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge,
   and Michelle Cotton for suggestions and advice.








Farrel                  Expires February 14, 2020               [Page 4]


Internet-Draft       IANA and the Independent Stream         August 2019


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

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

Author's Address

   Adrian Farrel
   Independent Submissions Editor

   Email: rfc-ise@rfc-editor.org

































Farrel                  Expires February 14, 2020               [Page 5]