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