idnits 2.17.1 draft-iab-iana-framework-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 : ---------------------------------------------------------------------------- ** 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 (March 19, 2014) is 3663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ADDREF' is mentioned on line 606, but not defined -- Obsolete informational reference (is this intentional?): RFC 3777 (ref. 'BCP10') (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board(IAB) IAB 3 Internet-Draft 4 Intended status: Informational O. Kolkman, Ed. 5 Expires: September 20, 2014 NLnet Labs 6 March 19, 2014 8 A Framework for Describing the Internet Assigned Numbers Authority(IANA) 9 draft-iab-iana-framework-02 11 Abstract 13 This document provides a framework for describing the management of 14 Internet registries managed by the Internet Assigned Numbers 15 Authority. It defines terminology describing the various roles and 16 responsibilities associated with management of Internet registry 17 functions. 19 [ Note: This is a work in progress and documents the thoughts 20 developed by the IAB in its IAB iana-evolution program ( http:// 21 www.iab.org/activities/programs/iana-evolution-program/) 22 InternetGovtech@iab.org is the list which the IAB will be monitoring 23 for the discussion of this draft. See http://www.iab.org/mailman/ 24 listinfo/internetgovtech for subscription details. ] 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 20, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Internet Registries and Interoperability on the Internet 3 62 1.2. The IANA function and Internet Registries . . . . . . . . 4 63 1.3. Framework for Internet Registries . . . . . . . . . . . . 5 64 2. Roles in Relation to Internet Registries . . . . . . . . . . 6 65 2.1. The Policy Role . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Evaluation Coordination Role . . . . . . . . . . . . . . 7 67 2.3. Maintenance/Publication Role . . . . . . . . . . . . . . 8 68 2.4. The Oversight Role . . . . . . . . . . . . . . . . . . . 8 69 3. Key principles of the IANA framework . . . . . . . . . . . . 9 70 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. On Separation of the roles . . . . . . . . . . . . . . . 9 72 4.2. On Delegation . . . . . . . . . . . . . . . . . . . . . . 10 73 4.3. Accountability . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. On the Ability to create Internet Registries . . . . . . 11 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Policy Examples . . . . . . . . . . . . . . . . . . . . . 11 77 5.1.1. IETF Protocol Parameter Registries . . . . . . . . . 12 78 5.1.2. Number Resources . . . . . . . . . . . . . . . . . . 12 79 5.1.3. Domain Names . . . . . . . . . . . . . . . . . . . . 12 80 5.2. Evaluation Coordination Role Examples . . . . . . . . . . 13 81 5.2.1. IETF Protocol Parameters . . . . . . . . . . . . . . 13 82 5.2.2. Nubmer Resources . . . . . . . . . . . . . . . . . . 13 83 5.2.3. Domain Names . . . . . . . . . . . . . . . . . . . . 13 84 5.3. Maintenance and Publication of Registry Content . . . . . 13 85 5.3.1. IETF Protocol Parameters . . . . . . . . . . . . . . 14 86 5.3.2. Alternative publication mechanisms . . . . . . . . . 14 87 5.4. Oversight Examples . . . . . . . . . . . . . . . . . . . 14 88 5.4.1. IETF Protocol Parameters . . . . . . . . . . . . . . 14 89 5.4.2. Nubmer Resources . . . . . . . . . . . . . . . . . . 14 90 5.4.3. Coordination - gTLDs vs special domain names . . . . 14 91 5.4.4. Coordination - ccTLD Administration . . . . . . . . . 14 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 7. Contributors and Acknowledgemetns . . . . . . . . . . . . . . 15 94 8. IANA Considderations . . . . . . . . . . . . . . . . . . . . 15 95 9. Informative References . . . . . . . . . . . . . . . . . . . 15 96 Appendix A. Document Editing Details . . . . . . . . . . . . . . 18 97 A.1. Version Information . . . . . . . . . . . . . . . . . . . 18 98 A.1.1. draft-iab-iana-framework-01 -> draft-iab-iana- 99 framework-02 . . . . . . . . . . . . . . . . . . . . 18 100 A.1.2. draft-iab-iana-framework-00 -> draft-iab-iana- 101 framework-01 . . . . . . . . . . . . . . . . . . . . 18 102 A.1.3. draft-kolkman-iana-framework-00 -> draft-iab-iana- 103 framework-00 . . . . . . . . . . . . . . . . . . . . 19 104 A.1.4. draft-kolkman-iana-framework-00 . . . . . . . . . . . 19 105 A.1.5. TODO . . . . . . . . . . . . . . . . . . . . . . . . 19 106 A.2. Subversion information . . . . . . . . . . . . . . . . . 19 108 1. Introduction 110 1.1. Internet Registries and Interoperability on the Internet 112 Internet registries are critical to the operation of the Internet, 113 since they provide a definitive record of the value and meaning of 114 identifiers that protocols use when communicating with each other. 115 Almost every Internet protocol makes use of registries in some form. 116 At the time of writing, the Internet Assigned Numbers Authority 117 (IANA) maintains over one thousand protocol parameter registries. 119 Management of Internet registries must be predictable, stable and 120 secure, in order to ensure that protocol identifiers have consistent 121 meanings and interpretations across all implementations and 122 deployments. For example, TCP port number 80 is globally understood 123 to denote the "http" service. 125 Internet registries hold identifiers consisting of constants and 126 other well-known values used by Internet protocols. These values can 127 be numbers, strings, addresses, etc. They are uniquely assigned for 128 one particular purpose or use. Identifiers can be maintained in 129 within a central list (e.g. a list of cryptographic algorithms for 130 use in a particular protocol) or they can be hierarchically allocated 131 and assigned by separate entities at different points in the 132 hierarchy (such as for IP addresses and domain names). 134 Stable and predictable assignment and registration of protocol 135 identifiers for Internet protocols is of great importance to many 136 stakeholders, including developers, vendors, and customers, as well 137 as users of devices, software, and services on the Internet. These 138 stakeholders use and depend on registries and implicitly trust the 139 registry system to be stable and predictable. The registry system is 140 built on trust and mutual cooperation; the use of the registries is 141 voluntary and is not enforced by mandates or certification policies. 142 While the use of registries is voluntary, it is noted that the 143 success of the Internet (e.g. as an enabler of social and economic 144 development) does create enormous pressure to utilize Internet 145 protocols, and hence the protocol registries and their associated 146 policies should be developed in a transparent manner which is open to 147 all interested parties. 149 Stability and consistency of Internet registries is achieved through 150 the definition of appropriate and clear policies for making additions 151 to or updating existing entries. Such policies must take into 152 account the technical and operational properties of the technology 153 that makes use of the registries. At the same time, it must be 154 possible to evolve the systems and policies for managing registry 155 contents as the Internet itself evolves. This description of 156 responsibilities, entities, and functions within the scope of IANA 157 serves as an aid for a structured approach to the potential evolution 158 of the Internet Registries model. 160 1.2. The IANA function and Internet Registries 162 The Internet Engineering Task Force (IETF) and its predecessors have 163 traditionally separated the publication mechanism of its protocol 164 specifications, published in immutable Request for Comments (RFCs), 165 from the registries containing protocol parameters. The latter is 166 maintained by a set of functions traditionally known collectively as 167 the Internet Assigned Numbers Authority (IANA). Dating back to the 168 somewhat before the earliest days of the Internet, the specification 169 publication function and the registry maintenance functions were 170 tightly coupled: Jon Postel of the Information Sciences Institute 171 (ISI) of the University of Southern California (USC) was responsible 172 for both the RFC publications and the IANA function. However, this 173 tight coupling was never a requirement. Indeed, today the RFC Editor 174 and IANA function are contracted to different entities. (The RFC 175 publication process and the IANA protocol parameter policy 176 development process and oversight remain closely coupled. For 177 example, the Internet Architecture Board (IAB) has oversight 178 responsibilities over the both RFC Series and IANA [RFC2850].) 180 One way to approach Internet Registry Management is to examine the 181 what, why, who and how. Internet Registries are tables with 182 assignments and allocations of values (the 'what'), established by 183 explicit directions contained within RFC documents (the 'why'). The 184 framework described in this document applies to individual 185 registries. These registries are colloquially grouped into 3 186 classes: Names, Numbers, and IETF Protocol Parameters. The framework 187 applies, with some nuance, to all registries, regardless of their 188 class. Within the context of this document the term "Internet 189 registries" is used for those the registries that are currently 190 organized as Domain Names, Number Resources, and IETF Protocol 191 Parameter registries. 193 One of the nuances that come into play is that some protocol 194 parameters within these classes are "general use", and registry 195 values assigned upon request to specific parties in accordance with 196 the registry policy. Such assignments are generally unique in 197 nature, i.e. only one party is associated with each general- purpose 198 registry entry. Coordination (or automation) is necessary to provide 199 uniqueness of assignments in each registry, but it is particularly 200 important in the general purpose registries given the large number of 201 assignments involved. Several of the general purpose registries 202 (DNS, IPv4, IPv6, ASNs) have been delegated to parties which are 203 believed to be reasonably representative of the communities dependent 204 upon those registries (e.g. ccTLD, and Regional Internet Registries). 206 In this framework we identify major four roles: The Policy, The 207 Oversight, the Evaluation Coordination, and Maintenance/Publication 208 Roles (the latter two are both both implementation aspects). The 209 entities that perform each of these roles can be interpreted as 'the 210 who' while the ways in which they carry out their roles determine 211 'the how'. 213 Within the IETF, the term "IANA" is often used to describe functions 214 belonging to the Evaluation Coordination and Maintenance/Publication 215 roles (as described below). In this document we use the term IANA or 216 IANA function(s) independent of the entities that implement those 217 functions (the 'who'). Currently, according to the Memorandum of 218 Understanding[RFC2860], the maintenance, implementation and 219 publication of most of the IETF protocol parameter registries are 220 performed by the Internet Corporation for Assigned Names and Numbers 221 (ICANN). 223 1.3. Framework for Internet Registries 225 This document provides a framework for describing the management of 226 Internet Registries as they are currently implemented. In Section 2 227 it defines terminology describing the various roles and 228 responsibilities associated with those roles. In Section 3 we 229 enumerate a few key principles for the implementation of the 230 framework. In Section 4 we discuss the existing context for these 231 principles and other features of the framework. Finally, in 232 Section 5 we provide a number of examples on how the framework 233 applies today. The examples demonstrate how the framework is applied 234 to the situation today and its utility going forward. 236 This document may be read independent of [RFC6220] and [RFC7020]. 237 Those documents identify the specific requirements for the IETF 238 Protocol Parameter registries and the Internet Numbers Registry 239 System. As such, they provide context and examples for some of the 240 subject matter of this document. Those requirements apply only to 241 those subsets of the current collection of IANA function Internet 242 registries. 244 The authors are aware that this framework uses fewer, slightly 245 different, and more generic terms to describe the various roles than 246 [RFC6220]. [RFC6220] is a document that specifically pertains to the 247 IETF protocol parameter registries. 249 For instance, [RFC6220] section 2.1 "Protocol Parameter Registry 250 Operator Role" describes the full set of responsibilities for the 251 operator(s) of the IETF Protocol Parameter registries. These 252 responsibilities map to the Implementor aspects in Section 2.2 and 253 Section 2.3 below. [RFC6220] also describes the role of the IETF 254 Administrative Oversight Committee (IAOC) and IETF Trust. These 255 bodies have specific responsibilities in the wider IETF and are 256 responsible for contracting and IPR respectively. Within this 257 framework they should be considered part of the 'oversight role'. 259 The words must, should, shall, required, may and such should not be 260 interpreted as normative language as defined in [RFC2119], but in 261 their plain English meaning. 263 2. Roles in Relation to Internet Registries 265 In this section we discuss the roles relevant to Internet Registries 266 in terms of an abstract registry that is defined as part of an 267 arbitrary technical specification. 269 Registry management involves 4 roles. First, a policy development 270 role that defines the purpose of the registry and the process and 271 requirements for making additions or updates. Second, roles that 272 refer to the operational process for processing change requests to a 273 registry and for publishing its contents, both implementation 274 aspects. Finally, an oversight role that refers to a high-level 275 responsibility for ensuring that the other two roles are operating 276 satisfactorily and stepping in if significant changes are needed in 277 the policies or implementation of a registry. Each of these roles is 278 described in more detail in the following subsections. 280 2.1. The Policy Role 282 Description: 284 Registries may need to have additional values added, or an existing 285 entry may need to be removed, clarified, or updated in some manner. 286 The Policy Role creates the registry and defines the policies that 287 describes who can make updates or additions, what sort of review (if 288 any) is needed, the conditions under which update requests would 289 normally be granted or when they might not, the security requirements 290 of these interactions, etc. The entity performing this role may 291 delegate its policy responsibilities for part or all of the 292 parameters within the registry. Consequently, in this document the 293 word "policy" is used to refer to a specific course or principle of 294 action for administration of a technical resource maintained within 295 specific registries. 297 Key Responsibilities: 299 The Policy Role refers to the creation of the governing policies that 300 define how and when a registry can be updated or modified. 302 Primary Output: 304 A set of policies by which registries can be populated. 306 2.2. Evaluation Coordination Role 308 The Evaluation Coordination Role and the Maintenance/Publication Role 309 (below) comprise the actual day-to-day operation of a registry in 310 terms of servicing requests for registry additions or updates and 311 publishing the contents of the registry. These roles implement 312 processes that abide by the policies as defined by the Policy Role. 314 Key Responsibility: 316 Coordinate, operate, and process the timely evaluation of 317 registration requests based on policies set by the Policy Role. 319 Primary Output: 321 A smoothly functioning system in which requests for registry updates 322 are submitted and are evaluated and processed in a manner consistent 323 with the policy guidance with the results recorded and published as 324 appropriate. In some cases, the evaluation of requests is a 325 straightforward task requiring little subjective evaluation, whereas 326 in other cases evaluation is more complex and requires subject matter 327 experts as defined by the relevant policy guidance. 329 Relation to other roles and activities: 331 The output of the evaluations is input to the process of assignment, 332 delegation, and/or population of the registries as performed by the 333 entity in the Maintenance/Publication Role (Section 2.3). The 334 evaluations are performed based on the policies as defined by the 335 Policy Role. The coordination of the evaluation is different from 336 the evaluation of a request itself: the Evaluation Coordination Role 337 handles the request for allocation or maintenance of a record and 338 may, under guidance of and in coordination with the entity fulfilling 339 the Policy Role, delegate the actual evaluation to a third party. 341 2.3. Maintenance/Publication Role 343 Key Responsibility: 345 The maintenance of the registries' content: allocating or assigning 346 parameters after positive evaluation and based on established 347 policies, keeping appropriate record of transactions, and making the 348 registries widely and freely available to the extend possible, to 349 encourage protocol usage in conformance with the specifications. 351 Primary Output: 353 Easy and convenient access to registry contents, with additions and 354 updates appearing in a timely manner. 356 Note: 358 Registry maintenance and publication are strictly mechanical 359 functions. In practice the entity that performs those functions will 360 often perform some or all of the responsibilities of the Evaluation 361 Coordination Role. For instance, verification that an application/ 362 registration request is correct is an Evaluation Coordination 363 responsibility that can reasonably be explicitly assigned to the 364 entity performing the Maintenance/Publication Role by the entity that 365 performs the Policy Development Role while evaluation of technical 366 content is usually delegated to technical experts. 368 2.4. The Oversight Role 370 Description: 372 The oversight role refers to a high-level responsibility for ensuring 373 that the other three roles are operating satisfactorily. Oversight 374 involves stepping in if significant changes are needed in the 375 policies, evaluation coordination, maintenance, or publication of a 376 registry. 378 Key Responsibility: 380 Ensure that policies and the implementation of registries are aligned 381 in a way that supports the coherent long-term development and use of 382 shared Internet resources. Coordinate with entities with similar 383 roles for other registries. 385 The oversight role is normally isolated from policy development. 386 That said, the entity performing the Oversight Role may serve to 387 resolve appeals related to policies or ratify developed policies. 389 3. Key principles of the IANA framework 391 The following key principles underscore the successful functioning of 392 the framework: 394 Separation of Roles: The Policy, Evaluation Coordination, 395 Maintenance/Publication, and Oversight roles should be separate or 396 separable. A clear distinction between the roles enhances the 397 transparency and makes it clearer who is accountable to whom. 399 Delegation: It should be possible to delegate any of the roles for 400 registries or parts thereof. 402 Accountability and transparency: The entities fulfilling the roles 403 are accountable to the materially concerned parties and the wider 404 community. The entities fulfilling the Oversight Role are 405 directly accountable to the wider community, although not all of 406 the entities fulfilling the other roles must be. By implication, 407 the entities fulfilling Oversight Role must maintain the highest 408 possible standards of transparency and be open to input and 409 review. 411 Stable and Predictable: Stable and predictable implementation of the 412 Internet registries function is important for establishing global 413 trust. 415 4. Discussion 417 4.1. On Separation of the roles 419 For many registries there is a de-facto separation of the Policy Role 420 and the Evaluation Coordination Role that takes place at 421 implementation. While this has never been an explicit requirement, 422 it seems that splitting those roles can expose instances where 423 policies lack of clarity, which provides helpful feedback to allow 424 those policies to be improved. In addition, having the Policy, 425 Oversight and the Evaluation Coordination Roles separated prevents 426 the risks of the Evaluation Coordination Role from being burdened 427 with (perceptions of) favoritism and unfairness. 429 4.2. On Delegation 431 Most, if not all, protocol parameter registries were created by the 432 IETF or its predecessors. Today, most IETF protocols paramaters 433 registries are maintained by the IANA at ICANN. However, nothing in 434 this framework prohibits the delegation of the Oversight, Policy, 435 Evaluation Coordination, or Maintenance/Publication role (or any 436 combination of these) of specific protocol parameter registries to 437 other organizations. In some circumstances, that may be desirable 438 and allow improved registry management for the good of the global 439 Internet community. 441 Delegation of an IANA registry may be desirable for several reasons, 442 including support for more inclusive registry policy development, 443 distributing registry operations globally, and accommodating public 444 policy considerations in registry management. While delegation of an 445 IANA registry in these situations can improve the registry service 446 received by the global Internet community, it is not guaranteed to do 447 so and hence it is incumbent upon the IAB to have clear guidelines 448 for successful IANA registry delegation. Such guidelines are out of 449 scope for this document. 451 Examples for registries where the responsibility for developing 452 policy has been delegated in whole or in part include the assignment 453 of domain names and the assignment of Internet Protocol (IP) address 454 blocks (both considered policy issues by [RFC2860]), and the 455 autonomous system (AS) number registry [RFC7020]. [RFC2860] 456 demonstrates that that delegation can be very specifically bounded: 457 "Note that (a) assignments of domain names for technical uses (such 458 as domain names for inverse DNS lookup), (b) assignments of 459 specialised address blocks (such as multicast or anycast blocks), and 460 (c) experimental assignments are not considered to be policy issues 461 [...]". These special-purpose names and addresses are assigned in 462 the same manner as protocol parameters except that coordination is 463 needed during policy setting and actual assignment of the values. 464 The oversight bodies may facilitate the coordination. Also see 465 Policy Examples 2 and 3 in Section 5.1. 467 4.3. Accountability 469 Any entity performing one of the roles defined in this framework is 470 to be held accountable for its responsibilities. Accountability of 471 each entity needs to be expressed in terms of 'who' and 'how'; to who 472 is the entity accountable and by which mechanisms is the entity being 473 held accountable. In other words registry policy development and 474 registry operations need to be "accountable" to the affected 475 community. 477 In practice accountability mechanisms may be defined by memoranda of 478 understanding or through contractual service level agreements (SLA) 479 between implementing entities and the oversight body while the 480 oversight bodies are being held accountable through community review 481 mechanisms, for instance through recall and appeal processes. 483 For example: For protocol parameters the general oversight over the 484 IANA function is performed by the IAB as a chartered responsibility 485 from [RFC2850] (also see Section 5.4). In addition the IAOC, a body 486 responsible for IETF administrational and financial matters, 487 [RFC4071] maintains an SLA with ICANN, thereby specifying the 488 operational requirements with respect to the coordination of 489 evaluation, and the maintenance and publication of the registries. 490 Both the IAB and the IAOC are accountable to the larger Internet 491 community and are being held accountable through the IETF Nomcom 492 process [BCP10]. 494 Accountability mechanisms can vary depending upon the actual 495 distribution of responsibilities (i.e.: how much is separated, how 496 much is delegated). 498 4.4. On the Ability to create Internet Registries 500 As with the IETF and the corresponding IANA Protocol registries, 501 other standards bodies (and other institutions) have long histories 502 of defining and creating registries and the parameters, tables, and 503 other values that make them up. Those normal practices may obviously 504 extend to registries and their contents for use on the Internet. 505 This document does not prescribe how those registries are governed. 507 The (wider) IETF has the authority to create new IETF Protocol 508 Parameter registries as described in [RFC6220]. The IETF also has 509 the authority to create registries that pertain to the Domain Name 510 System, but only for specify technical use [RFC6761]. Finally the 511 IETF has the (exclusive) authority to make technical assignment for 512 Number Resources out of the currently reserved address space 513 ([RFC2860] and [RFC4291]). 515 5. Examples 517 5.1. Policy Examples 519 Not coincidentally, the following 3 examples map to how the IANA 520 registration functions are currently organized: IETF Protocol 521 Parameter Registries, Number Resources and Domain Names. 523 5.1.1. IETF Protocol Parameter Registries 525 The IETF, through the IESG (see [RFC6220] section 2.3), acts in this 526 role when in the "IANA Considerations" sections of its RFCs it 527 specifies the creation of a new registry, specifies initial entries, 528 and specifies a policy for adding additional entries to the registry 529 in the future. [RFC5226] provides guidance and terminology that has 530 proven useful within the IETF for describing common policies for 531 managing its registries. Those terms include "Private Use", 532 "Hierarchical allocation", "First Come First Served", "Expert 533 Review", "Specification Required", "IESG Approval", "IETF Consensus", 534 and "Standards Action". The IETF uses these and, if needed, other 535 templates to define the policy through which registries are 536 populated. 538 5.1.2. Number Resources 540 IP address allocation and the associated policy development is 541 distributed too. For instance, the IETF has defined an IPv6 address 542 range called unicast addresses. For a fraction of that address range 543 ICANN has been delegated change control (see [RFC3513] section 4 for 544 details and [GlobAddrPol] for examples). The change control is 545 further delegated to the Regional Internet Registries (RIRs) which, 546 guided by policies set by the regional communities, delegate change 547 control even further e.g., to Local Internet Registries. 549 5.1.3. Domain Names 551 The Domain Name System (DNS) protocol allows for hierarchical 552 maintenance of the domain name registries, and publication thereof. 553 ICANN is currently responsible for change control at the root zone 554 which includes setting and maintaining policies for that zone. 555 Change control, policy control, and publication authority follows the 556 DNS hierarchy; although ICANN is the authoritative entity in the 557 policy role for the root zone, it is not authoritative for all 558 domains below the root. For example the IETF sets the policy for 559 determining which names are allocated in the ietf.org zone. For 560 country code top-level domains (ccTLD) the policies are set by the 561 ccTLD registry in coordination with local community, local 562 regulator(s), and/or other national bodies. Even the policy for 563 assignment of names within the root is subject to nuances. For 564 instance, ICANN has reserved two letter top-level domains for the use 565 as country and territory code Top Level Domains (ccTLDs). The 566 assignment of two-letter codes themselves (that may consecutively be 567 used as DNS top-level domains) is done by ISO TC46/WG2 and are 568 maintained by the ISO 3166 maintenance agency [ISO.3166.2013]. The 569 selection of the operator of a ccTLD is currently governed by 570 [RFC1591], also see Section 5.4.4. 572 5.2. Evaluation Coordination Role Examples 574 5.2.1. IETF Protocol Parameters 576 As mentioned above, [RFC5226] provides terminology to define common 577 policies used by IETF registries associated with IETF protocols. One 578 of the policies that the Policy Role can impose for allocation from a 579 registry is "Expert Review". In this case a subject matter expert 580 will evaluate the allocation request and determine whether an 581 allocation will be made. 583 An alternative policy for allocation is the requirement for IETF 584 Consensus. This is where the IETF has first, in its Policy Role, 585 sets the policy to use its (policy) process to determine consensus 586 for a particular registry modification. 588 The IANA functions operator (currently operated by ICANN) is the 589 entity that, for the IETF, coordinates the evaluation of registration 590 requests against policies as set by the IETF. 592 5.2.2. Nubmer Resources 594 IP address allocation policy is developed bottom-up through the 595 Regional Internet Registry (RIR) communities. The RIR communities 596 perform the Policy Role while at the RIRs the Policy Evaluation Role 597 is performed by IP-Resource Analysts (or similar) that assess 598 allocation requests against the policies developed in the Region. 600 RIR staff often support or even initiate the policy development 601 process. 603 5.2.3. Domain Names 605 Generic TLD delegation policy is today developed bottom-up through 606 ICANN policy processes. As specified in ICANN's bylaws [ADDREF], the 607 ICANN Board of Trustees (BoT) oversees those process to perform the 608 Policy Role. The Policy Evaluation Role is performed under the 609 responsibility of the ICANN BoT; staff and various panels evaluate 610 applications for new generic top-level domains against the policies 611 developed via the ICANN Policy Development Processes. In addition, 612 ICANN staff often support these policy development processes. 614 5.3. Maintenance and Publication of Registry Content 615 5.3.1. IETF Protocol Parameters 617 ICANN, as the current IANA functions operator, publishes the protocol 618 parameters registries on the IANA website. Recently the plain-text 619 tables on that website have been augmented with tables in a 620 structured machine-readable format. The coordination of the 621 requirements for publication and the implementation of the technical 622 systems is part of the publication and maintenance responsibility. 624 5.3.2. Alternative publication mechanisms 626 [EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of 627 publication and maintenance] 629 5.4. Oversight Examples 631 5.4.1. IETF Protocol Parameters 633 The Internet Architecture Board (IAB) is responsible for overseeing 634 the process used to create Internet Standards and coordinates with 635 the other entities that have the oversight role for Internet 636 Registries. 638 5.4.2. Nubmer Resources 640 Collectively, the communities served by the Regional Internet 641 Registries oversee the policy development for global Internet address 642 allocation policies. 644 5.4.3. Coordination - gTLDs vs special domain names 646 Collectively, the stakeholders involved in the ICANN policy 647 development processes serve to oversee the policy development for 648 generic TLD allocation processes. 650 Other examples of oversight around IETF protocols include the 651 coordination between the IAB and the ITU-T when the ENUM protocol 652 started to use E.164 identifiers (telephone numbers)[RFC3245]. 653 Another example is the facilitation of coordination between the IETF 654 protocol development process and reservations of labels at the top- 655 level of the domain name space with RFC6761 as a recent example. 657 5.4.4. Coordination - ccTLD Administration 659 Some readers might have noticed that in the Policy Example in 660 Section 5.1.3 the policy by which ccTLD operators are selected refers 661 to RFC1591. RFC1591 was specified and published by the IANA, while 662 Internet was still an ARPA project and before ICANN and the IETF 663 existed. The IAB at the time maintained loose oversight of IANA but 664 had a different set of responsibilities. Should an update of RFC1591 665 or a declaration of the historic nature of that document be needed 666 then such action would most likely involve stewardship and 667 coordination by the IAB and ICANN. 669 6. Security Considerations 671 As discussed in Section Section 1.1 Internet Registries and the model 672 discussed in this document are critical to elements of Internet 673 security. However, this document simply discusses that model rather 674 than changing it and consequently does not directly affect the 675 security of the Internet. 677 7. Contributors and Acknowledgemetns 679 This text has been [is being] developed within the IAB IANA evolution 680 program. The ideas and many, if not most, text fragments, and 681 corrections came from or were inspired on comments from: Bernard 682 Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, 683 Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa 684 Cooper, Leslie Daigle, Elise Gerich, Russ Housley, John Klensin, 685 Bertrand de La Chapelle, Danny McPherson, George Michaelson, Thomas 686 Narten, Andrei Robachevsky, and Greg Wood. Further inspiration and 687 input was drawn from various meetings with IETF and other Internet 688 community (RIRs, ISOC, W3C, IETF & IAB) leadership. 690 It should not be assumed that those acknowledged endorse the text. 692 8. IANA Considderations 694 This memo does not contain any specific instruction to any entity in 695 the Implementer Role. 697 9. Informative References 699 [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 700 and Recall Process: Operation of the Nominating and Recall 701 Committees", BCP 10, RFC 3777, June 2004. 703 Dawkins, S., "Nominating Committee Process: Earlier 704 Announcement of Open Positions and Solicitation of 705 Volunteers", BCP 10, RFC 5633, August 2009. 707 [GlobAddrPol] 708 "Board's Review Procedures for Global Internet Number 709 Resource Policies Forwarded for Ratification by the ASO 710 Address Council in Accordance with the ASO MoU", July 711 2005. 713 [ISO.3166.2013] 714 International Organization for Standardization, "Codes for 715 the representation of names of countries and their 716 subdivisions, 3rd edition", ISO Standard 3166, November 717 2013. 719 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 720 RFC 1591, March 1994. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 726 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 727 May 2000. 729 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 730 Understanding Concerning the Technical Work of the 731 Internet Assigned Numbers Authority", RFC 2860, June 2000. 733 [RFC3245] Klensin, J. and IAB, "The History and Context of Telephone 734 Number Mapping (ENUM) Operational Decisions: Informational 735 Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 736 3245, March 2002. 738 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 739 (IPv6) Addressing Architecture", RFC 3513, April 2003. 741 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 742 Administrative Support Activity (IASA)", BCP 101, RFC 743 4071, April 2005. 745 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 746 Architecture", RFC 4291, February 2006. 748 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 749 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 750 May 2008. 752 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and 753 Internet Architecture Board, "Defining the Role and 754 Function of IETF Protocol Parameter Registry Operators", 755 RFC 6220, April 2011. 757 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 758 RFC 6761, February 2013. 760 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 761 Internet Numbers Registry System", RFC 7020, August 2013. 763 Appendix A. Document Editing Details 765 [Text between square brackets starting with initials are editor 766 notes. Any other text between square brackets assumes an action by 767 the RFC editor prior to publication as an RFC. In most cases this 768 will be removal, sometimes a stylistic or editorial choices ore 769 question is indicated] [This section and its subsections should be 770 removed at publication as RFC] 772 A.1. Version Information 774 A.1.1. draft-iab-iana-framework-01 -> draft-iab-iana-framework-02 776 Reordered paragraphs in the Discussion to align them with the 777 order in the Key Principles. Also changed the order because 778 Accountability mechanisms may depend on the kinds of separation 779 and delegation applied. 781 Renamed the section titles for the examples from numbers to more 782 descriptive titles. 784 Significant rewording to improve readability based on feedback by 785 Alissa Cooper. 787 Added the paragraph talking about general use in Section 1.2 based 788 on feedback from John Curran. 790 A.1.2. draft-iab-iana-framework-00 -> draft-iab-iana-framework-01 792 Significantly reordered the document by pulling the examples out 793 of the descriptions of the roles and moving those to section 794 Section 5. 796 Split the "Implementation Role" into two different roles 797 explicitly: Evaluation and Maintenance. Both those roles can be 798 headed under Implementation aspects. 800 Refined text about te "what, who and why" and gave an overview in 801 section Section 1.2 803 Reworded the text in Section 4.2 to highlight that only the name 804 assignment is the policy aspect that has been delegated. 805 Similarly, in section Section 5.1 I tried to illustrate that even 806 within the domain name assignment in the root there are delegated 807 policies by introducing the ISO3166 reference. 809 Added Oversight Example 4 in Section 5.4 as an example of policy 810 that exists for over a few decades and for which an update would 811 need coordination 813 Nits and minor edits. 815 A.1.3. draft-kolkman-iana-framework-00 -> draft-iab-iana-framework-00 817 Added section "On Accountability" and "On Delegation". 819 Refined some of the phrasing based on a thorough review by David 820 Conrad" 822 Added a reference to [RFC7020] in Section 1.3 and clarified the 823 informative rather than normative nature of the examples. 825 Added section Section 3 and changed the name of section Section 4. 827 Nits and minor edits. 829 A.1.4. draft-kolkman-iana-framework-00 831 This draft is the result of a set of brainstorms in the IAB IANA 832 program, it does not claim to reflect any consensus. 834 A.1.5. TODO 836 o [RFC EDITOR: BCP10 reference [BCP10] needs to be formatted 837 correctly. The annotation hack used to list multiple RFCs that 838 make up BCP10 does not seem to work.] 840 A.2. Subversion information 842 $Id: iana-framework.xml 32 2014-03-19 11:17:02Z olaf $ 844 Authors' Addresses 846 Internet Architecture Board 848 EMail: iab@iab.org 849 Olaf Kolkman (editor) 850 Stichting NLnet Labs 851 Science Park 400 852 Amsterdam 1098 XH 853 The Netherlands 855 EMail: olaf@nlnetlabs.nl 856 URI: http://www.nlnetlabs.nl/