idnits 2.17.1 draft-ietf-ianaplan-icg-response-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2014) is 3480 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XXX' is mentioned on line 118, but not defined -- Looks like a reference, but probably isn't: '3' on line 1117 -- Duplicate reference: RFC2860, mentioned in 'RFC2860', was also mentioned in 'MOUSUP'. -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IANAPLAN E. Lear, Ed. 3 Internet-Draft R. Housley, Ed. 4 Intended status: Informational October 16, 2014 5 Expires: April 19, 2015 7 Draft Response to the Internet Coordination Group Request for Proposals 8 on IANA 9 draft-ietf-ianaplan-icg-response-01 11 Abstract 13 This document contains the a draft response to a request for 14 proposals from the IANA Stewardship Transition Coordination Group 15 regarding the protocol parameters registries. It is meant to be 16 included in an aggregate proposal that also includes contributions 17 covering names and addresses that will be submitted from their 18 respective operational communities. The IETF community is invited to 19 comment and propose changes to this document. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 19, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 56 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 60 6. Informative References . . . . . . . . . . . . . . . . . . . 16 61 Appendix A. Changes since -00 . . . . . . . . . . . . . . . . . 18 62 Appendix B. The Charter of the IANA Stewardship Coordination 63 Group (ICG . . . . . . . . . . . . . . . . . . . . . 18 64 Appendix C. IANA Stewardship Transition Coordination Group 65 Request for Proposals . . . . . . . . . . . . . . . 21 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 68 1. IETF Introduction 70 In March of 2014 the U.S. National Telecommunications & Information 71 Administration (NTIA) announced its intent to transition oversight of 72 Internet Assigned Numbers Authority (IANA) functions. In that 73 announcement, NTIA asked the Internet Corporation for Assigned Names 74 and Numbers (ICANN) to establish a process to deliver a proposal for 75 transition. As part of that process, the IANA Stewardship Transition 76 Coordination Group (ICG) was formed. The charter for the ICG can be 77 found in Appendix B. They solicited proposals regarding the 78 respective functions that IANA performs, in order that they may put 79 forth a proposal to the NTIA. The final request for proposal (RFP) 80 can be found in Appendix C. 82 While there are interactions between all of the IANA functions and 83 IETF standards, this document specifically addresses the protocol 84 registries function. Section 1 (this section) contains an 85 introduction that is sourced solely within the IETF. Section 2 86 contains the questionnaire that was written by the ICG and a formal 87 response by the IETF. Because much of this memo is taken from a 88 questionnaire we have quoted questions with ">>> " and we have 89 prefaced answers to questions being asked with "IETF Response:". 90 Note that there are small changes to the content of the questions 91 asked in order to match the RFC format. 93 As if to demonstrate the last point, the following text was included 94 in a footnote in the original propsoal. 96 In this RFP, "IANA" refers to the functions currently specified in 97 the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ 98 iana-functions-purchase-order] as well as any other functions 99 traditionally performed by the IANA functions operator. SAC-067 100 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides 101 one description of the many different meanings of the term "IANA" and 102 may be useful reading in addition to the documents constituting the 103 agreement itself. 105 2. The Formal RFP Response 107 The entire Request for Comments, including introduction, can be found 108 in Appendix C. 110 >>> 111 >>> 0. Proposal Type 112 >>> 113 >>> Identify which category of the IANA functions this 114 >>> submission proposes to address: 115 >>> 117 IETF Response: 118 [XXX] Protocol Parameters 120 This response states the existing practice of the IETF, and also 121 represents the views of the Internet Architecture Board and the IETF. 123 >>> 124 >>> I. Description of Community's Use of IANA Functions 125 >>> 126 >>> This section should list the specific, distinct IANA services 127 >>> or activities your community relies on. For each IANA service 128 >>> or activity on which your community relies, please provide the 129 >>> following: 130 >>> A description of the service or activity. 131 >>> 133 IETF Response: 135 Many IETF protocols make use of commonly defined protocol parameters. 136 These parameters are used by implementers, who are the IETF's primary 137 users of the IETF standards and other documents. To ensure 138 consistent interpretation of these parameter values by independent 139 implementations, and to promote universal interoperability, these 140 IETF protocol specifications define and require globally available 141 registry containing the parameter values and a pointer to 142 documentation of the associated semantic intent. The IETF uses the 143 IANA protocol parameter registries to implement such registries. 145 >>> 146 >>> A description of the customer(s) of the service or activity. 147 >>> 149 IETF Response: 151 The IANA protocol parameter registry operator maintains the protocol 152 parameters registry for the IETF in accordance with all relevant IETF 153 policies, in accordance with the Memorandum of Understanding and 154 assoicated supplemental agreements that include service level 155 agreements (SLAs). 157 The IETF is a global voluntary standards organization whose goal is 158 to make the Internet work better [RFC3595]. IETF standards are 159 published in the RFC series. The IETF is responsible for the key 160 standards that are used on the Internet today, including IP, TCP, 161 DNS, BGP, and HTTP, to name but a few. 163 The IETF operates an open and transparent manner [RFC6852]. The 164 processes that govern the IETF are also published in the RFC series. 165 The Internet Standards Process is documented in [RFC2026]. That 166 document explains not only how standards are developed, but also how 167 disputes about decisions are resolved. RFC 2026 has been amended a 168 number of times, and those amendments are indicated in [RFC-INDEX]. 169 The standards process can be amended in the same manner that 170 standards are approved. That is, someone proposes a change by 171 submitting a temporary document known as an Internet-Draft, the 172 community discusses it, and if rough consensus can be found the 173 change is approved by the Internet Engineering Steering Group (IESG), 174 who also have day-to-day responsibility for declaring IETF consensus 175 on technical decisions, including those that affect IANA. Anyone may 176 propose a change during a Last Call, and anyone may participate in 177 the community discussion. 179 >>> 180 >>> What registries are involved in providing the service or 181 >>> activity. 182 >>> 184 IETF Response: 186 The protocol parameter registries are the product of IETF work. 187 Administration of the protocol parameter registries is the service 188 that is provide to the IETF. 190 >>> 191 >>> A description of any overlaps or interdependencies between your 192 >>> IANA requirements and the functions required by other customer 193 >>> communities 194 >>> 196 IETF Response: 198 In this context, the IETF considers "overlap" to be where there is in 199 some way shared responsibility for a single registry across multiple 200 organizations. This is the case with both names and numbers, as 201 described in the paragraphs below. In all cases, the IETF engages 202 directly with the appropriate organizations to ensure that each 203 organization's policies are followed. 205 It is important to note that the IETF includes anyone who wishes to 206 participate, including anyone from ICANN or the regional Internet 207 registries (RIRs), and many people from those organizations regularly 208 do. 210 o The IETF has specified a number of special use registries with 211 regard to domain names. These registries require coordination 212 with the Generic Names Support Organization (GNSO). We already 213 perform this coordination.[RFC6761] 215 o The IETF specifies the DNS protocol. From time to time there have 216 been and will be updates to that protocol. We will continue to 217 coordinate with ICANN regarding those changes. 219 o The IETF specifies minimum requirements for root servers. Should 220 those requirements change, we will inform ICANN. 222 o The routing architecture has evolved over time, and is expected to 223 continue to do so. Such evolution may have an impact on 224 appropriate IP address allocation strategies. As and when that 225 happens, we will consult with the RIR community, as we have done 226 in the past. 228 o The IETF has established registries with IANA for special IPv4 and 229 IPv6 assignments. These are specified in [RFC6890]. The IETF 230 coordinates such assignments with the RIRs. 232 o IETF standards changes may have impact on operations of RIRs and 233 service providers. A recent example is the expansion of the BGP 234 community field from 16 to 32 bits.[RFC6793] It is important to 235 note that this change occurred out of operational necessity, and 236 it demonstrated strong alignment between the RIRs and the IETF. 238 >>> II. Existing, Pre-Transition Arrangements 240 >>> 241 >>> This section should describe how existing IANA-related 242 >>> arrangements work, prior to the transition. 243 >>> 244 >>> A. Policy Sources 245 >>> 246 >>> 247 >>> This section should identify the specific source(s) of policy 248 >>> which must be followed by the IANA functions operator in its 249 >>> conduct of the services or activities described above. If there 250 >>> are distinct sources of policy or policy development for 251 >>> different IANA activities, then please describe these 252 >>> separately. For each source of policy or policy development, 253 >>> please provide the following: 254 >>> 255 >>> Which IANA service or activity (identified in Section I) is 256 >>> affected. 257 >>> 259 IETF Response: The protocol parameters registry. 261 >>> 262 >>> A description of how policy is developed and established and 263 >>> who is involved in policy development and establishment. 264 >>> 266 IETF Response: 268 Policy for overall management of the registries is stated in RFCs in 269 [RFC6220] and [RFC5226]. The first of these documents explains the 270 model for how the registries are to be operated, how policy is set, 271 and how oversight takes place. RFC 5226 specifies the policies that 272 specification writers may employ when they define new protocol 273 registries in the "IANA Considerations" section of each 274 specification. All policies at the IETF begin with a proposal in the 275 form of an Internet-Draft. Anyone may submit such a proposal. If 276 there is sufficient interest, the Internet Engineering Steering Group 277 may choose to create a working group or an Area Director may choose 278 to sponsor the draft. In either case, anyone may comment on the 279 proposal as it progresses. A proposal cannot be passed by the IESG 280 unless it enjoys sufficient community support as to indicate rough 281 consensus [RFC7282] In each case, a "Last Call" is made so that 282 there is notice of any proposed change to a policy or process. 283 Anyone may comment during a Last Call. 285 >>> 286 >>> A description of how disputes about policy are resolved. 287 >>> 289 IETF Response: 291 Most disputes are handled at the lowest level through the working 292 group and rough consensus processes. Should anyone disagree with any 293 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 294 resolution and appeals process that includes the responsible Area 295 Director, the IESG, and the IAB. Should appeals be upheld, an 296 appropriate remedy is applied. In the case where an someone claims 297 that the procedures themselves are insufficient or inadequate in some 298 way to address a circumstance, one may appeal an IAB decision to the 299 Internet Society Board of Trustees. 301 >>> 302 >>> References to documentation of policy development and dispute 303 >>> resolution processes. 304 >>> 306 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 307 conflict resolution and appeals process. [RFC2418] specifies working 308 group procedures. Note that both of these documents have been 309 amended in later RFCs as indicated in the [RFC-INDEX]. Please also 310 see the references at the bottom of this document. 312 >>> 313 >>> B. Oversight and Accountability 314 >>> 315 >>> This section should describe all the ways in which oversight is 316 >>> conducted over IANA functions operator's provision of the 317 >>> services and activities listed in Section I and all the ways in 318 >>> which IANA functions operator is currently held accountab le for 319 >>> the provision of those services. For each oversight or 320 >>> accountability mechanism, please provide as many of the 321 >>> following as are applicable: 322 >>> 323 >>> Which IANA service or activity (identified in Section I) is 324 >>> affected. 325 >>> 327 IETF Response: the protocol parameters registries. 329 >>> 330 >>> If not all policy sources identified in Section II.A are 331 >>> affected, identify which ones are affected. 332 >>> 334 IETF Response: all policy sources relating to the protocol parameters 335 registry have been specified in II.A. 337 >>> 338 >>> A description of the entity or entities that provide oversight 339 >>> or perform accountability functions, including how individuals 340 >>> are selected or removed from participation in those entities. 341 >>> 343 IETF Response: 345 The Internet Architecture Board (IAB) is an oversight body of the 346 IETF whose responsibilities include, among other things, confirming 347 appointment of IESG members, managing appeals as discussed above, 348 management of certain domains, including .ARPA [RFC3172], and general 349 architectural guidance to the broader community. The IAB must 350 approve the appointment of an organization to act as IANA on behalf 351 of the IETF. The IAB is also responsible for establishing liaison 352 relationships with other orgnaizations on behalf of the IETF. The 353 IAB's charter is to be found in [RFC2850]. 355 The IAB members are selected and may be recalled through a Nominating 356 Committee (NOMCOM) process, which is described in [RFC3777]. This 357 process provides for selection of active members of the community who 358 themselves agree upon a slate of candidates. Those candidates are 359 sent to the Internet Society Board of Trustees for confirmation. In 360 general, members serve for two years. The IAB selects its own chair. 362 The IAB provides oversight of the protocol parameter registries of 363 the IETF, and is responsible for selecting appropriate operator(s) 364 and related per-registry arrangements. Especially when relationships 365 among protocols call for it, many registries are operated by, or in 366 conjunction with, other bodies. Unless the IAB or IETF has concluded 367 that special treatment is needed, the operator for registries is 368 currently ICANN. 370 >>> 371 >>> A description of the mechanism (e.g., contract, reporting 372 >>> scheme, auditing scheme, etc.). This should include a 373 >>> description of the consequences of the IANA functions operator 374 >>> not meeting the standards established by the mechanism, the 375 >>> extent to which the output of the mechanism is transparent and 376 >>> the terms under which the mechanism may change. 377 >>> 379 IETF Response: 381 A memorandum of understanding (MoU) between ICANN and the IETF 382 community has been in place since 2000. It can be found in 383 [RFC2860]. The MoU defines the work to be carried out by the IANA 384 staff for the IETF and the Internet Research Task Force (IRTF), a 385 peer organization to the IETF that focuses on research. Each year a 386 service level agreement is negotiated that supplements the MoU. 388 Day-to-day administration and contract management is the 389 responsibility of the IETF Administrative Director (IAD). The IETF 390 Administrative Oversight Committee (IAOC) oversees the IAD. IAOC 391 members are appointed by the Internet Society Board of Trustees, the 392 IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN 393 to establish annual IANA performance metrics and operational 394 procedures, and the resulting document is adopted as an supplement to 395 the MoU each year [MOUSUP]. 397 To date there have been no unresolvable disputes or issues. In the 398 unlikely event that a more difficult situation should arise, the IAOC 399 and the IAB would engage ICANN management to address the matter. The 400 MoU also provides an option for either party to terminate the 401 arrangement with six months notice. Obviously such action would only 402 be undertaken after serious consideration. 404 >>> 405 >>> Jurisdiction(s) in which the mechanism applies and the legal 406 >>> basis on which the mechanism rests. 407 >>> 409 IETF Response 411 This mechanism is global in nature. The current agreement does not 412 specify a jurisdiction. 414 >>>III. Proposed Post-Transition Oversight and Accountability 415 Arrangements 416 >>> 417 >>> This section should describe what changes your community is 418 >>> proposing to the arrangements listed in Section II.B in light of 419 >>> the transition. If your community is proposing to replace one or 420 >>> more existing arrangements with new arrangements, that 421 >>> replacement should be explained and all of the elements listed 422 >>> in Section II.B should be described for the new 423 >>> arrangements. Your community should provide its rationale and 424 >>> justification for the new arrangements. 425 >>> 426 >>> If your community's proposal carries any implications for 427 >>> existing policy arrangements described in Section II.A, those 428 >>> implications should be described here. 429 >>> 430 >>> If your community is not proposing changes to arrangements 431 >>> listed in Section II.B, the rationale and justification for that 432 >>> choice should be provided here. 433 >>> 435 IETF Response: 437 No changes are required, as over the years since the creation of 438 ICANN, the IETF, ICANN, and IAB have together created a system of 439 agreements, policies, and oversight mechanisms that covers what is 440 needed. 442 First and foremost, IANA protocol parameter registry updates will 443 continue to function day-to-day, as they have been doing for the last 444 decade or more. The IETF community is quite satisfied with the 445 current arrangement with ICANN. RFC 2860 remains in force and has 446 served the IETF community very well. RFC 6220 has laid out an 447 appropriate service description and requirements. 449 To address issues raised by the IETF community relating to 450 intellectual property rights; the IAOC is asked to engage the 451 appropriate parties, both inside and outside the IETF, to make clear 452 that data in the protocol parameters registries is in the public 453 domain. 455 To address a desire by some members of the IETF community to have 456 mechanisms that allow for additional dispute resolution between the 457 IETF and the current IANA protocol registries operator, the IAOC is 458 asked to conclude a supplemental agreement regarding jurisdiction and 459 any necessary dispute resolution mechanisms that are mutually 460 acceptable to the parties. 462 To address concerns regarding appropriate contingencies to transition 463 to another operator, IAOC is asked to conclude a supplemental 464 agreement that- 466 1. captures provisions C.7.3 and I.61 of the current IANA functions 467 contract between ICANN and the NTIA [NTIA-Contract]; and 469 2. requires the transfer of any associated marks and identifiers to 470 a subsequent operator. 472 Discussions during IETF 89 in London led to the following guiding 473 principles for IAB efforts that impact IANA protocol parameter 474 registries. These principles must be taken together; their order is 475 not significant. 477 1. The IETF protocol parameter registry function has been and 478 continues to be capably provided by the Internet technical community. 480 The strength and stability of the function and its foundation within 481 the Internet technical community are both important given how 482 critical protocol parameters are to the proper functioning of IETF 483 protocols. 485 We think the structures that sustain the protocol parameter registry 486 function needs to be strong enough that they can be offered 487 independently by the Internet technical community, without the need 488 for backing from external parties. And we believe we largely are 489 there already, although the system can be strengthened further, and 490 continuous improvements are being made. 492 2. The protocol parameter registry function requires openness, 493 transparency, and accountability. 495 Existing documentation of how the function is administered and 496 overseen is good [RFC2860], [RFC6220]. Further articulation and 497 clarity may be beneficial. It is important that the whole Internet 498 community can understand how the function works, and that the 499 processes for registering parameters and holding those who oversee 500 the protocol parameter function accountable for following those 501 processes are understood by all interested parties. We are committed 502 to making improvements here if necessary. 504 3. Any contemplated changes to the protocol parameter registry 505 function should respect existing Internet community agreements. 507 The protocol parameter registry is working well. The existing 508 Memorandum of Understanding in RFC 2860 defines "the technical work 509 to be carried out by the Internet Assigned Numbers Authority on 510 behalf of the Internet Engineering Task Force and the Internet 511 Research Task Force." Any modifications to the protocol parameter 512 registry function should be made using the IETF process to update RFC 513 6220 and other relevant RFCs. Put quite simply: evolution, not 514 revolution. 516 4. The Internet architecture requires and receives capable service 517 by Internet registries. 519 The stability of the Internet depends on capable provision of not 520 just IETF protocol parameters, but IP numbers, domain names, and 521 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 522 protocols. Thus we expect the role of the IETF in standards 523 development, architectural guidance, and allocation of certain name/ 524 number parameters to continue. IP multicast addresses and special- 525 use DNS names are two examples where close coordination is needed. 526 The IETF will continue to coordinate with ICANN, the RIRs, and other 527 parties that are mutually invested in the continued smooth operation 528 of the Internet registries. We fully understand the need to work 529 together. 531 5. The IETF will continue management of the protocol parameter 532 registry function as an integral component of the IETF standards 533 process and the use of resulting protocols. 535 RFC 6220 specifies the role and function of the protocol parameters 536 registry, which is critical to IETF standards processes and IETF 537 protocols. The IAB, on behalf of the IETF, has the responsibility to 538 define and manage the relationship with the protocol registry 539 operator role. This responsibility includes the selection and 540 management of the protocol parameter registry operator, as well as 541 management of the parameter registration process and the guidelines 542 for parameter allocation. 544 6. The protocol parameters registries are provided as a public 545 service. 547 Directions for the creation of protocol parameter registries and the 548 policies for subsequent additions and updates are specified in RFCs. 549 The protocol parameters registries are available to everyone, and 550 they are published in a form that allows their contents to be 551 included in other works without further permission. These works 552 include, but are not limited to, implementations of Internet 553 protocols and their associated documentation. 555 These principles will guide the IAB, IAOC, and the rest of the IETF 556 community as they work with ICANN to establish future IANA 557 performance metrics and operational procedures. 559 >>> IV Transition Implications 561 >>> 562 >>> This section should describe what your community views as the 563 >>> implications of the changes it proposed in Section III. These 564 >>> implications may include some or all of the following, or other 565 >>> implications specific to your community: 566 >>> 567 >>> o Description of operational requirements to achieve continuity 568 >>> of service and possible new service integration throughout 569 >>> the transition. 570 >>> o Risks to operational continuity 571 >>> o Description of any legal framework requirements in the 572 >>> absence of the NTIA contract 573 >>> o Description of how you have tested or evaluated the 574 >>> workability of any new technical or operational methods 575 >>> proposed in this document and how they compare to established 576 >>> arrangements. 577 >>> 579 IETF Response: 581 No structural changes are required. The principles listed above will 582 guide IAB, IAOC, and the rest of the IETF community as they work with 583 ICANN to establish future IANA performance metrics and operational 584 procedures, as they have in the past. 586 As no services are expected to change, no continuity issuees are 587 anticipated, and there are no new technical or operational methods 588 proposed by the IETF to test. The IETF leadership, ICANN, and the 589 RIRs maintain an ongoing informal dialog to spot any unforeseen 590 issues that might arise as a result of other changes. 592 What is necessary as part of transition is the completion of 593 supplemental agreement(s) discussed in the previous section of this 594 RFP. 596 >>> 597 >>> V. NTIA Requirements 598 >>> 599 >>> Additionally, NTIA has established that the transition proposal 600 >>> must meet the following five requirements: 601 >>> 602 >>> "Support and enhance the multistakeholder model;" 603 >>> 604 IETF Response: 606 Everyone is welcome to participate in IETF activities. The policies 607 and procedures are outlined in the documents we named above. In- 608 person attendance is not required for participation, and many people 609 participate in email discussions that have never attended an IETF 610 meeting. An email account is the only requirement to participate. 611 The IETF makes use of both formal and informal lines of communication 612 to collaborate with other organizations within the multistakeholder 613 ecosystem. 615 >>> 616 >>> "Maintain the security, stability, and resiliency of the 617 >>> Internet DNS;" 618 >>> 620 IETF Response: 622 The DNS relies on some of the IETF protocol parameters registries. 623 As the current IANA functions operator, ICANN performs its task very 624 well, usually exceeding the service level agreement metrics.[METRICS] 625 Security, stability, and resiliency of the Internet DNS is best 626 protected by maintaining the current service in its current form. 628 >>> 629 >>> "Meet the needs and expectation of the global customers and 630 >>> partners of the IANA services;" 631 >>> 633 IETF Response: 635 Implementers and their users from around the world make use of the 636 IETF standards and the associated IANA protocol parameter registries. 637 The current IANA protocol parameter registry system is meeting the 638 needs of these global customers. This proposal continues to meet 639 their needs by maintaining the existing processes that have served 640 them well in the past. 642 >>> 644 >>> 645 >>> "Maintain the openness of the Internet." 646 >>> 648 IETF Response: 650 This proposal maintains the existing open framework that allows 651 anyone to participate in the development of IETF standards, including 652 the IANA protocol parameter registry policies. Further, an 653 implementer anywhere in the world has full access to the protocol 654 specification published in the RFC series and the protocol parameter 655 registries published at iana.org. Those who require assignments in 656 the IANA protocol registries will continue to be able to do so, as 657 specified by the existing policies for those registries. 659 {We will have an open discussion, make changes based on that 660 discussion, and then conduct a Last Call to confirm that there is 661 rough consensus for the proposal.} 663 >>> 664 >>> VI. Community Process 665 >>> 666 >>> This section should describe the process your community used for 667 >>> developing this proposal, including: 668 >>> 669 >>> o The steps that were taken to develop the proposal and to 670 >>> determine consensus. 671 >>> 673 IETF Response: 675 The IESG established the IANAPLAN working group to develop this 676 response. Anyone was welcome to join the discussion and participate 677 in the development of this response. An open mailing list 678 (ianaplan@ietf.org) was associated with the working group. In 679 addition, IETF's IANA practices have been discussed in the broader 680 community, and all input is welcome. 682 >>> 683 >>> Links to announcements, agendas, mailing lists, consultations and 684 >>> meeting proceedings. 685 >>> 687 IETF Response: [xxx to be completed in more detail] 689 The following list is not exhaustive, as there have been many open 690 discussions about this transition within the IETF community in the 691 past few months. 693 Creation of an open mailing list to discuss the transition: http://w 694 ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html 696 Announcement of a public session on the transition: http:// 697 www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html 699 Announcement by the IESG of the intent to form a working group: 700 http://www.ietf.org/mail-archive/web/ietf-announce/current/ 701 msg13170.html 703 >>> 704 >>> An assessment of the level of consensus behind your community's 705 >>> proposal, including a description of areas of contention or 706 >>> disagreement. 707 >>> 709 IETF Response: To be completed as the process progresses. 711 3. IANA Considerations 713 This memo is a response a request for proposals. No parameter 714 allocations or changes are sought. 716 4. Security Considerations 718 While the IANA framework has shown strong resiliency, the IETF will 719 continue to work with all relevant parties to facilitate improvements 720 in our standards. 722 5. Acknowledgments 724 This document does not define new processes, and so it seems we 725 acknowledge all of the preceding IAB members and members of the 726 community who developed the processes that we describe. The initial 727 version of this document was developed collaboratively through both 728 the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular 729 thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew 730 Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, Greg Wood, 731 John Curran, and Milton Mueller. 733 6. Informative References 735 [METRICS] , "Performance Standards Metrics Report", , 736 . 738 [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of 739 Understanding between the IETF and ICANN)", , 740 . 742 [NTIA-Contract] 743 , "The NTIA Contract with ICANN", , . 747 [RFC-INDEX] 748 RFC Editor, , "Index of all Requests for Comments", RFC 749 Index, August 2014. 751 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 752 3", BCP 9, RFC 2026, October 1996. 754 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 755 Procedures", BCP 25, RFC 2418, September 1998. 757 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 758 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 759 May 2000. 761 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 762 Understanding Concerning the Technical Work of the 763 Internet Assigned Numbers Authority", RFC 2860, June 2000. 765 [RFC3172] Huston, G., "Management Guidelines & Operational 766 Requirements for the Address and Routing Parameter Area 767 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 769 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 770 3595, September 2003. 772 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 773 Recall Process: Operation of the Nominating and Recall 774 Committees", BCP 10, RFC 3777, June 2004. 776 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 777 Administrative Support Activity (IASA)", BCP 101, RFC 778 4071, April 2005. 780 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 781 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 782 May 2008. 784 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., 785 Internet Architecture Board, "Defining the Role and 786 Function of IETF Protocol Parameter Registry Operators", 787 RFC 6220, April 2011. 789 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 790 RFC 6761, February 2013. 792 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 793 Autonomous System (AS) Number Space", RFC 6793, December 794 2012. 796 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. 797 Amour, "Affirmation of the Modern Paradigm for Standards", 798 RFC 6852, January 2013. 800 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 801 "Special-Purpose IP Address Registries", BCP 153, RFC 802 6890, April 2013. 804 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 805 7282, June 2014. 807 Appendix A. Changes since -00 809 NOTE: This section to be removed by RFC Editor at publication. 811 o Front matter greatly reduced. 813 o Appendices with charter and RFP added. 815 o Jurisdiction text changed. 817 o Proposed changes include supplemental agreement(s) to address 818 jurisdiction, dispute resolution, and IPR, including names and 819 marks. 821 o Transition implications slightly modified to reference 822 supplemental agreement. 824 Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG 826 Charter for the IANA Stewardship Transition Coordination Group V.10 828 (August 27, 2014) 830 The IANA stewardship transition coordination group (ICG) has one 831 deliverable: a proposal to the U.S. Commerce Department National 832 Telecommunications and Information Administration (NTIA) regarding 833 the transition of NTIA's stewardship of the IANA functions to the 834 global multi-stakeholder community. The group will conduct itself 835 transparently, consult with a broad range of stakeholders, and ensure 836 that its proposals support the security and stability of the IANA 837 functions. 839 The group's mission is to coordinate the development of a proposal 840 among the communities affected by the IANA functions. The IANA 841 functions are divided into three main categories: domain names, 842 number resources, and other protocol parameters. The domain names 843 category falls further into the country code and generic domain name 844 sub-categories. While there is some overlap among all of these 845 categories, each poses distinct organizational, operational and 846 technical issues, and each tends to have distinct communities of 847 interest and expertise. For those reasons it is best to have work on 848 the three categories of IANA parameters proceed autonomously in 849 parallel and be based in the respective communities. 851 The IANA stewardship transition process is taking place alongside a 852 parallel and related process on enhancing ICANN accountability. 853 While maintaining the accountability of Internet identifier 854 governance is central to both processes, this group's scope is 855 focused on the arrangements required for the continuance of IANA 856 functions in an accountable and widely accepted manner after the 857 expiry of the NTIA-ICANN contract. Nevertheless, the two processes 858 are interrelated and interdependent and should appropriately 859 coordinate their work. 861 The coordination group has four main tasks: 862 (i) Act as liaison to all interested parties, including the three 863 "operational communities" (i.e., those with direct operational 864 or service relationship with IANA; namely names, numbers, 865 protocol parameters). This task consists of: 866 a. Soliciting proposals from the operational communities 867 b. Soliciting the input of the broad group of communities 868 affected by the IANA functions 869 (ii) Assess the outputs of the three operational communities for 870 compatibility and interoperability 871 (iii) Assemble a complete proposal for the transition 872 (iv) Information sharing and public communication 873 Describing each in more detail: 874 (i) Liaison 875 a. Solicit proposals 877 The ICG expects a plan from the country code and generic name 878 communities (possibly a joint one), a plan from the numbers 879 community, and a plan from the protocol parameters community. 880 Members of the ICG will ensure that the communities from which they 881 are drawn are working on their part of the transition plans. This 882 involves informing them of requirements and schedules, tracking 883 progress, and highlighting the results or remaining issues. The role 884 of a coordination group member during this phase is to provide status 885 updates about the progress of his or her community in developing 886 their component, and to coordinate which community will develop a 887 transition proposal for each area of overlap (e.g., special-use 888 registry). 890 While working on the development of their proposals, the operational 891 communities are expected to address common requirements and issues 892 relating to the transition, in as far as they affect their parts of 893 the stewardship of IANA functions. 895 b. Solicit broader input 897 The ICG is open for input and feedback from all interested parties. 898 While no set of formal requirements related to a transition proposal 899 will be requested outside the operational communities, everyone's 900 input is welcome across all topics. 902 The ICG expects that all interested parties get involved as early as 903 possible in the relevant community processes. Input received 904 directly by the ICG may be referred to the relevant community 905 discussion. 907 The ICG members chosen from a particular community are the official 908 communication channel between the ICG and that community. 910 (ii) Assessment 912 When the group receives output from the communities it will discuss 913 and assess their compatibility and interoperability with the 914 proposals of the other communities. Each proposal should be 915 submitted with a clear record of how consensus has been reached for 916 the proposal in the community, and provide an analysis that shows the 917 proposal is in practice workable. The ICG should also compile the 918 input it has received beyond the operational communities, and review 919 the impacts of this input. 921 The ICG might at some point detect problems with the component 922 proposals. At that point the role of the ICG is to communicate that 923 back to the relevant communities so that they (the relevant 924 communities) can address the issues. It is not in the role of the 925 ICG to develop proposals or to select from among competing proposals. 927 (iii) Assembling and submitting a complete proposal 929 The assembly effort involves taking the proposals for the different 930 components and verifying that the whole fulfills the intended scope, 931 meets the intended criteria, that there are no missing parts, and 932 that the whole fits together. The whole also needs to include 933 sufficient independent accountability mechanisms for running the IANA 934 function. The ICG will then develop a draft final proposal that 935 achieves rough consensus within the ICG itself. The ICG will then 936 put this proposal up for public comment involving a reasonable period 937 of time for reviewing the draft proposal, analyzing and preparing 938 supportive or critical comments. The ICG will then review these 939 comments and determine whether modifications are required. If no 940 modifications are needed, and the coordination group agrees, the 941 proposal will be submitted to NTIA. 943 If changes are required to fix problems or to achieve broader 944 support, the ICG will work with the operational communities in a 945 manner similar to what was described in task (ii) above. Updates are 946 subject to the same verification, review, and consensus processes as 947 the initial proposals. If, in the ICG's opinion, broad public 948 support for the proposal as articulated by the NTIA is not present, 949 the parts of the proposal that are not supported return to the 950 liaison phase. 952 (iv) Information sharing 954 The ICG serves as a central clearinghouse for public information 955 about the IANA stewardship transition process. Its secretariat 956 maintains an independent, publicly accessible and open website, under 957 its own domain, where status updates, meetings and notices are 958 announced, proposals are stored, the ICG members are listed, etc. As 959 the development of the transition plans will take some time, it is 960 important that information about ongoing work is distributed early 961 and continuously. This will enable sharing of ideas and the 962 detection of potential issues. 964 Appendix C. IANA Stewardship Transition Coordination Group Request for 965 Proposals 967 IANA Stewardship Transition Coordination Group Request for Proposals 969 8 September 2014 971 Introduction 973 Under the IANA1 Stewardship Transition Coordination Group (ICG) 974 Charter,2 the ICG has four main tasks: 976 (i) Act as liaison to all interested parties in the IANA 977 stewardship transition, including the three "operational 978 communities" (i.e., those with direct operational or service 979 relationships with the IANA functions operator; namely names, 980 numbers, protocol parameters). This task consists of: 
 982 a. Soliciting proposals from the operational communities 983 b. Soliciting the input of the broad group of communities 984 affected by the
