idnits 2.17.1 draft-iab-iana-principles-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 (5 January 2015) is 3399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 191, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC2860' is defined on line 268, 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: 9 July 2015 5 January 2015 8 Principles for Operation of 9 Internet Assigned Numbers Authority (IANA) Registries 11 draft-iab-iana-principles-03 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 9 July 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). The principles contained in this 98 document should be taken into consideration for all hierarchal 99 Internet registries to maximize trust and usefulness throughout each 100 identifier space. The IAB will encourage support for these 101 principles in all delegations of Internet identifiers. 103 The registry system is built on trust and mutual cooperation. The 104 use of the registries is voluntary and is not enforced by mandates or 105 certification policies. While the use of registries is voluntary, it 106 is noted that the success of the Internet creates enormous pressure 107 to use Internet protocols and the identifier registries associated 108 with them. 110 This document provides principles for the operation of IANA 111 registries, ensuring that protocol identifiers have consistent 112 meanings and interpretations across all implementations and 113 deployments, and thus providing the necessary trust in the IANA 114 registries. 116 2. Principles for the Operation of IANA Registries 118 The following key principles underscore the successful functioning of 119 the IANA registries, and they provide a foundation for trust in those 120 registries: 122 Ensure Uniqueness: The same protocol identifier must not be used for 123 more than one purpose. 125 Stable: Protocol identifier assignment must be lasting. 127 Predictable: The process for making assignments must not include 128 unexpected steps. 130 Public: The protocol identifiers must be made available in a manner 131 that makes them freely available to everyone in well-known 132 locations. 134 Open: The process that sets the policy for protocol identifier 135 assignment and registration must be open to all interested 136 parties. 138 Transparent: The protocol registries and their associated policies 139 should be developed in a transparent manner. 141 Accountable: Registry policy development and registry operations 142 need to be accountable to the affected community. 144 3. Discussion 146 The principles discussed in Section 2 provide trust and confidence in 147 the IANA registries. 149 3.1. Ensuring Uniqueness, Stability, and Predictability 151 Protocol identifier assignment and registration must be unique, 152 stable, and predictable. Developers, vendors, customers, and users 153 depend on the registries for unique protocol identifiers that are 154 assigned in a stable and predictable manner. 156 A protocol identifier may only be reassigned for a different purpose 157 after due consideration of the impact of such a reassignment, and if 158 possible, with the consent of the original assignee. 160 Recognizing that some assignments involve judgment, such as those 161 involving a designated expert [RFC5226], a predictable process does 162 not require completion in a predetermined number of days. Rather, it 163 means that no unexpected steps are introduced in the process of 164 making an assignment. 166 3.2. Public 168 Once assigned, the protocol identifiers must be made available in a 169 manner that makes them freely available to everyone without 170 restrictions. The use of a consistent publication location builds 171 confidence in the registry. This does not mean that the publication 172 location can never change, but it does mean that it must change 173 infrequently and only after adequate prior notice. 175 3.3. Open and Transparent 177 The process that sets the policy for protocol identifier assignment 178 and registration must be open to all interested parties and operate 179 in a transparent manner. 181 When a registries is established, a policy is set for the addition of 182 new entries and the updating of existing entries. While making 183 additions and modifications, the registry operator may expose 184 instances where policies lack of clarity. When this occurs, the 185 registry operator should provide helpful feedback to allow those 186 policies to be improved. In addition, the registry operator not 187 being involved in establishing registry policy avoids the risks 188 associated with (perceptions of) favoritism and unfairness. 190 Recognizing that some assignments involve judgment, such as those 191 involving a designated expert [RFC5226], the recommendations by 192 designated experts must be visible to the public to the maximum 193 extent possible and subject to challenge or appeal. 195 3.4. Accountable 197 The process that sets the policy for IANA registries and the 198 operation of the registries must be accountable to the parties that 199 rely on the protocol identifiers. Oversight is needed to ensure 200 these are properly serving the affected community. 202 In practice accountability mechanisms for the registry operator may 203 be defined by contract, memoranda of understanding, or service level 204 agreements (SLAs). An oversight body uses these mechanisms to ensure 205 that these registry operator is meeting the needs of the affected 206 community, but the oversight body is held accountable to the affected 207 community by vastly different mechanisms, for instance recall and 208 appeal processes. 210 For protocol parameters [RFC6220], the general oversight over the 211 IANA function is performed by the IAB as a chartered responsibility 212 from [RFC2850]. In addition the IETF Administrative Oversight 213 Committee (IAOC), a body responsible for IETF administrative and 214 financial matters [BCP101], maintains an SLA with the current 215 registry operator, the Internet Corporation for Assigned names and 216 Numbers (ICANN), thereby specifying the operational requirements with 217 respect to the coordination, maintenance, and publication of the 218 protocol parameter registries. Both the IAB and the IAOC are 219 accountable to the larger Internet community and are being held 220 accountable through the IETF Nomcom process [BCP10]. 222 For the Internet Number Registries [RFC7249], oversight is performed 223 by the Regional Internet Registries (RIRs) as described RFC 7020 224 [RFC7020]. The RIRs are member-based organizations, and they are 225 accountable to the affected community by elected governance boards. 226 Furthermore, per agreement between the RIRs and ICANN, the policy 227 development for the global IANA number registries is coordinated by a 228 community-elected number council and subject to process review before 229 ratification by the ICANN Board of Trustees [ASOMOU]. 231 4. Security Considerations 233 Internet Registries are critical to elements of Internet security. 234 The principles described in this document are necessary for the 235 Internet community to place trust in the IANA registries. 237 5. IANA Considerations 239 {{{ RFC Editor: Please delete this section prior to publication. }}} 241 This document does not contain updates to any registries. 243 6. Informative References 245 [ASOMOU] Published by ICANN, "ICANN Address Supporting Organization 246 (ASO) MoU", October 2004, 247 . 249 [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 250 and Recall Process: Operation of the Nominating and Recall 251 Committees", BCP 10, RFC 3777, June 2004. 253 Dawkins, S., "Nominating Committee Process: Earlier 254 Announcement of Open Positions and Solicitation of 255 Volunteers", BCP 10, RFC 5633, August 2009. 257 [BCP101] Austein, R. and B. Wijnen, "Structure of the IETF 258 Administrative Support Activity (IASA)", BCP 101, RFC 259 4071, April 2005. 261 Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for 262 IPR Trust", BCP 101, RFC 4371, January 2006. 264 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 265 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 266 May 2000. 268 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 269 Understanding Concerning the Technical Work of the 270 Internet Assigned Numbers Authority", RFC 2860, June 2000. 272 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and 273 Internet Architecture Board, "Defining the Role and 274 Function of IETF Protocol Parameter Registry Operators", 275 RFC 6220, April 2011. 277 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 278 Internet Numbers Registry System", RFC 7020, August 2013. 280 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 281 2014. 283 IAB Members at the Time of Approval 285 Jari Arkko (IETF Chair) 286 Mary Barnes 287 Marc Blanchet 288 Joel Halpern 289 Ted Hardie 290 Joe Hildebrand 291 Russ Housley 292 Eliot Lear 293 Xing Li 294 Erik Nordmark 295 Andrew Sullivan 296 Dave Thaler 297 Brian Trammell 299 Contributors and Acknowledgements 301 This text has been developed within the IAB IANA Evolution Program. 302 The ideas and many text fragments, and corrections came from or were 303 inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, 304 Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve 305 Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, 306 John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, 307 George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew 308 Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further 309 inspiration and input was drawn from various meetings with IETF and 310 other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership. 312 Please do not assume those acknowledged endorse the resulting text. 314 Authors' Addresses 316 Russ Housley 317 918 Spring Knoll Drive 318 Herndon, VA 20170 319 USA 320 Email: housley@vigilsec.com 322 Olaf Kolkman 323 Science Park 400 324 Amsterdam 1098 XH 325 The Netherlands 326 EMail: kolkman@isoc.org