idnits 2.17.1 draft-iab-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 03, 2014) is 3764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ADDREF' is mentioned on line 311, but not defined ** Obsolete normative reference: RFC 3777 (ref. 'BCP10') (Obsoleted by RFC 7437) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6220 (Obsoleted by RFC 8722) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board(IAB) IAB 3 Internet-Draft O. Kolkman, Ed. 4 Intended status: Informational NLnet Labs 5 Expires: July 05, 2014 January 03, 2014 7 A Framework for the Evolution of the Internet Assigned Numbers 8 Authority(IANA) 9 draft-iab-iana-framework-00 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 [ InternetGovtech@iab.org is the list which the IAB will be 20 monitoring for the discussion of this draft. See http://www.iab.org/ 21 mailman/listinfo/internetgovtech 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 July 05, 2014. 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 (http://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 1. Introduction 56 1.1. Internet Registries and Interoperability on the Internet 58 Internet registries hold identifiers consisting of constants and 59 other well-known values used by Internet protocols. Such values 60 define a common vocabulary that protocols understand when 61 communicating with each other. For example, the TCP port number of 62 "80" is globally understood to denote "http" service. Almost every 63 protocol in existence makes use of registries in some form. 65 Internet registries are critical to the operation of the Internet. 66 They are needed to record the definitive value and meaning of 67 identifiers that protocols use when communicating with each other. 68 Management of Internet registries must be done in a predictable, 69 stable and secure manner in order to ensure that protocol identifiers 70 have consistent meanings and interpretations across all 71 implementations and deployments. 73 Protocol identifier values can be numbers, strings, addresses, and so 74 on. They are uniquely assigned for one particular purpose or use. 75 They can be maintained in centrally maintained lists (such as, for 76 instance, lists of cryptographic algorithms in use in a particular 77 protocol) or hierarchically allocated and assigned by separate 78 entities at different points in the hierarchy (such as for IP 79 addresses and domain names). At the time of writing, the Internet 80 Assigned Numbers Authority (IANA) maintains over one thousand 81 protocol parameter registries. 83 Stable and predictable assignment and registration of protocol 84 identifiers for Internet protocols is of great importance to many 85 stakeholders, including developers, vendors, and customers, as well 86 as users of devices, software, and services on the Internet. These 87 stakeholders use and depend on registries and implicitly trust the 88 registry system to be stable and predictable. The registry system is 89 built on trust and mutual cooperation; the use of the registries is 90 voluntary and is not enforced by mandates or certification policies. 92 Stability and consistency of Internet registries is achieved through 93 the definition of appropriate and clear policies for making additions 94 to or updating existing entries. Such policies must take into 95 account the technical and operational properties of the technology 96 that makes use of the registries. At the same time, it must be 97 possible to evolve the systems and policies for managing registry 98 contents as the Internet itself evolves. 100 1.2. The IANA function and Internet Registries 101 The Internet Engineering Task Force (IETF) and its predecessors have 102 traditionally separated the publication mechanism of its protocol 103 specifications, published in immutable RFCs, from the registries 104 containing protocol parameters. The latter is maintained by a set of 105 functions traditionally known collectively as the Internet Assigned 106 Numbers Authority (IANA). Dating back to the somewhat before the 107 earliest days of the Internet, the specification publication function 108 and the registry maintenance functions were tightly coupled: Jon 109 Postel of the Information Sciences Institute (ISI) of the University 110 of Southern California (USC) was responsible for both the RFC 111 publications and the IANA function. However, this tight coupling was 112 never a requirement and indeed, today the RFC Editor and IANA 113 function are contracted to different entities. (The RFC publication 114 process and the IANA protocol parameter policy development process 115 and oversight remain closely coupled. For instance,one of the 116 responsibilities of the IAB is oversight over the RFC Series and IANA 117 [RFC2850] ) 119 To properly understand Internet registry management it is important 120 to distinguish between the who, the what, and the how. The Internet 121 or IANA Registries are tables with assignments and allocations of 122 values (the What). These Internet registries are colloquially 123 subdivided into 3 classes: Names, Numbers, and IETF Protocol 124 Parameters. Normally we use the term IANA for the set of functions 125 with specific responsibilities within the context of Internet 126 Registries. In this document we use the term IANA or IANA 127 function(s) independent of the entities that implement those 128 functions (the Who). Currently the maintenance, implementation and 129 publication of most of the IETF protocol Registries is performed by 130 the Internet Corporation for Assigned Names and Numbers (ICANN). 132 1.3. An IANA Framework 134 This document provides a framework for describing the management of 135 Internet Registries as they are currently implemented. It defines 136 terminology describing the various roles and responsibilities 137 associated with those roles. 139 Although this document can be read independent of [RFC6220] and 140 [RFC7020] -- which document the requirements specific to a subset of 141 all current IANA function Internet registries, namely the IETF 142 protocol parameter registries and the Internet Numbers Registry 143 System respectively --, those RFCs provide context and example of the 144 subject matter of this document. The framework presented herein is 145 intended to be applicable to all registration functions that are 146 currently considered to be IANA functions in terms generic enough to 147 be applicable for the future. The examples herein are intended to 148 illustrate the applicability of the framework and are of informative 149 rather than of normative nature. 151 The words must, should, shall, required, may and such should not be 152 interpreted as normative language as defined in [RFC2119], but in 153 their plain English meaning. 155 2. Roles in Relation to Internet Registries 157 In this section we discuss the roles relevant to Internet Registries 158 in terms of an abstract registry that is defined as part of a 159 arbitrary technical specification. Registry management involves 3 160 roles. First, a policy development role that defines the purpose of 161 the registry and the process and requirements for making additions or 162 updates. Second, an implementation role that refers to the 163 operational process for processing change requests to a registry and 164 for publishing its contents. Finally, an oversight role that refers 165 to a high-level responsibility for ensuring that the other two roles 166 are operating satisfactorily and stepping in if significant changes 167 are needed in the policies or implementation of a registry. Each of 168 these roles is described in more detail in the following subsections. 170 2.1. The Policy Development Role 172 Description: 174 Registries may need to have additional values added, or an existing 175 entry may need to be removed, clarified, or updated in some manner. 176 The policy development role creates the registry and defines the 177 policies that describes who can make updates or additions, what sort 178 of review (if any) is needed, the conditions under which update 179 requests would normally be granted or when they might not, the 180 security requirements of these interactions, etc. The entity 181 performing this role may delegate its responsibility for part or all 182 of the registry to others which may include the responsibility for 183 defining policies. 185 Key Responsibilities: 187 The policy development role refers to the creation of the governing 188 policies that define how and when a registry can be updated or 189 modified. 191 Primary Output: 193 A set of policies by which registries can be populated. 195 Not coincidentally, the following 3 examples map to how the IANA 196 registration functions are currently organized: Domain Names, Number 197 Resources, and IETF Protocol Parameter Registries. 199 Example 1: 201 The IETF, through the IESG (see [RFC6220] section 2.3), acts in this 202 role when in the "IANA Considerations" sections of its RFCs it 203 specifies the creation of a new registry, specifies initial entries, 204 and specifies a policy for adding additional entries to the registry 205 in the future. [RFC5226] provides guidance and terminology that has 206 proven useful within the IETF for describing common policies for 207 managing its registries. Those terms include "Private Use", 208 "Hierarchical allocation", "First Come First Served", "Expert 209 Review", "Specification Required", "IESG Approval", "IETF Consensus", 210 and "Standards Action". The IETF uses these and, if needed, other 211 templates to define the policy through which registries are 212 populated. 214 Example 2: 216 The Domain Name System (DNS) protocol allows for hierarchical 217 maintenance of the registries, and publication thereof. ICANN is 218 currently responsible for change control at the root zone which 219 includes setting and maintaining policies for that zone. Change 220 control, policy control, and publication authority follows the DNS 221 hierarchy. Although ICANN is authoritative for the root zone, it is 222 not authoritative for all domains below the root. For example the 223 IETF sets the policy for determining which names are allocated in the 224 ietf.org zone. For country code top-level domains (ccTLD) the 225 policies are set by the ccTLD registry in coordination with local 226 community, local regulator(s), and/or other national bodies. 228 Example 3: 230 IP address allocation and the associated policy development is 231 distributed too. For instance, the IETF has defined an IPv6 address 232 range called unicast addresses. For a fraction of that address range 233 ICANN has been delegated change control (see [RFC3513] section 4 for 234 details and [GlobAddrPol] for examples). The change control is 235 further delegated to the Regional Internet Registries (RIRs) which, 236 guided by policies set by the regional communities, delegate change 237 control even further e.g., to Local Internet Registries. 239 2.2. The Implementation Role 241 The implementation role refers to the actual day-to-day operation of 242 a registry in terms of servicing requests for registry additions or 243 updates and publishing the contents of the registry. The 244 implementation role implements processes that abide by the policies 245 as defined by the policy development role. The implementation role 246 has two distinct key aspects: Evaluation Coordination, and the 247 maintenance and publication of registry content. We discuss these 248 aspects separately. 250 2.2.1. Implementation Role - Evaluation Coordination 252 Key Responsibility: 254 Coordinate, operate, and process the timely evaluation of 255 registration requests based on policies set by the Policy Role. 257 Primary Output: 259 A smoothly functioning system in which requests for registry updates 260 are submitted and are evaluated and processed in a manner consistent 261 with the policy guidance with the results recorded and published as 262 appropriate. In some cases, the evaluation of requests is a 263 straightforward task requiring little subjective evaluation, whereas 264 in other cases evaluation is more complex and requires subject matter 265 experts as defined by the relevant policy guidance. 267 Relation to other roles and activities: 269 The output of the evaluations is input to the process of assignment, 270 delegation, and/or population of the registries (the other key 271 responsibility for this role). The evaluations are performed based on 272 the policies as defined by the Policy role. The coordination of the 273 evaluation is different from the evaluation of a request itself: The 274 Implementation Role handles the request for allocation or maintenance 275 of a record and may, under guidance of or in coordination with the 276 policy role, delegate the actual evaluation to a third party. 278 Example 1: 280 As mentioned above, [RFC5226] provides terminology to define common 281 policies used by IETF registries associated with IETF protocols. One 282 of the policies that the Policy Role can impose for allocation from a 283 registry is "Expert Review". In this case a subject matter expert 284 will evaluate the allocation request and determine whether an 285 allocation will be made. 287 An alternative policy for allocation is the requirement for IETF 288 Consensus. This is where the IETF has first, in its Policy 289 Development role, set the policy and then, in its Policy Evaluation 290 role implements it by determining consensus for a particular registry 291 modification. 293 The IANA functions operator (currently operated by ICANN) is the 294 entity that, for the IETF, coordinates the evaluation of registration 295 requests against policies as set by the IETF. 297 Example 2: 299 IP address allocation policy is developed bottom-up through the 300 Regional Internet Registry (RIR) communities. The RIR communities 301 perform the Policy Role while at the RIRs the Policy Evaluation Role 302 is performed by IP-Resource Analysts (or similar) that assess 303 allocation requests against the policies developed in the Region. 305 RIR staff often support or even initiate the policy development 306 process. 308 Example 3: 310 Generic TLD delegation policy is developed bottom-up through ICANN 311 policy processes. As specified in ICANN's bylaws [ADDREF], the ICANN 312 Board of Trustees (BoT) oversees those process to perform the Policy 313 Role. The Policy Evaluation Role is performed under the 314 responsibility of the ICANN BoT; staff and various panels evaluate 315 applications for new generic top-level domains against the policies 316 developed via the ICANN Policy Development Processes. In addition, 317 ICANN staff often support these policy development processes. 319 2.2.2. Implementation Role - Maintenance and Publication of Registry 320 Content 322 Key Responsibility: 324 The maintenance of the registries content: allocating or assigning 325 parameters after positive evaluation and based on established 326 policies, keeping appropriate record of transactions, and making the 327 registries publicly available. 329 Primary Output: 331 Easy and convenient access to registry contents, with additions and 332 updates appearing in a timely manner. 334 Note: 336 Registry maintenance and publication are strictly mechanical 337 functions. In practice the entity that performs those functions will 338 often perform some or all of the responsibilities of the Policy 339 Evaluation Coordination. For instance, verification that an 340 application/registration request is correct is a Policy Evaluation 341 responsibility that can reasonably be explicitly assigned to the 342 entity performing the IANA function by the entity that performs the 343 Policy Development Role. 345 Example 1: 347 ICANN, as the IANA functions operator, publishes the protocol 348 parameters registries on the IANA website. Recently the plain-text 349 tables on that website have been augmented with tables in a 350 structured machine-readable format. The coordination of the 351 requirements for publication and the implementation of the technical 352 systems is part of the publication and maintenance responsibility. 354 Example 2: 356 [EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of 357 publication and maintenance] 359 2.3. The Oversight Role 361 Description: 363 The oversight role refers to a high-level responsibility for ensuring 364 that the other two roles are operating satisfactorily, stepping in if 365 significant changes are needed in the policies or implementation of a 366 registry. 368 Key Responsibility: 370 Ensure that policies and the implementation of registries are aligned 371 in a way that supports the coherent long-term development and use of 372 shared Internet resources. Coordinate with entities with similar 373 roles for other registries. 375 The oversight role is normally isolated with respect to the actual 376 policy development. That said, it may serve to resolve appeals or 377 ratify developed policies. 379 Example 1: 381 The Internet Architecture Board (IAB) is responsible for overseeing 382 the policy development in the context of the IETF's standards process 383 and coordinates with the other entities that have the oversight role 384 for Internet Registries. 386 Example 2: 388 Collectively, the communities served by the Regional Internet 389 Registries oversee the policy development for global Internet address 390 allocation policies. 392 Example 3: 394 Collectively, the stakeholders involved in the ICANN policy 395 development processes serve to oversee the policy development for 396 generic TLD allocation processes. 398 Other examples of coordination around IETF protocols are coordination 399 with the ITU-T when the ENUM protocol started to use E.164 400 identifiers (telephone numbers)[RFC3245]. Another example is the 401 coordination between the IETF protocol development process and 402 reservations of labels at the top-level of the domain name space with 403 RFC6761 as a recent example. 405 3. Key principles of the IANA framework 407 Any IANA framework should be implementable with the following key 408 principles in mind. 410 Stable and Predictable: Stable and Predictable implementation of the 411 Internet Registries Function is important for establishing global 412 trust. 414 Accountability and transparency: Oversight, implementation, and 415 policy development roles are accountable to the materially 416 concerned parties and the wider community. Not all roles may be 417 directly accountable to the wider community, in practice the 418 oversight role has responsibility for such stewardship. 420 Separation of Roles: The oversight, policy development, and 421 implementation roles should be separate or separable. A clear 422 distinction between the roles enhances the transparency and makes 423 it clearer who is accountable to who. 425 Delegation: It should be possible to delegate any of the roles 426 (policy, implementation, or oversight) for registries or parts 427 thereof. 429 4. Discussion 431 4.1. On Separation of the roles 433 For many registries there is a de-facto separation of the Policy 434 Development and the Evaluation coordination that takes place at 435 implementation. While this has never been an explicit requirement, 436 it seems that splitting those roles can surface a lack of clarity in 437 the policies. In addition, having the policy setting, oversight and 438 evaluation roles separated prevents the evaluation role from being 439 burdened with perceptions of favoritism and unfairness. 441 4.2. On Accountability 443 Any entity performing one of the roles defined in this framework is 444 to be held accountable for its responsibilities. Accountability of 445 each entity needs to be expressed in terms of 'who' and 'how'; to who 446 is the entity accountable and by which mechanisms is the entity being 447 held accountable. 449 In practice accountability mechanisms will be defined by memoranda of 450 understanding or through contractual service level agreements (SLA) 451 between implementing entities and the oversight body while the 452 oversight bodies are being held accountable through community review 453 mechanisms, for instance through recall and appeal processes. 455 For example: For protocol parameters the general oversight over the 456 IANA function is performed by the IAB as a chartered responsibility 457 from [RFC2850]. In addition the IAOC [RFC4071] maintains an SLA with 458 ICANN. Both the IAB and the IAOC are accountable to the larger 459 Internet community and are being held accountable through the IETF 460 Nomcom process [BCP10]. 462 4.3. On Delegation 464 Most, if not all, protocol parameter registries were created by the 465 IETF or its predecessors. Today, most IETF protocols registries are 466 maintained by the IANA at ICANN. However, nothing in this framework 467 prohibits the delegation of the oversight, policy, or maintenance 468 role (or any combination of these) of specific protocol parameter 469 registries to other organizations. In some circumstances, that may 470 be desirable and allow improved registry management for the good of 471 the global Internet community. 473 Examples of IANA registries already delegated delegated in whole or 474 in part include the Domain Name System (DNS) registry [RFC2860] the 475 Internet Protocol (IP) address space registry and the autonomous 476 system (AS) number registry [RFC7020]. 478 Delegation of an IANA registry may be desirable for several reasons, 479 including support for more inclusive registry policy development, 480 distributing registry operations globally, and accommodating public 481 policy considerations in registry management. While delegation of an 482 IANA registry in these situations can improve the registry service 483 received by the global Internet community, it is not guaranteed to do 484 so and hence it is incumbent upon the IAB to have clear guidelines 485 for successful IANA registry delegation. Such guidelines are out of 486 scope for this document. 488 4.4. On the Authority to create Internet Registries 490 As with the IETF and the corresponding IANA Protocol registries, 491 other standards bodies (and other institutions) have long histories 492 of defining and creating registries and the parameters, tables, and 493 other values that make them up. Those normal practices may obviously 494 extend to registries and their contents for use on the Internet. 495 This document does not prescribe how those registries are governed." 497 Within the context of this document the term Internet Registries is 498 used for those the registries that are currently organized as Domain 499 Names, Number Resources, and IETF Protocol Parameter registries. 501 The (wider) IETF has the authority to create new IETF Protocol 502 Parameter registries as described in [RFC6220]. The IETF also has 503 the authority to create registries that pertain to the Domain Name 504 System, but only for specify technical use [RFC6761]. Finally the 505 IETF has the (exclusive) authority to make technical assignment for 506 Number Resources out of the currently reserved address pace 507 [RFC4291]. 509 4.5. On the relation to RFC6220 511 The authors are aware that this framework uses less, slightly 512 different, and more generic terms to describe the various roles than 513 [RFC6220]. [RFC6220] is a document that specifically pertains to the 514 IETF protocol parameter registries. 516 For instance, [RFC6220] section 2.1 "Protocol Parameter Registry 517 Operator Role" describes the full set of responsibilities for the 518 operator(s) of the IETF Protocol Parameter registries. These 519 responsibilities map to the Implementor Role in Section 2.2 above. 520 [RFC6220] also describes the role of the IETF Administrative 521 Oversight Committee (IAOC) and IETF Trust. These bodies have 522 specific responsibilities in the wider IETF and are responsible for 523 contracting and IPR respectively. Within this framework they should 524 be considered part of the 'oversight role'. 526 5. Security Considerations 528 As discussed in Section Section 1.1 Internet Registries and the model 529 discussed in this document are critical to elements of Internet 530 security. However, this document simply discusses that model rather 531 than changing it and consequently does not directly affect the 532 security of the Internet. 534 6. Contributors and Acknowledgemetns 536 This text has been [is being] developed within the IAB IANA strategy 537 program. The ideas and many, if not most, text fragments, and 538 corrections came from or were inspired on comments from: Jari Arkko, 539 Marcelo Bagnulo, Mark Blanchet, David Conrad, John Curran, Leslie 540 Daigle, Russ Housley, John Klensin, Danny McPherson, Thomas Narten, 541 Andrei Robachevsky, Greg Wood, and various meetings with IETF and 542 other Internet community (RIRs, ISOC, W3C, IETF & IAB) leadership. 544 7. IANA Considderations 546 This memo does not contain any specific instruction to any entity in 547 the Implementer Role. 549 8. References 551 [BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 552 and Recall Process: Operation of the Nominating and Recall 553 Committees", BCP 10, RFC 3777, June 2004. 555 Dawkins, S., "Nominating Committee Process: Earlier 556 Announcement of Open Positions and Solicitation of 557 Volunteers", BCP 10, RFC 5633, August 2009. 559 [GlobAddrPol] 560 "Board's Review Procedures for Global Internet Number 561 Resource Policies Forwarded for Ratification by the ASO 562 Address Council in Accordance with the ASO MoU", July 563 2005. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC2850] Internet Architecture Board, and B. Carpenter, "Charter 569 of the Internet Architecture Board (IAB)", BCP 39, RFC 570 2850, May 2000. 572 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 573 Understanding Concerning the Technical Work of the 574 Internet Assigned Numbers Authority", RFC 2860, June 2000. 576 [RFC3245] Klensin, J.IAB, "The History and Context of Telephone 577 Number Mapping (ENUM) Operational Decisions: Informational 578 Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 579 3245, March 2002. 581 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 582 (IPv6) Addressing Architecture", RFC 3513, April 2003. 584 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 585 Administrative Support Activity (IASA)", BCP 101, RFC 586 4071, April 2005. 588 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 589 Architecture", RFC 4291, February 2006. 591 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 592 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 593 May 2008. 595 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, 596 G.Internet Architecture Board, "Defining the Role and 597 Function of IETF Protocol Parameter Registry Operators", 598 RFC 6220, April 2011. 600 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 601 RFC 6761, February 2013. 603 [RFC7020] Housley, R., Curran, J., Huston, G. and D. Conrad, "The 604 Internet Numbers Registry System", RFC 7020, August 2013. 606 Appendix A. Document Editing Details 608 [Text between square brackets starting with initials are editor 609 notes. Any other text between square brackets assumes an action by 610 the RFC editor prior to publication as an RFC. In most cases this 611 will be removal, sometimes a stylistic or editorial choices ore 612 question is indicated] [This section and its subsections should be 613 removed at publication as RFC] 615 Appendix A.1. Version Information 617 Appendix A.1.1. draft-kolkman-iana-framework-00 619 This draft is the result of a set of brainstorms in the IAB IANA 620 program, it does not claim to reflect any consensus. 622 Appendix A.1.2. draft-kolkman-iana-framework-00 -> draft-iab-iana- 623 framework-00 625 Added section "On Accountability" and "On Delegation". 627 Refined some of the phrasing based on a thorough review by David 628 Conrad" 630 Added a reference to [RFC7020] in Section 1.3 and clarified the 631 informative rather than normative nature of the examples. 633 Added section Section 3 and changed the name of section Section 4. 635 Nits and minor edits. 637 Appendix A.1.3. TODO 639 o Possibly add a terminology section with terms like maintenance, 640 coordination, etc further explained. 642 o [RFC EDITOR: BCP10 reference [BCP10] needs to be formatted 643 correctly. The annotation hack used to list multiple RFCs that 644 make up BCP10 does not seem to work.] 646 o Review and potentially add clarifying text on the use of 'Internet 647 Registries' (IP and AS numbers, Domain Names, and IETF Protocol 648 registries). 650 Appendix A.2. Subversion information 652 $Id: draft-iab-iana-framework-00.txt 26 2014-01-03 16:56:37Z olaf $ 654 Authors' Addresses 656 Internet Architecture Board 658 Email: iab@iab.org 659 Olaf Kolkman, editor 660 Stichting NLnet Labs 661 Science Park 400 662 Amsterdam, 1098 XH 663 The Netherlands 665 Email: olaf@nlnetlabs.nl 666 URI: http://www.nlnetlabs.nl/