wdiff rfc8726.original rfc8726.txt

Network Working Group

Independent Submission A. Farrel
Internet-Draft
Request for Comments: 8726 Independent Submissions Editor
Intended status:
Category: Informational September 23, 2019
Expires: March 26, November 2020
ISSN: 2070-1721

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

Abstract

The Independent Submissions 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 Submissions Submission
Stream that request actions from the 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 Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 26, 2020.
https://www.rfc-editor.org/info/rfc8726.

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. Transfer of Control . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
10. References
9.1. Normative References . . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References
Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction

The Internet Assigned Numbers Authority (IANA) maintains registries
to track codepoints 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>.
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), Stream) but may also be sourced from other
streams
streams, including the Independent Submissions Submission Stream (the Independent
Stream)
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 the IANA. Nothing in this document changes existing
IANA registries or their allocation policies, nor does it change any
previously documented processes.

In the event that

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: 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 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 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 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, itself and usually require
documentation from the same stream as 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, is itself very
limited (see Section 4).

4. Creating New IANA Registries

Sometimes new registries are needed to track a new set of codepoints 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 the creation of when a sub-registry
that is specifically tied document to be published in
the Independent Submission Stream requests the allocation of a code
point allocated for the same
document from an existing registry where with the allocation policy for
that document is
Specification Required, Expert Review, RFC Required, or First Come
First Served. Furthermore, 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 parent existing base registry, that DE must approve the assignment of the individual code
point from the existing base registry and the creation of the
sub-registry. Additionally, 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 sub- registry may only be First Come
First Served, RFC Required, Experimental, or Private Use. In
particular, no sub-registry registry may be created that would require IETF
action to achieve a future codepoint 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 sub-registry
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
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 sub-registry subregistry
created for Independent Stream documents will require the review of a
DE. That means that no new sub-registry 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, 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, 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, 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 contributes 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. Acknowledgements

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

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