idnits 2.17.1 draft-iab-iana-principles-05.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 (26 February 2015) is 3309 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 193, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC2860' is defined on line 270, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3777 (ref. 'BCP10') (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 4071 (ref. 'BCP101') (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board (IAB) R. Housley (editor) 3 Internet-Draft Vigil Security 4 Intended status: Informational O. Kolkman (editor) 5 Internet Society 6 Expires: 26 August 2015 26 February 2015 8 Principles for Operation of 9 Internet Assigned Numbers Authority (IANA) Registries 11 draft-iab-iana-principles-05 13 Abstract 15 This document provides principles for the operation of Internet 16 Assigned Numbers Authority (IANA) registries. 18 {{{ RFC Editor: Please delete the note prior to publication. }}} 20 Note: This Internet-Draft was developed by the IAB IANA Evolution 21 Program, and it should be discussed on the InternetGovtech@iab.org 22 mail list. See http://www.iab.org/mailman/listinfo/internetgovtech 23 for subscription details. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 26 August 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 0. Document Background 59 {{{ RFC Editor: Please delete this section prior to publication. }}} 61 This document is a split off from draft-iab-iana-framework-02. This 62 document contains principles that were scattered in various places in 63 the IANA Framework, pulling them into one place. 65 The IANA Framework has been under discussion since February 2011. 67 1. Introduction 69 The Internet Engineering Task Force (IETF) and its predecessors have 70 traditionally separated the publication of protocol specifications in 71 immutable Request for Comments (RFCs) and the registries containing 72 protocol parameters. The latter is maintained by a set of functions 73 traditionally known collectively as the Internet Assigned Numbers 74 Authority (IANA). Dating back to the earliest days of the Internet, 75 specification publication and the registry operations were tightly 76 coupled: Jon Postel of the Information Sciences Institute (ISI) of 77 the University of Southern California (USC) was responsible for both 78 RFC publication and IANA registry operation. This tight coupling had 79 advantages, but it was never a requirement. Indeed, today the RFC 80 Editor and IANA registry operation are provided by different 81 entities. 83 Internet registries are critical to the operation of the Internet, 84 since they provide a definitive record of the value and meaning of 85 identifiers that protocols use when communicating with each other. 86 Almost every Internet protocol makes use of registries in some form. 87 At the time of writing, the IANA maintains more than two thousand 88 protocol parameter registries. 90 Internet registries hold protocol identifiers consisting of constants 91 and other well-known values used by Internet protocols. These values 92 can be numbers, strings, addresses, and so on. They are uniquely 93 assigned for one particular purpose or use. Identifiers can be 94 maintained in a central list (such as a list of cryptographic 95 algorithms) or they can be hierarchically allocated and assigned by 96 separate entities at different points in the hierarchy (such as IP 97 addresses and domain names). To maximize trust and usefulness, the 98 principles in this document should be taken into consideration for 99 centralized registries as well as hierarchically delegated 100 registries. In hierarchically delegated registries, entries nearest 101 to top-level have broad scope, but lower-level entries have narrow 102 scope. The IAB will encourage support for these principles in all 103 delegations of Internet identifiers. 105 The registry system is built on trust and mutual cooperation. The 106 use of the registries is voluntary and is not enforced by mandates or 107 certification policies. While the use of registries is voluntary, it 108 is noted that the success of the Internet creates enormous pressure 109 to use Internet protocols and the identifier registries associated 110 with them. 112 This document provides principles for the operation of IANA 113 registries, ensuring that protocol identifiers have consistent 114 meanings and interpretations across all implementations and 115 deployments, and thus providing the necessary trust in the IANA 116 registries. 118 2. Principles for the Operation of IANA Registries 120 The following key principles underscore the successful functioning of 121 the IANA registries, and they provide a foundation for trust in those 122 registries: 124 Ensure Uniqueness: The same protocol identifier must not be used for 125 more than one purpose. 127 Stable: Protocol identifier assignment must be lasting. 129 Predictable: The process for making assignments must not include 130 unexpected steps. 132 Public: The protocol identifiers must be made available in a manner 133 that makes them freely available to everyone in well-known 134 locations. 136 Open: The process that sets the policy for protocol identifier 137 assignment and registration must be open to all interested 138 parties. 140 Transparent: The protocol registries and their associated policies 141 should be developed in a transparent manner. 143 Accountable: Registry policy development and registry operations 144 need to be accountable to the affected community. 146 3. Discussion 148 The principles discussed in Section 2 provide trust and confidence in 149 the IANA registries. 151 3.1. Ensuring Uniqueness, Stability, and Predictability 153 Protocol identifier assignment and registration must be unique, 154 stable, and predictable. Developers, vendors, customers, and users 155 depend on the registries for unique protocol identifiers that are 156 assigned in a stable and predictable manner. 158 A protocol identifier may only be reassigned for a different purpose 159 after due consideration of the impact of such a reassignment, and if 160 possible, with the consent of the original assignee. 162 Recognizing that some assignments involve judgment, such as those 163 involving a designated expert [RFC5226], a predictable process does 164 not require completion in a predetermined number of days. Rather, it 165 means that no unexpected steps are introduced in the process of 166 making an assignment. 168 3.2. Public 170 Once assigned, the protocol identifiers must be made available in a 171 manner that makes them freely available to everyone without 172 restrictions. The use of a consistent publication location builds 173 confidence in the registry. This does not mean that the publication 174 location can never change, but it does mean that it must change 175 infrequently and only after adequate prior notice. 177 3.3. Open and Transparent 179 The process that sets the policy for protocol identifier assignment 180 and registration must be open to all interested parties and operate 181 in a transparent manner. 183 When a registry is established, a policy is set for the addition of 184 new entries and the updating of existing entries. While making 185 additions and modifications, the registry operator may expose 186 instances where policies lack of clarity. When this occurs, the 187 registry operator should provide helpful feedback to allow those 188 policies to be improved. In addition, the registry operator not 189 being involved in establishing registry policy avoids the risks 190 associated with (perceptions of) favoritism and unfairness. 192 Recognizing that some assignments involve judgment, such as those 193 involving a designated expert [RFC5226], the recommendations by 194 designated experts must be visible to the public to the maximum 195 extent possible and subject to challenge or appeal. 197 3.4. Accountable 199 The process that sets the policy for IANA registries and the 200 operation of the registries must be accountable to the parties that 201 rely on the protocol identifiers. Oversight is needed to ensure 202 these are properly serving the affected community. 204 In practice accountability mechanisms for the registry operator may 205 be defined by contract, memoranda of understanding, or service level 206 agreements (SLAs). An oversight body uses these mechanisms to ensure 207 that the registry operator is meeting the needs of the affected 208 community, but the oversight body is held accountable to the affected 209 community by vastly different mechanisms, for instance recall and 210 appeal processes. 212 For protocol parameters [RFC6220], the general oversight over the 213 IANA function is performed by the IAB as a chartered responsibility 214 from [RFC2850]. In addition the IETF Administrative Oversight 215 Committee (IAOC), a body responsible for IETF administrative and 216 financial matters [BCP101], maintains an SLA with the current 217 registry operator, the Internet Corporation for Assigned names and 218 Numbers (ICANN), thereby specifying the operational requirements with 219 respect to the coordination, maintenance, and publication of the 220 protocol parameter registries. Both the IAB and the IAOC are 221 accountable to the larger Internet community and are being held 222 accountable through the IETF Nomcom process [BCP10]. 224 For the Internet Number Registries [RFC7249], oversight is performed 225 by the Regional Internet Registries (RIRs) as described RFC 7020 226 [RFC7020]. The RIRs are member-based organizations, and they are 227 accountable to the affected community by elected governance boards. 228 Furthermore, per agreement between the RIRs and ICANN, the policy 229 development for the global IANA number registries is coordinated by a 230 community-elected number council and subject to process review before 231 ratification by the ICANN Board of Trustees [ASOMOU]. 233 4. Security Considerations 235 Internet Registries are critical to elements of Internet security. 236 The principles described in this document are necessary for the 237 Internet community to place trust in the IANA registries. 239 5. IANA Considerations 241 {{{ RFC Editor: Please delete this section prior to publication. }}} 243 This document does not contain updates to any registries. 245 6. Informative References 247 [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization 248 (ASO) MoU", October 2004, 249 . 251 [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 252 and Recall Process: Operation of the Nominating and Recall 253 Committees", BCP 10, RFC 3777, June 2004. 255 Dawkins, S., "Nominating Committee Process: Earlier 256 Announcement of Open Positions and Solicitation of 257 Volunteers", BCP 10, RFC 5633, August 2009. 259 [BCP101] Austein, R. and B. Wijnen, "Structure of the IETF 260 Administrative Support Activity (IASA)", BCP 101, RFC 261 4071, April 2005. 263 Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for 264 IPR Trust", BCP 101, RFC 4371, January 2006. 266 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 267 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 268 May 2000. 270 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 271 Understanding Concerning the Technical Work of the 272 Internet Assigned Numbers Authority", RFC 2860, June 2000. 274 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and 275 Internet Architecture Board, "Defining the Role and 276 Function of IETF Protocol Parameter Registry Operators", 277 RFC 6220, April 2011. 279 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 280 Internet Numbers Registry System", RFC 7020, August 2013. 282 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 283 2014. 285 IAB Members at the Time of Approval 287 Jari Arkko (IETF Chair) 288 Mary Barnes 289 Marc Blanchet 290 Joel Halpern 291 Ted Hardie 292 Joe Hildebrand 293 Russ Housley 294 Eliot Lear 295 Xing Li 296 Erik Nordmark 297 Andrew Sullivan 298 Dave Thaler 299 Brian Trammell 301 Contributors and Acknowledgements 303 This text has been developed within the IAB IANA Evolution Program. 304 The ideas and many text fragments, and corrections came from or were 305 inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, 306 Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve 307 Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, 308 John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, 309 George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew 310 Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further 311 inspiration and input was drawn from various meetings with IETF and 312 other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership. 314 Please do not assume those acknowledged endorse the resulting text. 316 Authors' Addresses 318 Russ Housley 319 918 Spring Knoll Drive 320 Herndon, VA 20170 321 USA 322 Email: housley@vigilsec.com 324 Olaf Kolkman 325 Science Park 400 326 Amsterdam 1098 XH 327 The Netherlands 328 EMail: kolkman@isoc.org