idnits 2.17.1 draft-kolkman-iana-framework-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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2013) is 3824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC6220' on line 119 -- Looks like a reference, but probably isn't: 'RFC5226' on line 248 -- Looks like a reference, but probably isn't: 'RFC3513' on line 199 == Unused Reference: '1' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 400, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 404, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. '1') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 5226 (ref. '2') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6220 (ref. '3') (Obsoleted by RFC 8722) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman, Ed. 3 Internet-Draft NLnet Labs 4 Intended status: Informational November 04, 2013 5 Expires: May 06, 2014 7 A Framework for the Evolution of IANA 8 draft-kolkman-iana-framework-00 10 Abstract 12 This document provides a framework for describing the management of 13 Internet Registries managed by IANA. It defines terminology 14 describing the various roles and responsibilities associated with 15 management of Internet Registry functions. 17 Status of this Memo 19 This Internet-Draft is submitted 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). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 06, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 1. Introduction 50 1.1. Internet Registries and Interoperability on the Internet 52 Internet registries hold identifiers consisting of constants and 53 other well-known values used by Internet protocols. Such values 54 define a common vocabulary that protocols understand when 55 communicating with each other. For example, the TCP port number of 56 "80" is globally understood to denote "http" service. Almost every 57 protocol in existence makes use of registries in some form. 59 Internet registries are critical to the operation of the Internet. 60 They are needed to record the definitive value and meaning of 61 identifiers that protocols use when communicating with each other. 62 Management of Internet registries must be operated in a predictable, 63 stable and secure manner in order to ensure that protocol identifiers 64 have consistent meanings and interpretations across all 65 implementations and deployments. 67 Protocol identifier values can be numbers, strings, addresses, and so 68 on. They are uniquely assigned for one particular purpose or use. 69 They can be maintained in centrally maintained lists (such as, for 70 instance, lists of cryptographic algorithms in use in a particular 71 protocol) or hierarchically allocated and assigned by separate 72 entities at different points in the hierarchy (such as for IP 73 addresses and domain names). At the time of writing, IANA maintains 74 hundreds of protocol parameter registries. 76 Stable and predictable assignment and registration of protocol 77 identifiers for Internet protocols is of great importance to many 78 stakeholders, including developers, vendors, and customers, as well 79 as users of devices, software, and services on the Internet. These 80 actors use and depend on registries and implicitly trust the registry 81 system to be stable and predictable. The registry system is built on 82 trust and mutual cooperation, not on mandates and policing. 84 Stability and consistency of Internet registries is achieved through 85 the definition of appropriate and clear policies for making additions 86 to or updating existing entries. Such policies must take into 87 account the technical and operational properties of the technology 88 that makes use of the registry. At the same time, it most be 89 possible to evolve the systems and policies for managing registry 90 contents as the Internet itself evolves. 92 1.2. The IANA function and Internet Registries 94 The IETF and its predecessors have traditionally separated the 95 publication mechanism of its protocol specifications, published in 96 immutable RFCs, from the registries containing protocol parameters 97 maintained by the so called Internet Assigned Numbers Authority 98 (IANA). Dating back to the earliest days of the Internet, the 99 specification publication function and the registry maintenance 100 functions were tightly coupled: Jon Postel of ISI, USC was 101 responsible for both the RFC publications and the IANA function. 103 To properly understand Internet Registry management it is important 104 to distinguish between the who and the what. The IANA function is a 105 specific set of responsibilities within the context of Internet 106 Registries (the what); in this document we use the term IANA or IANA 107 functions independent of the entity that implements the function. 108 When we refer to the IANA entity (the who) we will do so explicitly. 109 Also, unless otherwise mentioned, the IANA entity is the entity as is 110 currently operated by ICANN. 112 1.3. An IANA Framework 114 This document provides a framework for describing the management of 115 Internet Registries as they are currently implemented. It defines 116 terminology describing the various roles and responsibilities 117 associated with management of those roles. 119 This document can be read independent of [RFC6220] which documents 120 the IETF's requirements specific to a subset of all current IANA 121 function registries, namely the IETF protocol parameter registries. 122 The framework presented herein is intended to be applicable to all 123 registration functions that are currently considered to be IANA 124 functions in terms generic enough to be applicable for the future. 126 The words must, should, shall, required, may and such should not be 127 interpreted as normative language, but in their plain English 128 meaning. 130 2. Roles in Relation to Internet Registries. 132 In this section we discuss the roles relevant to Internet Registries 133 in terms of an abstract registry that is defined as part of a 134 technical specification. Registry management involves 3 roles. 135 First, a policy development role defines the purpose of the registry 136 and the process and requirements for making additions or updates. 137 Second, an implementation role refers to the the operational process 138 itself for processing change requests to a registry and for 139 publishing its contents. Finally, an oversight role refers to a 140 high-level responsibility for ensuring that the other two roles are 141 operating satisfactorily, stepping in if significant changes are 142 needed in the policies or implementation of a registry. Each of 143 these roles is described in more detail in the following subsections. 145 2.1. The Policy Development Role 147 Description: 149 Registries may need to have additional values added, or an existing 150 entry may need to be clarified or updated in some manner. The policy 151 development role describes who can make updates or additions, what 152 sort of review (if any) is needed, the conditions under which update 153 requests would normally be granted or when they might not, etc. The 154 entity performing this role may transfer its responsibility for part 155 or all of the registry to others which may include the responsibility 156 for defining policies. 158 Key Responsibilities: 160 The policy development role refers to governing policies that define 161 how and when a registry can be updated or modified. 163 Primary Output: 165 A set of policies by which registries can be populated. 167 Example 1: 169 IETF acts in this role when "IANA Considerations" sections specify 170 the creation of a new registry, specify initial entries, and specify 171 a policy for adding additional entries to the registry in the future. 172 For instance, RFC5226 [RFC5226] provides terminology that has proven 173 useful within the IETF for describing common policies for managing 174 its registries. Those terms include "Private Use", "Hierarchical 175 allocation", "First Come First Served", "Expert Review", 176 "Specification Required", "IESG Approval", "IETF Consensus", and 177 "Standards Action". The IETF can uses this, and if needed other 178 policies to define the policy through wich registries are populated. 180 Example 2: 182 The Domain Name System (DNS) protocol is hierarchical and the 183 maintenance of the registries, and publication thereof, has been 184 organized hierarchically. ICANN is currently responsible for change 185 control at the 'root' which includes setting and maintaining policies 186 for that root zone. Change control, policy control, and publication 187 responsibility follows the DNS hierarchy. Although ICANN is 188 responsible for the root zone, it is not responsible for all domains 189 below the root. For example the IETF sets the policy for determining 190 which names are allocated in the ietf.org zone. For ccTLDs the 191 policies are set by the ccTLD registry in coordination with local 192 regulator, and/or other national bodies. 194 Example 3: 196 IP address allocation and its policy development is hierarchical too. 197 For instance, the IETF has defined an IPv6 address range called 198 unicast addresses. For a fraction of that address range ICANN and 199 the NRO have been delegated change control (see [RFC3513] section 4 200 for details). The change control is further delegated to the Regional 201 Internet Registries (RIRs) which, guided by policies set by the 202 regional communities, delegate change control even further e.g., to 203 Local Internet Registries. 205 Not coincidentally, these 3 areas map to how IANA currently organizes 206 its registration responsibilities: Domain Names, Number Resources, 207 and Protocol Assignments. 209 2.2. The Implementation Role 211 The implementation role refers to the actual day-to-day operation of 212 a registry in terms of servicing requests for registry additions or 213 updates and publishing the contents of the registry. The 214 implementation role carries out the policies as defined by the policy 215 development role. The implementation role has two distinct key 216 aspects: Evaluation Coordination, and the maintenance and publication 217 of registry content. We discuss them separately. 219 2.2.1. Implementation Role - Evaluation Coordination 221 Key Responsibility: 223 Coordinate, operate and process the timely evaluation of registration 224 requests based on policies set by the Policy Role. 226 Primary Output: 228 A smoothly functioning system in which requests for registry updates 229 come in, are evaluated and processed in a manner consistent with the 230 policy guidance with the results recorded and published as 231 appropriate. In some cases, the evaluation of requests is a 232 straightforward task requiring little subjective evaluation, whereas 233 in other cases evaluation is more complex and requires subject matter 234 experts as defined by the relevant policy guidance. 236 Relation to other roles and activities: 238 The output of the evaluations is input to the process of assignment, 239 delegation, and/or population of the registries (the other key 240 responsibility for this role). The evaluations are performed based on 241 the policies as defined by the Policy role. The coordination of the 242 evaluation is different from the evaluation of a request itself: The 243 Implementation Role handles the request for allocation or maintenance 244 of a record and may delegate the actual evaluation to a third party. 246 Example 1: 248 As mentioned above, RFC5226 [RFC5226] provides terminology to define 249 common policies used by IETF registries associated with IETF 250 protocols. One of the policies that the Policy Role can impose for 251 allocation from a registry is expert review. In this case a subject 252 matter expert will evaluate the allocation request and determine 253 whether an allocation will be made. 255 An alternative policy for allocation is the requirement for IETF 256 Consensus. This is where the IETF has first, in its Policy 257 Development role, set the policy and then, in its Policy Evaluation 258 role implements it by determining consensus for a particular registry 259 modification. 261 The IANA entity is the entity that, for the IETF, coordinates the 262 evaluation of registration requests against policies as set by the 263 IETF. 265 Example 2: 267 IP address allocation policy is developed bottom-up through the 268 Regional Internet Registry (RIR) communities. The RIR communities 269 perform the Policy Role while at the RIRs the Policy Evaluation Role 270 is performed by the so called IP-Resource Analysts (or similar) that 271 assess allocation requests agains the policies developed in the 272 Region. 274 RIR staff often support the policy development process. 276 [OK: This assumes no policy development by the RIRs themselves, 277 correct? Should this clarification that RIR staff has a supporting 278 role for the development process, be refined?] 280 Example 3: 282 The evaluation of requests for the creation of new gTLDs as performed 283 by ICANN staff and the evaluation of redelegation requests for 284 existing Top Level Domains. 286 2.2.2. Implementation Role - Maintenance and Publication of Registry 287 Content 289 Key Responsibility: 291 The maintenance of the registries content: allocating or assigning 292 parameters after positive evaluation and based on established 293 policies, keeping appropriate record of transaction, and publishing 294 the registries publicly. 296 Primary Output: 298 Easy and convenient access to registry contents, with additions and 299 updates appearing in a timely manner. 301 Note: 303 The maintenance and publication are strictly mechanical functions. 304 In practice the entity that performs those functions will perform 305 some or all of the responsibilities of the Policy Evaluation 306 Coordination. For instance, even verification that an application/ 307 registration request is correct is a Policy Evaluation responsibility 308 that should be explicitly assigned to the entity performing the IANA 309 function by entity that performs the Policy Development Role. 311 Example 1: 313 ICANN publishes the protocol parameters registries on the IANA 314 website. Recently the information the plain-text tables thereon have 315 been augmented with tables in a structured machine-readable format. 316 The coordination of the requirements for publication and the 317 implementation of the technical systems is part of the publication 318 and maintenance responsibility. 320 Example 2: 322 [EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of 323 publication and maintenance] 325 2.3. The Oversight Role 327 Description: 329 The oversight role refers to a high-level responsibility for ensuring 330 that the other two roles are operating satisfactorily, stepping in if 331 significant changes are needed in the policies or implementation of a 332 registry. 334 Key Responsibility: 336 Ensure on a long-term basis that policies and implementation 337 registries are aligned in a way that supports the coherent long-term 338 development and use of shared Internet resources. Coordinate with 339 entities with similar roles for other registries. 341 Example 1: 343 The IAB is responsible for overseeing the policy development (in the 344 context of the IETF, the standards process) and coordinates with the 345 other entities that have the oversight role for Internet Registries. 347 Example 2: 349 The NRO is responsible for overseeing the policy development for 350 global Internet address allocation policies. 352 3. Observations 354 [OK: these observations need refinement and reality checks] 356 3.1. Stable and Predictable implementation of the Internet Registries 357 Function 359 Stable and predictable policy development, allocation, publication 360 are key requirements in any vision about the the Internet Registries 361 function. 363 3.2. Separation of the roles 365 For many registries there is a de-facto separation of the Policy 366 Development and the Evaluation coordination that takes place at 367 implementation. While this has never been an explicit requirement it 368 seems that splitting those roles forces problems with unclarities in 369 policies to surface. Besides, having the policy setting, oversight 370 and evaluation roles separated prevents the evaluation role from 371 being burdened with perceptions of favoritism and unfairness. 373 4. Security Considerations 375 As discussed in Section Section 1.1 Internet Registries and the model 376 discussed in this document are critical to elements of Internet 377 security. However, this document simply discusses that model rather 378 than changing it and consequently does not directly affect the 379 security of the Internet. 381 5. Contributors and Acknowledgemetns 383 This text [is being] developed within the IAB IANA strategy program. 384 The ideas and many, if not most, text fragments came from or were 385 inspired on comments from: Jari Arkko, Marcelo Bagnulo, Leslie 386 Daigle, Russ Housley, John Klensin, Danny McPherson, Thomas Narten, 387 Andrei Robachevsky and various meetings with IETF and other I* 388 leadership. 390 6. IANA Considderations 392 This memo does not contain any specific instruction to any entity in 393 the Implementer Role. 395 7. References 397 [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 398 (IPv6) Addressing Architecture", RFC 3513, April 2003. 400 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an 401 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 402 May 2008. 404 [3] McPherson, D., Kolkman, O., Klensin, J., Huston, 405 G.Internet Architecture Board, "Defining the Role and 406 Function of IETF Protocol Parameter Registry Operators", 407 RFC 6220, April 2011. 409 Appendix A. Document Editing Details 411 [Text between square brackets starting with initials are editor 412 notes. Any other text between square brackets assumes an action by 413 the RFC editor prior to publication as an RFC. In most cases this 414 will be removal, sometimes a stylistic or editorial choices ore 415 question is indicated] [This section and its subsections should be 416 removed at publication as RFC] 418 Appendix A.1. Version Infromation 420 Appendix A.1.1. This version 422 This draft is the result of a set of brainstorms in the IAB IANA 423 program, it does claim to reflect any consensus. 425 Appendix A.1.2. TODO 427 o Possibly add a terminology section with terms like maintenance, 428 coordination, etc further explained. 430 Appendix A.2. Subversion information 432 $Id: draft-kolkman-iana-framework-00.txt 16 2013-11-04 21:16:33Z olaf $ 434 Author's Address 436 Olaf Kolkman, editor 437 Stichting NLnet Labs 438 Science Park 400 439 Amsterdam, 1098 XH 440 The Netherlands 442 Email: olaf@nlnetlabs.nl 443 URI: http://www.nlnetlabs.nl/