idnits 2.17.1 draft-iab-rfc7500-bis-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC7500, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (26 June 2019) is 1766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2860' is defined on line 283, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7437 (ref. 'BCP10') (Obsoleted by RFC 8713) == Outdated reference: A later version (-11) exists of draft-ietf-iasa2-rfc4071bis-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley, Ed. 3 Internet Architecture Board (IAB) Vigil Security 4 Obsoletes: 7500 (once approved) O. Kolkman, Ed. 5 Intended Status: Informational Internet Society 6 Expires: 26 December 2019 26 June 2019 8 Principles for Operation of 9 Internet Assigned Numbers Authority (IANA) Registries 10 draft-iab-rfc7500-bis-00 12 Abstract 14 This document provides principles for the operation of Internet 15 Assigned Numbers Authority (IANA) registries. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 0. Cover Note ..................................................... 2 56 1. Introduction ................................................... 2 57 2. Principles for the Operation of IANA Registries ................ 4 58 3. Discussion ..................................................... 4 59 3.1. Ensuring Uniqueness, Stability, and Predictability ........ 4 60 3.2. Public .................................................... 5 61 3.3. Open and Transparent ...................................... 5 62 3.4. Accountable ............................................... 5 63 4. Security Considerations ........................................ 6 64 5. Changes Since RFC 7500 ........................................ 6 65 6. Informative References ......................................... 6 66 IAB Members at the Time of Approval ............................... 8 67 Contributors and Acknowledgements ................................. 8 68 Authors' Addresses ................................................ 8 70 0. Cover Note 72 {{ RFC Editor: Please remove this section prior to publication. }} 74 Section 3.4 is changed for alignment with the new structure for the 75 IETF Administrative Support Activity (IASA). 77 1. Introduction 79 The Internet Engineering Task Force (IETF) and its predecessors have 80 traditionally separated the publication of protocol specifications in 81 immutable Request for Comments (RFCs) and the registries containing 82 protocol parameters. Traditionally, the registries are maintained by 83 a set of functions known collectively as the Internet Assigned 84 Numbers Authority (IANA). Dating back to the earliest days of the 85 Internet, specification publication and the registry operations were 86 tightly coupled: Jon Postel of the Information Sciences Institute 87 (ISI) of the University of Southern California (USC) was responsible 88 for both RFC publication and IANA registry operation. This tight 89 coupling had advantages, but it was never a requirement. Indeed, 90 today the RFC Editor and IANA registry operation are provided by 91 different entities. 93 Internet registries are critical to the operation of the Internet, 94 because they provide a definitive record of the value and meaning of 95 identifiers that protocols use when communicating with each other. 96 Almost every Internet protocol makes use of registries in some form. 97 At the time of writing, the IANA maintains more than two thousand 98 protocol parameter registries. 100 Internet registries hold protocol identifiers consisting of constants 101 and other well-known values used by Internet protocols. These values 102 can be numbers, strings, addresses, and so on. They are uniquely 103 assigned for one particular purpose or use. Identifiers can be 104 maintained in a central list (such as a list of cryptographic 105 algorithms) or they can be hierarchically allocated and assigned by 106 separate entities at different points in the hierarchy (such as IP 107 addresses and domain names). To maximize trust and usefulness of the 108 IANA registries, the principles in this document should be taken into 109 consideration for centralized registries as well as hierarchically 110 delegated registries. In hierarchically delegated registries, 111 entries nearest to top level have broad scope, but lower-level 112 entries have narrow scope. The Internet Architecture Board (IAB) 113 will encourage support for these principles in all delegations of 114 Internet identifiers. 116 The registry system is built on trust and mutual cooperation. The 117 use of the registries is voluntary and is not enforced by mandates or 118 certification policies. While the use of registries is voluntary, it 119 is noted that the success of the Internet creates enormous pressure 120 to use Internet protocols and the identifier registries associated 121 with them. 123 This document provides principles for the operation of IANA 124 registries, ensuring that protocol identifiers have consistent 125 meanings and interpretations across all implementations and 126 deployments, and thus providing the necessary trust in the IANA 127 registries. 129 2. Principles for the Operation of IANA Registries 131 The following key principles underscore the successful functioning of 132 the IANA registries, and they provide a foundation for trust in those 133 registries: 135 Ensure Uniqueness: The same protocol identifier must not be used for 136 more than one purpose. 138 Stable: Protocol identifier assignment must be lasting. 140 Predictable: The process for making assignments must not include 141 unexpected steps. 143 Public: The protocol identifiers must be made available in well- 144 known locations in a manner that makes them freely available to 145 everyone. 147 Open: The process that sets the policy for protocol identifier 148 assignment and registration must be open to all interested 149 parties. 151 Transparent: The protocol registries and their associated policies 152 should be developed in a transparent manner. 154 Accountable: Registry policy development and registry operations 155 need to be accountable to the affected community. 157 3. Discussion 159 The principles discussed in Section 2 provide trust and confidence in 160 the IANA registries. This section expands on these principles. 162 3.1. Ensuring Uniqueness, Stability, and Predictability 164 Protocol identifier assignment and registration must be unique, 165 stable, and predictable. Developers, vendors, customers, and users 166 depend on the registries for unique protocol identifiers that are 167 assigned in a stable and predictable manner. 169 A protocol identifier may only be reassigned for a different purpose 170 after due consideration of the impact of such a reassignment, and if 171 possible, with the consent of the original assignee. 173 Recognizing that some assignments involve judgment, such as those 174 involving a designated expert [RFC5226], a predictable process does 175 not require completion in a predetermined number of days. Rather, it 176 means that no unexpected steps are introduced in the process of 177 making an assignment. 179 3.2. Public 181 Once assigned, the protocol identifiers must be made available in a 182 manner that makes them freely available to everyone without 183 restrictions. The use of a consistent publication location builds 184 confidence in the registry. This does not mean that the publication 185 location can never change, but it does mean that it must change 186 infrequently and only after adequate prior notice. 188 3.3. Open and Transparent 190 The process that sets the policy for protocol identifier assignment 191 and registration must be open to all interested parties and operate 192 in a transparent manner. 194 When a registry is established, a policy is set for the addition of 195 new entries and the updating of existing entries. While making 196 additions and modifications, the registry operator may expose 197 instances where policies lack clarity. When this occurs, the 198 registry operator should provide helpful feedback to allow those 199 policies to be improved. In addition, the registry operator not 200 being involved in establishing registry policy avoids the risks 201 associated with (perceptions of) favoritism and unfairness. 203 Recognizing that some assignments involve judgment, such as those 204 involving a designated expert [RFC5226], the recommendations by 205 designated experts must be visible to the public to the maximum 206 extent possible and subject to challenge or appeal. 208 3.4. Accountable 210 The process that sets the policy for IANA registries and the 211 operation of the registries must be accountable to the parties that 212 rely on the protocol identifiers. Oversight is needed to ensure 213 these are properly serving the affected community. 215 In practice, accountability mechanisms for the registry operator may 216 be defined by contract, memoranda of understanding, or service level 217 agreements (SLAs). An oversight body uses these mechanisms to ensure 218 that the registry operator is meeting the needs of the affected 219 community. The oversight body is held accountable to the affected 220 community by vastly different mechanisms, for instance recall and 221 appeal processes. 223 For protocol parameters [RFC6220], the general oversight of the IANA 224 function is performed by the IAB as a chartered responsibility from 226 [RFC2850]. In addition, the IETF Administration Limited Liability 227 Company (IETF LLC), as part of the IETF Administrative Support 228 Activity (IASA), is responsible for IETF administrative and financial 229 matters [I-D.ietf-iasa2-rfc4071bis], and in that role, the IETF LLC 230 maintains a SLA with the current registry operator, the Internet 231 Corporation for Assigned names and Numbers (ICANN), thereby 232 specifying the operational requirements with respect to the 233 coordination, maintenance, and publication of the protocol parameter 234 registries. Both the IAB and the Board of the IETF LLC are 235 accountable to the larger Internet community and are being held 236 accountable through the IETF NomCom process [BCP10]. 238 For the Internet Number Registries [RFC7249], oversight is performed 239 by the Regional Internet Registries (RIRs) as described RFC 7020 240 [RFC7020]. The RIRs are member-based organizations, and they are 241 accountable to the affected community by elected governance boards. 242 Furthermore, per agreement between the RIRs and ICANN, the policy 243 development for the global IANA number registries is coordinated by a 244 community-elected number council and subject to process review before 245 ratification by the ICANN Board of Trustees [ASOMOU]. 247 4. Security Considerations 249 Internet Registries are critical to elements of Internet security. 250 The principles described in this document are necessary for the 251 Internet community to place trust in the IANA registries. 253 5. Changes Since RFC 7500 255 Section 3.4 has been updated to align with the restructuring of the 256 IETF Administrative Support Activity (IASA). Under the new 257 structure, the IETF LLC maintains a SLA with the protocol parameter 258 registry operator. Under the old structure, the SLA was maintained 259 by the IETF Administrative Oversight Committee (IAOC). 261 6. Informative References 263 [ASOMOU] ICANN, "ICANN Address Supporting Organization (ASO) MoU", 264 October 2004, 265 . 267 [BCP10] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 268 Confirmation, and Recall Process: Operation of the 269 Nominating and Recall Committees", BCP 10, RFC 7437, 270 January 2015, . 272 [I-D.ietf-iasa2-rfc4071bis] 273 Haberman, B., Hall, J., and J. Livingood, "Structure of 274 the IETF Administrative Support Activity, Version 2.0", 275 draft-ietf-iasa2-rfc4071bis-00 (work in progress), 276 December 2018. 278 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 279 "Charter of the Internet Architecture Board (IAB)", BCP 280 39, RFC 2850, May 2000, 281 . 283 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 284 Understanding Concerning the Technical Work of the 285 Internet Assigned Numbers Authority", RFC 2860, June 2000, 286 . 288 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 289 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 290 May 2008, . 292 [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., 293 Huston, G., Ed., and Internet Architecture Board, 294 "Defining the Role and Function of IETF Protocol Parameter 295 Registry Operators", RFC 6220, April 2011, 296 . 298 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 299 Internet Numbers Registry System", RFC 7020, August 2013, 300 . 302 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 303 2014, . 305 IAB Members at the Time of Approval 307 {{ RFC Editor: Fill in the current membership. }} 309 Contributors and Acknowledgements 311 This text has been developed within the IAB IANA Evolution Program. 312 The ideas and many text fragments, and corrections came from or were 313 inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, 314 Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve 315 Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, 316 John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, 317 George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew 318 Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further 319 inspiration and input was drawn from various meetings with IETF and 320 other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership. 322 Please do not assume those acknowledged endorse the resulting text. 324 Authors' Addresses 326 Russ Housley 327 Vigil Security, LLC 328 918 Spring Knoll Drive 329 Herndon, VA 20170 330 USA 331 EMail: housley@vigilsec.com 333 Olaf Kolkman 334 Internet Society 335 Science Park 400 336 Amsterdam 1098 XH 337 The Netherlands 338 EMail: kolkman@isoc.org