doc: Add RFC documents

1 files changed, 281 insertions, 0 deletions

diff --git a/doc/rfc/rfc8726.txt b/doc/rfc/rfc8726.txt
new file mode 100644
index 0000000..bda95d4
--- /dev/null
+++ b/doc/rfc/rfc8726.txt
@@ -0,0 +1,281 @@
+
+
+
+
+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: rfc-ise@rfc-editor.org