idnits 2.17.1 draft-ise-iana-policy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2019) is 1677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet-Draft Independent Submissions Editor 4 Intended status: Informational September 23, 2019 5 Expires: March 26, 2020 7 How Requests for IANA Action Will be Handled on the Independent Stream 8 draft-ise-iana-policy-03 10 Abstract 12 The Internet Assigned Numbers Authority (IANA) maintains registries 13 to track codepoints used by protocols such as those defined by the 14 IETF and documented in RFCs developed on the IETF Stream. 16 The Independent Submissions Stream is another source of documents 17 that can be published as RFCs. This stream is under the care of the 18 Independent Submissions Editor (ISE). 20 This document complements RFC 4846 by providing a description of how 21 the ISE currently handles documents in the Independent Submissions 22 Stream that request actions from the IANA. Nothing in this document 23 changes existing IANA registries or their allocation policies, nor 24 does it change any previously documented processes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 26, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Allocations from Existing Registries . . . . . . . . . . . . 3 62 3. Changing Policies of Existing Registries . . . . . . . . . . 3 63 4. Creating New IANA Registries . . . . . . . . . . . . . . . . 3 64 5. Assigning Designated Experts . . . . . . . . . . . . . . . . 4 65 6. Transfer of Control . . . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 The Internet Assigned Numbers Authority (IANA) maintains registries 75 to track codepoints used by protocols such as those defined by the 76 IETF and documented in RFCs developed on the IETF Stream. A full 77 list of registries and code points can be found at 78 . 80 Requests may be made to IANA for actions to create registries or to 81 allocate code points from existing registries. Procedures for these 82 operations are described in [RFC8126]. 84 Many requests for IANA action are included in documents that are 85 progressed for publication as RFCs. RFCs may be sourced from within 86 the IETF (on the IETF Stream), but may also be sourced from other 87 streams including the Independent Submissions Stream (the Independent 88 Stream) as described in [RFC4846]. The Independent Stream is under 89 the care of the Independent Submissions Editor (ISE). 91 This document complements [RFC4846] by providing a description of how 92 the ISE currently handles documents in the Independent Stream that 93 request actions from the IANA. Nothing in this document changes 94 existing IANA registries or their allocation policies, nor does it 95 change any previously documented processes. 97 In the event that a case arises that is not precisely covered by this 98 document, the ISE may discuss a solution with the interested parties, 99 including IANA, the IESG, the stream managers for other streams, and 100 the authors of an Independent Submission that requests IANA action. 102 2. Allocations from Existing Registries 104 Each IANA registry is governed by an allocation policy: the rules 105 that IANA applies to determine which code points can be allocated and 106 under what circumstances. These policies are described in [RFC8126]. 108 Documents proceeding from the Independent Stream will always follow 109 the assignment policies defined for the registries from which they 110 request allocations. Similarly, all code point assignments are 111 subject to the oversight of any Designated Expert (DE) appointed for 112 the registry. 114 It should be noted that documents on the Independent Stream can never 115 result in Standards Track RFCs and Independent Stream documents are 116 never subject to IETF review. Thus a registry whose policy is "IETF 117 Review" or "Standards Action" [RFC8126] is not available to 118 Independent Stream documents. 120 3. Changing Policies of Existing Registries 122 From time to time a decision is made to change the allocation policy 123 for a registry. Such changes are normally only made using allocation 124 policy of the registry itself, and usually require documentation from 125 the same stream as created the registry. 127 Independent Stream RFCs will not seek to change the allocation 128 policies of any registries except those created by documents from the 129 Independent Stream. The list of such registries is, itself, very 130 limited (see Section 4). 132 4. Creating New IANA Registries 134 Sometimes new registries are needed to track a new set of codepoints 135 for a new protocol or an extension to an existing protocol. In 136 general, documents on the Independent Stream cannot request the 137 creation of a new registry. 139 The only exception to this rule is the creation of a sub-registry 140 that is specifically tied to a code point allocated for the same 141 document from an existing registry where the allocation policy for 142 that document is Specification Required, Expert Review, RFC Required, 143 or First Come First Served. Furthermore, where there is an appointed 144 DE for the parent registry, that DE must approve the creation of the 145 sub-registry. Additionally, the allocation policy for the new sub- 146 registry may only be First Come First Served, RFC Required, 147 Experimental, or Private Use. In particular, no sub-registry may be 148 created that would require IETF action to achieve a future codepoint 149 allocation. See Section 5 for an explanation of why the application 150 of Specification Required and Expert Review are not acceptable 151 policies for any sub-registry created from a document in the 152 Independent Stream. 154 5. Assigning Designated Experts 156 Some IANA allocation policies (specifically, Specification Required 157 and Expert Review) utilize the review of a DE. The procedures 158 applicable to the appointment and actions of a DE are described in 159 section 5 of [RFC8126]. 161 When a DE is appointed, the position must be maintained and supported 162 by whoever designated the DE in the first place. That is, someone 163 must appoint replacement DEs if necessary, and someone must provide a 164 backstop in case the appointed DEs are unresponsive. 166 The ISE will not appoint a DE. That means that no sub-registry 167 created for Independent Stream documents will require the review of a 168 DE. That means that no new sub-registry can be created that uses the 169 Specification Required or Expert Review policies. 171 6. Transfer of Control 173 Very rarely, it may be desirable to transfer "ownership" of an IANA 174 registry from the Independent Stream to the IETF Stream. This might 175 happen, for example, if a protocol was originally documented in the 176 Independent Stream, but has been adopted for work and standardization 177 in the IETF. Such a transfer may require an IETF Stream RFC to act 178 as the base reference for the registry, and will require discussion 179 and agreement with the ISE. 181 Ownership of a registry will not be transferred from the IETF Stream 182 to the Independent Stream. 184 7. IANA Considerations 186 This document is all about IANA actions, but makes no request for 187 IANA action. 189 8. Security Considerations 191 There are no direct security considerations arising from this 192 document. It may be noted that some IANA registries relate to 193 security protocols, and the stability and proper management of those 194 registries contributes to the stability of the protocols themselves. 195 That is a benefit for the security of the Internet and the users of 196 the Internet. 198 9. Acknowledgements 200 Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, 201 Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz, 202 Michael Richardson, Colin Perkins, Brian Carpenter, Stephen Farrell, 203 Barry Leiba, and Benjamin Kaduk for suggestions and advice. 205 10. Normative References 207 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent 208 Submissions to the RFC Editor", RFC 4846, 209 DOI 10.17487/RFC4846, July 2007, 210 . 212 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 213 Writing an IANA Considerations Section in RFCs", BCP 26, 214 RFC 8126, DOI 10.17487/RFC8126, June 2017, 215 . 217 Author's Address 219 Adrian Farrel 220 Independent Submissions Editor 222 Email: rfc-ise@rfc-editor.org