idnits 2.17.1 draft-iab-iana-principles-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 November 2014) is 3441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2860' is defined on line 236, 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 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 1 error (**), 0 flaws (~~), 2 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: 22 May 2015 18 November 2014 8 Principles for Operation of 9 Internet Assigned Numbers Authority (IANA) Registries 11 draft-iab-iana-principles-00 13 Abstract 15 This document provides principles for the operation of Internet 16 Assigned Numbers Authority (IANA) registries. 18 Note: This is Internet-Draft was developed by the IAB IANA Evolution 19 Program, and it should be discussed on the InternetGovtech@iab.org 20 mail list. See http://www.iab.org/mailman/listinfo/internetgovtech 21 for subscription details. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 21 May 2015. 40 Copyright Notice 42 Copyright (c) 2014 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 (http://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 0. Document Background 57 {{{ RFC Editor: Please delete this section prior to publication. }}} 59 This document is a split off from draft-iab-iana-framework-02. This 60 document contains principles that were scattered in various places in 61 the IANA Framework, pulling them into one place. 63 The IANA Framework has been under discussion since February 2011. 65 1. Introduction 67 The Internet Engineering Task Force (IETF) and its predecessors have 68 traditionally separated the publication of protocol specifications in 69 immutable Request for Comments (RFCs) and the registries containing 70 protocol parameters. The latter is maintained by a set of functions 71 traditionally known collectively as the Internet Assigned Numbers 72 Authority (IANA). Dating back to the earliest days of the Internet, 73 specification publication and the registry operations were tightly 74 coupled: Jon Postel of the Information Sciences Institute (ISI) of 75 the University of Southern California (USC) was responsible for both 76 RFC publication and IANA registry operation. This tight coupling has 77 advantages, but it has never been a requirement. Indeed, today the 78 RFC Editor and IANA registry operation are provided by different 79 entities. 81 Internet registries are critical to the operation of the Internet, 82 since they provide a definitive record of the value and meaning of 83 identifiers that protocols use when communicating with each other. 84 Almost every Internet protocol makes use of registries in some form. 85 At the time of writing, the IANA maintains more than two thousand 86 protocol parameter registries. 88 Internet registries hold protocol identifiers consisting of constants 89 and other well-known values used by Internet protocols. These values 90 can be numbers, strings, addresses, and so on. They are uniquely 91 assigned for one particular purpose or use. Identifiers can be 92 maintained in a central list (such as a list of cryptographic 93 algorithms) or they can be hierarchically allocated and assigned by 94 separate entities at different points in the hierarchy (such as IP 95 addresses and domain names). 97 The registry system is built on trust and mutual cooperation. The 98 use of the registries is voluntary and is not enforced by mandates or 99 certification policies. While the use of registries is voluntary, it 100 is noted that the success of the Internet creates enormous pressure 101 to use Internet protocols and the registries associated with them. 103 This document provides principles for the operation of IANA 104 registries, ensuring that protocol identifiers have consistent 105 meanings and interpretations across all implementations and 106 deployments, and thus providing the necessary trust in the 107 registries. 109 2. Principles for the Operation of IANA Registries 111 The following key principles underscore the successful functioning of 112 the IANA registries, and they provide a foundation for trust in those 113 registries: 115 Unique: The same protocol identifier must not be used for more than 116 one purpose. 118 Stable: Protocol identifier assignment must be lasting. 120 Predictable: The process for making assignments must be predictable. 122 Public Publication: The protocol identifiers must be published in a 123 manner that makes them available to everyone in selected well- 124 known locations. 126 Open: The process that sets the policy for protocol identifier 127 assignment and registration must be open to all interested 128 parties. 130 Transparent: The protocol registries and their associated policies 131 should be developed in a transparent manner. 133 Accountable: Registry policy development and registry operations 134 need to be accountable to the affected community. 136 3. Discussion 138 The principles discussed in Section 2 provide trust and confidence in 139 the IANA registries. 141 3.1. Unique, Stable, and Predictable 143 Protocol identifier assignment and registration must be unique, 144 stable, and predictable. Developers, vendors, customers, and users 145 depend on the registries for unique protocol identifiers that are 146 assigned in a stable and predictable manner. A protocol identifier 147 may only be reassigned for a different purpose after due 148 consideration of the impact of such a reassignment, and if possible, 149 with the consent of the original assignee. 151 3.2. Public Publication 153 Once assigned, the protocol identifiers must be published in a manner 154 that makes them available to everyone. The use of a consistent 155 publication location builds confidence in the registry. This does 156 not mean that the publication location can never change, but it does 157 mean that it must change infrequently and only after adequate prior 158 notice. 160 3.3. Open and Transparent 162 The process that sets the policy for protocol identifier assignment 163 and registration must be open to all interested parties and operate 164 in a transparent manner. 166 For many registries there is a de-facto separation of the policy 167 setting and the evaluation of the policy that takes place at 168 implementation. Splitting those roles can expose instances where 169 policies lack of clarity, which provides helpful feedback to allow 170 those policies to be improved. In addition, this separation 171 prevents the risks of the policy evaluation from being burdened with 172 (perceptions of) favoritism and unfairness. 174 3.4. Accountable 176 The process that sets the policy for protocol identifiers and the 177 operation of the registries must be accountable to the parties that 178 rely on the protocol identifiers. Oversight is needed to ensure 179 these are properly serving the affected community. 181 In practice accountability mechanisms may be defined by contract, 182 memoranda of understanding, or service level agreements (SLAs). An 183 oversight body is held accountable to the wider community by 184 different mechanisms, for instance recall and appeal processes. 186 For protocol parameters [RFC6220], the general oversight over the 187 IANA function is performed by the IAB as a chartered responsibility 188 from [RFC2850] (also see Section 5.4). In addition the IAOC, a body 189 responsible for IETF administrative and financial matters [RFC4071], 190 maintains an SLA with ICANN, thereby specifying the operational 191 requirements with respect to the coordination of evaluation, and the 192 maintenance and publication of the registries. Both the IAB and the 193 IAOC are accountable to the larger Internet community and are being 194 held accountable through the IETF Nomcom process [BCP10]. 196 4. Security Considerations 198 Internet Registries are critical to elements of Internet security. 199 The principles described in this document are necessary for the 200 Internet community to place trust in the IANA registries.. 202 5. Contributors and Acknowledgements 204 This text has been developed within the IAB IANA Evolution Program. 205 The ideas and many text fragments, and corrections came from or were 206 inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, 207 Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve 208 Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, 209 John Klensin, Bertrand de La Chapelle, Danny McPherson, George 210 Michaelson, Thomas Narten, Andrei Robachevsky, and Greg Wood. 211 Further inspiration and input was drawn from various meetings with 212 IETF and other Internet community (RIRs, ISOC, W3C, IETF, and IAB) 213 leadership. 215 It should not be assumed that those acknowledged endorse the 216 resulting text. 218 6. IANA Considderations 220 This document does not contain updates to any registries. 222 7. Informative References 224 [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 225 and Recall Process: Operation of the Nominating and Recall 226 Committees", BCP 10, RFC 3777, June 2004. 228 Dawkins, S., "Nominating Committee Process: Earlier 229 Announcement of Open Positions and Solicitation of 230 Volunteers", BCP 10, RFC 5633, August 2009. 232 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 233 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 234 May 2000. 236 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 237 Understanding Concerning the Technical Work of the 238 Internet Assigned Numbers Authority", RFC 2860, June 2000. 240 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 241 Administrative Support Activity (IASA)", BCP 101, RFC 242 4071, April 2005. 244 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and 245 Internet Architecture Board, "Defining the Role and 246 Function of IETF Protocol Parameter Registry Operators", 247 RFC 6220, April 2011. 249 Authors' Addresses 251 Russ Housley 252 918 Spring Knoll Drive 253 Herndon, VA 20170 254 USA 255 Email: housley@vigilsec.com 257 Olaf Kolkman 258 Science Park 400 259 Amsterdam 1098 XH 260 The Netherlands 261 EMail: kolkman@isoc.org