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