IANA functions 986 (ii) Assess the outputs of the three operational communities for 987 compatibility and interoperability (iii) Assemble a complete 988 proposal for the transition 990 (iv) Information sharing and public communication 992 This Request for Proposals (RFP) addresses task (i) of the ICG 993 Charter. This RFP does not preclude any form of input from the 994 non-operational communities. 996 0. Complete Formal Responses 998 The IANA Stewardship Transition Coordination Group (ICG) seeks 999 complete formal responses to this RFP through processes which are to 1000 be convened by each of the "operational communities" of IANA (i.e., 1001 those with direct operational or service relationships with the IANA 1002 functions operator, in connection with names, numbers, or protocol 1003 parameters). 1005 Proposals should be supported by the broad range of stakeholders 1006 participating in the proposal development process. Proposals should 1007 be developed through a transparent process that is open to and 1008 inclusive of all stakeholders interested in participating in the 1009 development of the proposal. In order to help the ICG maintain its 1010 light coordination role, all interested and affected parties are 1011 strongly encouraged to participate directly in these community 1012 processes. 1014 The following link provides information about ongoing community 1015 processes and how to participate in them, and that will continue to 1016 be updated over time: 1018 https://www.icann.org/en/stewardship/community 1020 In this RFP, "IANA" refers to the functions currently specified in 1021 the agreement between NTIA and ICANN 1022 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 1023 as any other functions traditionally performed by the IANA functions 1024 operator. SAC-067 1026 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 1027 provides one description of the many different meanings of the term 1028 "IANA" and may be useful reading in addition to the documents 1029 constituting the agreement itself. 1031 Communities are asked to adhere to open and inclusive processes in 1032 developing their responses, so that all community members may fully 1033 participate in and observe those processes. Communities are also 1034 asked to actively seek out and encourage wider participation by any 1035 other parties with interest in their response. 1037 A major challenge of the ICG will be to identify and help to 1038 reconcile differences between submitted proposals, in order to 1039 produce a single plan for the transition of IANA 1040 stewardship. Submitted Proposals should therefore focus on those 1041 elements that are considered to be truly essential to the transition 1042 of their specific IANA functions. The target deadline for all 1043 complete formal responses to this RFP is 15 January 2015. 1045 I. Comments 1047 While the ICG is requesting complete formal proposals through 1048 processes convened by each of the operational communities, and that 1049 all interested parties get involved as early as possible in the 1050 relevant community processes, some parties may choose to provide 1051 comments directly to the ICG about specific aspects of particular 1052 proposals, about the community processes, or about the ICG's own 1053 processes. Comments may be directly submitted to the ICG any time 1054 via email to icg-forum@icann.org. Comments will be publicly archived 1055 at . 1057 Commenters should be aware that ICG will direct comments received to 1058 the relevant operational communities if appropriate. The ICG will 1059 review comments received as time and resources permit and in 1060 accordance with the overall timeline for the transition. That is, 1061 comments received about specific proposals may not be reviewed until 1062 those proposals have been submitted to the ICG. The ICG may 1063 establish defined public comment periods about specific topics in 1064 the future, after the complete formal responses to the RFP have been 1065 received. 1067 Required Proposal Elements 1069 The ICG encourages each community to submit a single proposal that 1070 contains the elements described in this section. 1072 Communities are requested to describe the elements delineated in the 1073 sections below in as much detail possible, and according to the 1074 suggested format/structure, to allow the ICG to more easily 1075 assimilate the results. While each question is narrowly defined to 1076 allow for comparison between answers, respondents are encouraged to 1077 provide further information in explanatory sections, including 1078 descriptive summaries of policies/practices and associated 1079 references to source documents of specific policies/practices. In 1080 this way, the responses to the questionnaire will be useful at the 1081 operational level as well as to the broader stakeholder communities. 1083 In the interest of completeness and consistency, proposals should 1084 cross-reference wherever appropriate the current IANA Functions 1085 Contract[3] when describing existing arrangements and proposing 1086 changes to existing arrangements. 1088 0. Proposal type 1090 Identify which category of the IANA functions this submission 1091 proposes to address: 1092 [ ] Names [ ] Numbers [ ] Protocol Parameters 1094 I. Description of Community's Use of IANA Functions 1096 This section should list the specific, distinct IANA functions your 1097 community relies on. For each IANA function on which your community 1098 relies, please provide the following: 1100 o A description of the function; 1101 o A description of the customer(s) of the function; 1102 o What registries are involved in providing the function; 1103 o A description of any overlaps or interdependencies between your 1104 IANA requirements and the functions required by other customer 1105 communities. 1107 If your community relies on any other IANA service or activity 1108 beyond the scope of the IANA functions contract, you may describe 1109 them here. In this case please also describe how the service or 1110 activity should be addressed by the transition plan. 1112 II. Existing, Pre-Transition Arrangements 1114 This section should describe how existing IANA-related arrangements 1115 work, prior to the transition. 1117 [3] http://www.ntia.doc.gov/files/ntia/ 1118 publications/sf_26_pg_1-2-final_award_and_sacs.pdf 1120 A. Policy Sources 1122 This section should identify the specific source(s) of policy which 1123 must be followed by the IANA functions operator in its conduct of 1124 the services or activities described above. If there are distinct 1125 sources of policy or policy development for different IANA 1126 functions, then please describe these separately. For each source of 1127 policy or policy development, please provide the following: 1129 o Which IANA function (identified in Section I) are affected. 1130 o A description of how policy is developed and established and who 1131 is involved in policy development and establishment. 1132 o A description of how disputes about policy are resolved. 1133 o References to documentation of policy development and dispute 1134 resolution processes. 1136 B. Oversight and Accountability 1138 This section should describe all the ways in which oversight is 1139 conducted over the IANA functions operator's provision of the 1140 services and activities listed in Section I and all the ways in 1141 which the IANA functions operator is currently held accountable for 1142 the provision of those services. For each oversight or 1143 accountability mechanism, please provide as many of the following as 1144 are applicable: 1146 Which IANA functions (identified in Section I) are affected. If the 1147 policy sources identified in Section II.A are affected, identify 1148 which ones are affected and explain in what way. 1150 o A description of the entity or entities that provide oversight or 1151 perform accountability functions, including how individuals are 1152 selected or removed from participation in those entities. 1153 o A description of the mechanism (e.g., contract, reporting scheme, 1154 auditing scheme, etc.). This should include a description of the 1155 consequences of the IANA functions operator not meeting the 1156 standards established by the mechanism, the extent to which the 1157 output of the mechanism is transparent and the terms under which 1158 the mechanism may change. 1159 o Jurisdiction(s) in which the mechanism applies and the legal basis 1160 on which the mechanism rests. 1162 III. Proposed Post-Transition Oversight and Accountability 1163 Arrangements 1165 This section should describe what changes your community is 1166 proposing to the arrangements listed in Section II.B in light of the 1167 transition. If your community is proposing to replace one or more 1168 existing arrangements with new arrangements, that replacement should 1169 be explained and all of the elements listed in Section II.B should 1170 be described for the new arrangements. Your community should provide 1171 its rationale and justification for the new arrangements. 1173 If your community's proposal carries any implications for the 1174 interface between the IANA functions and existing policy arrangements 1175 described in Section II.A, those implications should be described 1176 here. 1178 If your community is not proposing changes to arrangements listed in 1179 Section II.B, the rationale and justification for that choice should 1180 be provided here. 1182 IV. Transition Implications 1184 This section should describe what your community views as the 1185 implications of the changes it proposed in Section III. These 1186 implications may include some or all of the following, or other 1187 implications specific to your community: 1189 Description of operational requirements to achieve continuity of 1190 service and possible new service integration throughout the 1191 transition. 1193 Risks to operational continuity and how they will be addressed. 1194 Description of any legal framework requirements in the absence of the 1195 NTIA contract. Description of how you have tested or evaluated the 1196 workability of any new technical or operational methods proposed in 1197 this document and how they compare to established arrangements. 1198 Description of how long the proposals in Section III are expected to 1199 take to complete, and any intermediate milestones that may occur 1200 before they are completed. 1202 V. NTIA Requirements 1204 Additionally, NTIA has established that the transition proposal must 1205 meet the following five requirements: 1206 o Support and enhance the multistakeholder model; 1207 o Maintain the security, stability, and resiliency of the Internet 1208 DNS; 1209 o Meet the needs and expectation of the global customers and 1210 partners of the IANA functions; 1211 o Maintain the openness of the Internet; 1212 o The proposal must not replace the NTIA role with a government-led 1213 or an inter-governmental organization solution. 1215 This section should explain how your community's proposal meets these 1216 requirements and how it responds to the global interest in the IANA 1217 functions. 1219 VI. Community Process 1220 This section should describe the process your community used for 1221 developing this proposal, including: 1222 o The steps that were taken to develop the proposal and to determine 1223 consensus. 1224 o Links to announcements, agendas, mailing lists, consultations and 1225 meeting proceedings. 1226 o An assessment of the level of consensus behind your community's 1227 proposal, including a description of areas of contention or 1228 disagreement. 1230 Authors' Addresses 1232 Eliot Lear (editor) 1233 Richtistrasse 7 1234 Wallisellen, ZH CH-8304 1235 Switzerland 1237 Phone: +41 44 878 9200 1238 Email: lear@cisco.com 1240 Russ Housley (editor) 1241 918 Spring Noll Drive 1242 Herndon, VA 20170 1243 USA 1245 Email: housley@vigilsec.com