idnits 2.17.1 draft-ietf-ianaplan-icg-response-04.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 == Line 753 has weird spacing: '...cussion http:...' == Line 756 has weird spacing: '...st call http:...' -- The document date (November 21, 2014) is 3443 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XXX' is mentioned on line 123, but not defined -- Looks like a reference, but probably isn't: '3' on line 1242 -- 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 (~~), 5 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 November 21, 2014 5 Expires: May 25, 2015 7 Draft Response to the Internet Coordination Group Request for Proposals 8 on the IANA protocol parameters registries 9 draft-ietf-ianaplan-icg-response-04 11 Abstract 13 This document contains the a response to a request for proposals from 14 the IANA Stewardship Transition Coordination Group regarding the 15 protocol parameters registries. It is meant to be included in an 16 aggregate proposal that also includes contributions covering domain 17 names and numbering resources 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 May 25, 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 . . . . . . . . . . . . . . . . . . . . . 17 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 59 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 61 7. Informative References . . . . . . . . . . . . . . . . . . . 17 62 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19 63 A.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 19 64 A.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20 65 A.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 20 66 A.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20 67 Appendix B. The Charter of the IANA Stewardship Coordination 68 Group (ICG . . . . . . . . . . . . . . . . . . . . . 21 69 Appendix C. IANA Stewardship Transition Coordination Group 70 Request for Proposals . . . . . . . . . . . . . . . 24 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 73 1. IETF Introduction 75 In March of 2014 the U.S. National Telecommunications & Information 76 Administration (NTIA) announced its intent to transition oversight of 77 Internet Assigned Numbers Authority (IANA) functions. In that 78 announcement, NTIA asked the Internet Corporation for Assigned Names 79 and Numbers (ICANN) to establish a process to deliver a proposal for 80 transition. As part of that process, the IANA Stewardship Transition 81 Coordination Group (ICG) was formed. The charter for the ICG can be 82 found in Appendix B. They solicited proposals regarding post- 83 transition arrangements from the three functional areas in order to 84 put forth a proposal to the NTIA. The final request for proposal 85 (RFP) can be found in Appendix C. 87 While there are interactions between all of the IANA functions and 88 IETF standards, this document specifically addresses the protocol 89 parameters registries function. Section 1 (this section) contains an 90 introduction that is sourced solely within the IETF. Section 2 91 contains the questionnaire that was written by the ICG and a formal 92 response by the IETF. Because much of this memo is taken from a 93 questionnaire we have quoted questions with ">>> " and we have 94 prefaced answers to questions being asked with "IETF Response:". 95 Note that there are small changes to the content of the questions 96 asked in order to match the RFC format. 98 As if to demonstrate the last point, the following text was included 99 in a footnote in the original propsoal. 101 In this RFP, "IANA" refers to the functions currently specified in 102 the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ 103 iana-functions-purchase-order] as well as any other functions 104 traditionally performed by the IANA functions operator. SAC-067 105 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides 106 one description of the many different meanings of the term "IANA" and 107 may be useful reading in addition to the documents constituting the 108 agreement itself. 110 2. The Formal RFP Response 112 The entire Request for Comments, including introduction, can be found 113 in Appendix C. 115 >>> 116 >>> 0. Proposal Type 117 >>> 118 >>> Identify which category of the IANA functions this 119 >>> submission proposes to address: 120 >>> 122 IETF Response: 123 [XXX] Protocol Parameters 125 This response states the existing practice of the IETF, and also 126 represents the views of the Internet Architecture Board and the IETF. 128 >>> 129 >>> I. Description of Community's Use of IANA Functions 130 >>> 131 >>> This section should list the specific, distinct IANA services 132 >>> or activities your community relies on. For each IANA service 133 >>> or activity on which your community relies, please provide the 134 >>> following: 135 >>> A description of the service or activity. 136 >>> 138 IETF Response: 140 Many IETF protocols make use of commonly defined protocol parameters. 141 These parameters are used by implementers, who are the IETF's primary 142 users of the IETF standards and other documents. To ensure 143 consistent interpretation of these parameter values by independent 144 implementations, and to promote universal interoperability, these 145 IETF protocol specifications define and require globally available 146 registries containing the parameter values and a pointer to any 147 associated documentation. The IETF uses the IANA protocol parameters 148 registries to store this information in a public location. The IETF 149 community presently accesses the protocol parameter registries via 150 references based on iana.org domain name, and makes use of the term 151 "IANA" in the protocol parameter registry processes[RFC5226]. 153 ICANN currently operates the .ARPA top level domain on behalf of the 154 Internet Architecture Board (IAB). This zone is used for certain 155 Internet infrastructure services that are delegated beneath it. We 156 consider .ARPA part of the protocol parameters registries for 157 purposes of this response. 159 >>> 160 >>> A description of the customer(s) of the service or activity. 161 >>> 163 IETF Response: 165 The IANA protocol parameters registries operator maintains the 166 protocol parameters registries for the IETF in conformance with all 167 relevant IETF policies, in accordance with the Memorandum of 168 Understanding[RFC2860] and associated supplemental agreements that 169 include service level agreements (SLAs) established between the IETF 170 and ICANN[MOUSUP]. 172 The IETF is a global voluntary standards organization whose goal is 173 to make the Internet work better [RFC3595]. IETF standards are 174 published in the RFC series. The IETF is responsible for the key 175 standards that are used on the Internet today, including IP, TCP, 176 DNS, BGP, and HTTP, to name but a few. 178 The IETF operates in an open and transparent manner [RFC6852]. The 179 processes that govern the IETF are also published in the RFC series. 180 The Internet Standards Process is documented in [RFC2026]. That 181 document explains not only how standards are developed, but also how 182 disputes about decisions are resolved. RFC 2026 has been amended a 183 number of times, and those amendments are indicated in [RFC-INDEX]. 184 The standards process can be amended in the same manner that 185 standards are approved. That is, someone proposes a change by 186 submitting a temporary document known as an Internet-Draft, the 187 community discusses it, and if rough consensus can be found the 188 change is approved by the Internet Engineering Steering Group (IESG), 189 who also have day-to-day responsibility for declaring IETF consensus 190 on technical decisions, including those that affect the IANA protocol 191 parameters registries. Anyone may propose a change during a Last 192 Call, and anyone may participate in the community discussion. 194 >>> 195 >>> What registries are involved in providing the service or 196 >>> activity. 197 >>> 199 IETF Response: 201 The protocol parameters registries are the product of IETF work. 202 These also include the top-level registry for the entire IP address 203 space and some of its sub-registries, AS number space, and a number 204 of special use registries with regard to domain names. For more 205 detail please refer to the documentation in the "overlaps or 206 interdependencies" section. 208 Administration of the protocol parameters registries is the service 209 that is provided to the IETF. 211 >>> 212 >>> A description of any overlaps or interdependencies between your 213 >>> IANA requirements and the functions required by other customer 214 >>> communities 215 >>> 217 IETF Response: 219 In this context, the IETF considers "overlap" to be where there is in 220 some way shared responsibility for a single registry across multiple 221 organizations. In this sense, there is no overlap between 222 organizations because responsibility for each registry is carefully 223 delineated. There are, however, points of interaction between other 224 organizations, and a few cases where we may further define the scope 225 of a registry for technical purposes. This is the case with both 226 names and numbers, as described in the paragraphs below. In all 227 cases, the IETF coordinates with the appropriate organizations. 229 It is important to note that the IETF includes anyone who wishes to 230 participate. Staff and participants from ICANN or the Regional 231 Internet Registries (RIRs) regularly participate in IETF activities. 233 o The IETF has specified a number of special use registries with 234 regard to domain names. These registries require coordination 235 with ICANN as the policy authority for the DNS root, including 236 community groups that are responsible for ICANN policy on domain 237 names such as the GNSO and the ccNSO. There are already 238 mechanisms in place to perform this coordination, and the capacity 239 to modify them to meet new conditions as they might 240 arise.[RFC6761] 242 o The IETF specifies the DNS protocol. From time to time there have 243 been and will be updates to that protocol. As we make changes we 244 will broadly consult the operational community about the impact of 245 those changes, as we have done in the past. 247 o The IETF specifies minimum requirements for root servers. Should 248 those requirements change, we will inform ICANN. 250 o The routing architecture has evolved over time, and is expected to 251 continue to do so. Such evolution may have an impact on 252 appropriate IP address allocation strategies. As and when that 253 happens, we will consult with the RIR community, as we have done 254 in the past. 256 o The IETF is responsible for policy relating to the entire IP 257 address space and AS number space. Through the IANA protocol 258 parameters registries, the IETF delegates unicast IP address and 259 AS number ranges to the RIR system [RFC7020],[RFC7249]. Special 260 address allocation, such a multicast and anycast addresses, often 261 require coordination. Another example of IP addresses that are 262 not administered by the RIR system is Unique Local Addresses 263 (ULAs) [RFC4193], where local networks employ a prefix that is not 264 intended to be routed on the public Internet. New special address 265 allocations are added, from time to time, related to the evolution 266 of the standards. In all cases, these special assignments are 267 listed in the IANA protocol paramters registries. 269 o The IETF maintains sub-registries for special IPv4 and IPv6 270 assignments. These are specified in [RFC3307], [RFC5771], and 271 [RFC6890]. The IETF coordinates such assignments with the RIRs. 273 o IETF standards changes may have impact on operations of RIRs and 274 service providers. A recent example is the extensions to BGP to 275 carry the Autonomous System numbers as four-octet entities 276 [RFC6793]. It is important to note that this change occurred out 277 of operational necessity, and it demonstrated strong alignment 278 between the RIRs and the IETF. 280 >>> II. Existing, Pre-Transition Arrangements 282 >>> 283 >>> This section should describe how existing IANA-related 284 >>> arrangements work, prior to the transition. 285 >>> 286 >>> A. Policy Sources 287 >>> 288 >>> 289 >>> This section should identify the specific source(s) of policy 290 >>> which must be followed by the IANA functions operator in its 291 >>> conduct of the services or activities described above. If there 292 >>> are distinct sources of policy or policy development for 293 >>> different IANA activities, then please describe these 294 >>> separately. For each source of policy or policy development, 295 >>> please provide the following: 296 >>> 297 >>> Which IANA service or activity (identified in Section I) is 298 >>> affected. 299 >>> 301 IETF Response: The protocol parameters registries. 303 >>> 304 >>> A description of how policy is developed and established and 305 >>> who is involved in policy development and establishment. 306 >>> 308 IETF Response: 310 Policy for overall management of the protocol parameters registries 311 is stated in [RFC6220] and [RFC5226]. The first of these documents 312 explains the model for how the registries are to be operated, how 313 policy is set, and how oversight takes place. RFC 5226 specifies the 314 policies that specification writers may employ when they define new 315 protocol registries in the "IANA Considerations" section of each 316 specification. All policies at the IETF begin with a proposal in the 317 form of an Internet-Draft. Anyone may submit such a proposal. If 318 there is sufficient interest, a working group whose scope includes 319 the proposed work may choose to adopt it, the Internet Engineering 320 Steering Group may choose to create a working group, or an Area 321 Director may choose to sponsor the draft. In any case, anyone may 322 comment on the proposal as it progresses. A proposal cannot be 323 passed by the IESG unless it enjoys sufficient community support as 324 to indicate rough consensus [RFC7282]. In each case, a "Last Call" 325 is made so that there is notice of any proposed change to a policy or 326 process. Anyone may comment during a Last Call. 328 >>> 329 >>> A description of how disputes about policy are resolved. 331 >>> 333 IETF Response: 335 Most disputes are handled at the lowest level through the working 336 group and rough consensus processes. Should anyone disagree with any 337 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 338 resolution and appeals process that includes the responsible Area 339 Director, the IESG, and the IAB. Should appeals be upheld, an 340 appropriate remedy is applied. In the case where someone claims that 341 the procedures themselves are insufficient or inadequate in some way 342 to address a circumstance, one may appeal an IAB decision to the 343 Internet Society Board of Trustees. 345 >>> 346 >>> References to documentation of policy development and dispute 347 >>> resolution processes. 348 >>> 350 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 351 conflict resolution and appeals process. [RFC2418] specifies working 352 group procedures. Note that both of these documents have been 353 amended in later RFCs as indicated in the [RFC-INDEX]. Please also 354 see the references at the bottom of this document. 356 >>> 357 >>> B. Oversight and Accountability 358 >>> 359 >>> This section should describe all the ways in which oversight is 360 >>> conducted over IANA functions operator's provision of the 361 >>> services and activities listed in Section I and all the ways in 362 >>> which IANA functions operator is currently held accountab le for 363 >>> the provision of those services. For each oversight or 364 >>> accountability mechanism, please provide as many of the 365 >>> following as are applicable: 366 >>> 367 >>> Which IANA service or activity (identified in Section I) is 368 >>> affected. 369 >>> 371 IETF Response: the protocol parameters registries. 373 >>> 374 >>> If not all policy sources identified in Section II.A are 375 >>> affected, identify which ones are affected. 377 >>> 379 IETF Response: all policy sources relating to the protocol parameters 380 registry are affected. 382 >>> 383 >>> A description of the entity or entities that provide oversight 384 >>> or perform accountability functions, including how individuals 385 >>> are selected or removed from participation in those entities. 386 >>> 388 IETF Response: 390 The Internet Architecture Board (IAB) is an oversight body of the 391 IETF whose responsibilities include, among other things, confirming 392 appointment of IESG members, managing appeals as discussed above, 393 management of certain domains, including .ARPA [RFC3172], and general 394 architectural guidance to the broader community. The IAB must 395 approve the appointment of an organization to act as IANA operator on 396 behalf of the IETF. The IAB is also responsible for establishing 397 liaison relationships with other orgnaizations on behalf of the IETF. 398 The IAB's charter is to be found in [RFC2850]. 400 The IAB members are selected and may be recalled through a Nominating 401 Committee (NOMCOM) process, which is described in [RFC3777]. This 402 process provides for selection of active members of the community who 403 themselves agree upon a slate of candidates. Those candidates are 404 sent to the Internet Society Board of Trustees for confirmation. In 405 general, members are appointed for terms of two years. The IAB 406 selects its own chair. 408 The IAB provides oversight of the protocol parameters registries of 409 the IETF, and is responsible for selecting appropriate operator(s) 410 and related per-registry arrangements. Especially when relationships 411 among protocols call for it, many registries are operated by, or in 412 conjunction with, other bodies. Unless the IAB or IETF has concluded 413 that special treatment is needed, the operator for registries is 414 currently ICANN. 416 >>> 417 >>> A description of the mechanism (e.g., contract, reporting 418 >>> scheme, auditing scheme, etc.). This should include a 419 >>> description of the consequences of the IANA functions operator 420 >>> not meeting the standards established by the mechanism, the 421 >>> extent to which the output of the mechanism is transparent and 422 >>> the terms under which the mechanism may change. 424 >>> 426 IETF Response: 428 A memorandum of understanding (MoU) between ICANN and the IETF 429 community has been in place since 2000. It can be found in 430 [RFC2860]. The MoU defines the work to be carried out by the IANA 431 functions operator for the IETF and the Internet Research Task Force 432 (IRTF), a peer organization to the IETF that focuses on research. 433 Each year a service level agreement is negotiated that supplements 434 the MoU. 436 Day-to-day administration and contract management is the 437 responsibility of the IETF Administrative Director (IAD). The IETF 438 Administrative Oversight Committee (IAOC) oversees the IAD. The 439 members of the IAOC are also the trustees of the IETF Trust, whose 440 main purpose is to hold certain intellectual property for the benefit 441 of the IETF as a whole. IAOC members are appointed by the Internet 442 Society Board of Trustees, the IAB, the IESG, and the NOMCOM 443 [RFC4071]. The IAOC works with the IANA functions operator to 444 establish annual IANA performance metrics and operational procedures, 445 and the resulting document is adopted as an supplement to the MoU 446 each year [MOUSUP]. In accordance with these supplements, an annual 447 review is performed to ensure that protocol parameter requests are 448 being processed according to the established policies. 450 To date there have been no unresolvable disputes or issues. In the 451 unlikely event that a more difficult situation should arise, the IAOC 452 and the IAB would engage ICANN management to address the matter. The 453 MoU also provides an option for either party to terminate the 454 arrangement with six months notice. Obviously such action would only 455 be undertaken after serious consideration. 457 >>> 458 >>> Jurisdiction(s) in which the mechanism applies and the legal 459 >>> basis on which the mechanism rests. 460 >>> 462 IETF Response 464 This mechanism is global in nature. The current agreement does not 465 specify a jurisdiction. 467 >>>III. Proposed Post-Transition Oversight and Accountability 468 Arrangements 469 >>> 470 >>> This section should describe what changes your community is 471 >>> proposing to the arrangements listed in Section II.B in light of 472 >>> the transition. If your community is proposing to replace one or 473 >>> more existing arrangements with new arrangements, that 474 >>> replacement should be explained and all of the elements listed 475 >>> in Section II.B should be described for the new 476 >>> arrangements. Your community should provide its rationale and 477 >>> justification for the new arrangements. 478 >>> 479 >>> If your community's proposal carries any implications for 480 >>> existing policy arrangements described in Section II.A, those 481 >>> implications should be described here. 482 >>> 483 >>> If your community is not proposing changes to arrangements 484 >>> listed in Section II.B, the rationale and justification for that 485 >>> choice should be provided here. 486 >>> 488 IETF Response: 490 No major changes are required. Over the years since the creation of 491 ICANN, the IETF, ICANN, and IAB have together created a system of 492 agreements, policies, and oversight mechanisms that already cover 493 what is needed. This system has worked well without any operational 494 involvement from the NTIA. Therefore, no new organizaitons or 495 structures are needed. 497 IANA protocol parameters registry updates will continue to function 498 day-to-day, as they have been doing for the last decade or more. The 499 IETF community is quite satisfied with the current arrangement with 500 ICANN. RFC 2860 remains in force and has served the IETF community 501 very well. RFC 6220 has laid out an appropriate service description 502 and requirements. 504 However in the absence of the NTIA contract a few new arrangements 505 may be needed in order to ensure the IETF community's expectations 506 are met. Those expectations are the following: 508 o The protocol parameters registries are in the public domain. It 509 is the preference of the IETF community that all relevant parties 510 acknowledge that fact as part of the transition. 512 o It is possible in the future that the operation of the protocol 513 parameters registries may be transitioned from ICANN to subsequent 514 operator(s). It is the preference of the IETF community that, as 515 part of the NTIA transition, ICANN acknowledge that it will carry 516 out the obligations established under C.7.3 and I.61 of the 517 current IANA functions contract between ICANN and the 518 NTIA[NTIA-Contract] to achieve a smooth transition to subsequent 519 operator(s), should the need arise. Furthermore, in the event of 520 a transition it is the expectation of the IETF community that 521 ICANN, the IETF, and subsequent operator(s) will work together to 522 minimize disruption in the use the protocol parameters registries 523 or other resources currently located at iana.org. 525 Discussions during IETF 89 in London led to the following guiding 526 principles for IAB efforts that impact IANA protocol parameter 527 registries. These principles must be taken together; their order is 528 not significant. 530 1. The IETF protocol parameters registries function has been and 531 continues to be capably provided by the Internet technical community. 533 The strength and stability of the function and its foundation within 534 the Internet technical community are both important given how 535 critical protocol parameters are to the proper functioning of IETF 536 protocols. 538 We think the structures that sustain the protocol parameters 539 registries function needs to be strong enough that they can be 540 offered independently by the Internet technical community, without 541 the need for backing from external parties. And we believe we 542 largely are there already, although the system can be strengthened 543 further, and continuous improvements are being made. 545 2. The protocol parameters registries function requires openness, 546 transparency, and accountability. 548 Existing documentation of how the function is administered and 549 overseen is good [RFC2860], [RFC6220]. Further articulation and 550 clarity may be beneficial. It is important that the whole Internet 551 community can understand how the function works, and that the 552 processes for registering parameters and holding those who oversee 553 the protocol parameters function accountable for following those 554 processes are understood by all interested parties. We are committed 555 to making improvements here if necessary. 557 3. Any contemplated changes to the protocol parameters registries 558 function should respect existing Internet community agreements. 560 The protocol parameters registries function is working well. The 561 existing Memorandum of Understanding in RFC 2860 defines "the 562 technical work to be carried out by the Internet Assigned Numbers 563 Authority on behalf of the Internet Engineering Task Force and the 564 Internet Research Task Force." Any modifications to the protocol 565 parameters registries function should be made using the IETF process 566 to update RFC 6220 and other relevant RFCs. Put quite simply: 567 evolution, not revolution. 569 4. The Internet architecture requires and receives capable service 570 by Internet registries. 572 The stability of the Internet depends on capable provision of not 573 just IETF protocol parameters, but IP numbers, domain names, and 574 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 575 protocols. Thus we expect the role of the IETF in standards 576 development, architectural guidance, and allocation of certain name/ 577 number parameters to continue. IP multicast addresses and special- 578 use DNS names are two examples where close coordination is needed. 579 The IETF will continue to coordinate with ICANN, the RIRs, and other 580 parties that are mutually invested in the continued smooth operation 581 of the Internet registries. We fully understand the need to work 582 together. 584 5. The IETF will continue management of the protocol parameter 585 registry function as an integral component of the IETF standards 586 process and the use of resulting protocols. 588 RFC 6220 specifies the role and function of the protocol parameters 589 registry, which is critical to IETF standards processes and IETF 590 protocols. The IAB, on behalf of the IETF, has the responsibility to 591 define and manage the relationship with the protocol registry 592 operator role. This responsibility includes the selection and 593 management of the protocol parameter registry operator, as well as 594 management of the parameter registration process and the guidelines 595 for parameter allocation. 597 6. The protocol parameters registries are provided as a public 598 service. 600 Directions for the creation of protocol parameters registries and the 601 policies for subsequent additions and updates are specified in RFCs. 602 The protocol parameters registries are available to everyone, and 603 they are published in a form that allows their contents to be 604 included in other works without further permission. These works 605 include, but are not limited to, implementations of Internet 606 protocols and their associated documentation. 608 These principles will guide the IAB, IAOC, and the rest of the IETF 609 community as they work with ICANN to establish future IANA 610 performance metrics and operational procedures. 612 >>> IV Transition Implications 614 >>> 615 >>> This section should describe what your community views as the 616 >>> implications of the changes it proposed in Section III. These 617 >>> implications may include some or all of the following, or other 618 >>> implications specific to your community: 619 >>> 620 >>> o Description of operational requirements to achieve continuity 621 >>> of service and possible new service integration throughout 622 >>> the transition. 623 >>> o Risks to operational continuity 624 >>> o Description of any legal framework requirements in the 625 >>> absence of the NTIA contract 626 >>> o Description of how you have tested or evaluated the 627 >>> workability of any new technical or operational methods 628 >>> proposed in this document and how they compare to established 629 >>> arrangements. 630 >>> 632 IETF Response: 634 No structural changes are required. The principles listed above will 635 guide IAB, IAOC, and the rest of the IETF community as they work with 636 ICANN to establish future IANA performance metrics and operational 637 procedures, as they have in the past. 639 As no services are expected to change, no continuity issues are 640 anticipated, and there are no new technical or operational methods 641 proposed by the IETF to test. The IETF leadership, ICANN, and the 642 RIRs maintain an ongoing informal dialog to spot any unforeseen 643 issues that might arise as a result of other changes. 645 What is necessary as part of transition is the completion of any 646 supplemental agreement(s) necessary to achieve the requirements 647 outlined in our response in Section III of this RFP. 649 >>> 650 >>> V. NTIA Requirements 651 >>> 652 >>> Additionally, NTIA has established that the transition proposal 653 >>> must meet the following five requirements: 654 >>> 655 >>> "Support and enhance the multistakeholder model;" 656 >>> 657 IETF Response: 659 Everyone is welcome to participate in IETF activities. The policies 660 and procedures are outlined in the documents we named above. In- 661 person attendance is not required for participation, and many people 662 participate in email discussions that have never attended an IETF 663 meeting. An email account is the only requirement to participate. 664 The IETF makes use of both formal and informal lines of communication 665 to collaborate with other organizations within the multistakeholder 666 ecosystem. 668 >>> 669 >>> "Maintain the security, stability, and resiliency of the 670 >>> Internet DNS;" 671 >>> 673 IETF Response: 675 The DNS relies on some of the IETF protocol parameters registries. 676 As the current IANA functions operator, ICANN performs its task very 677 well, usually exceeding the service level agreement metrics.[METRICS] 678 Security, stability, and resiliency of the Internet DNS is best 679 protected by maintaining the current service in its current form. 681 >>> 682 >>> "Meet the needs and expectation of the global customers and 683 >>> partners of the IANA services;" 684 >>> 686 IETF Response: 688 Implementers and their users from around the world make use of the 689 IETF standards and the associated IANA protocol parameters 690 registries. The current IANA protocol parameters registries system 691 is meeting the needs of these global customers. This proposal 692 continues to meet their needs by maintaining the existing processes 693 that have served them well in the past. 695 >>> 697 >>> 698 >>> "Maintain the openness of the Internet." 699 >>> 701 IETF Response: 703 This proposal maintains the existing open framework that allows 704 anyone to participate in the development of IETF standards, including 705 the IANA protocol parameters registries policies. Further, an 706 implementer anywhere in the world has full access to the protocol 707 specification published in the RFC series and the protocol parameters 708 registries published at iana.org. Those who require assignments in 709 the IANA protocol registries will continue to be able to do so, as 710 specified by the existing policies for those registries. 712 >>> 713 >>> VI. Community Process 714 >>> 715 >>> This section should describe the process your community used for 716 >>> developing this proposal, including: 717 >>> 718 >>> o The steps that were taken to develop the proposal and to 719 >>> determine consensus. 720 >>> 722 IETF Response: 724 The IESG established the IANAPLAN working group to develop this 725 response. Anyone was welcome to join the discussion and participate 726 in the development of this response. An open mailing list 727 (ianaplan@ietf.org) was associated with the working group. In 728 addition, IETF's IANA practices have been discussed in the broader 729 community, and all input is welcome. 731 >>> 732 >>> Links to announcements, agendas, mailing lists, consultations and 733 >>> meeting proceedings. 734 >>> 736 IETF Response: 738 The following list is not exhaustive, as there have been many open 739 discussions about this transition within the IETF community in the 740 past few months. 742 Creation of an open mailing list to discuss the transition: http://w 743 ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html 745 Announcement of a public session on the transition: http:// 746 www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html 748 Announcement by the IESG of the intent to form a working group: 750 http://www.ietf.org/mail-archive/web/ietf-announce/current/ 751 msg13170.html 753 The working group discussion http://www.ietf.org/mail-archive/web/ 754 ianaplan/current/maillist.html 756 Working group last call http://www.ietf.org/mail-archive/web/ 757 ianaplan/current/msg00760.html 759 >>> 760 >>> An assessment of the level of consensus behind your community's 761 >>> proposal, including a description of areas of contention or 762 >>> disagreement. 763 >>> 765 IETF Response: To be completed as the process progresses. 767 3. IANA Considerations 769 This memo is a response a request for proposals. No parameter 770 allocations or changes are sought. 772 4. Security Considerations 774 While the agreement, supplements, policies, and procedures around the 775 IANA function have shown strong resiliency, the IETF will continue to 776 work with all relevant parties to facilitate improvements while 777 maintaining availability of the IANA registries. 779 5. IAB Note 781 This section to be filled in by the IAB. 783 6. Acknowledgments 785 This document describes processes that have been developed by many 786 members of the community over many years. The initial version of 787 this document was developed collaboratively through both the IAB IANA 788 Strategy Program and the IETF IANAPLAN WG. Particular thanks go to 789 Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie 790 Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John 791 Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and 792 Suzanne Woolf. 794 7. Informative References 796 [METRICS] , "Performance Standards Metrics Report", , 797 . 799 [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of 800 Understanding between the IETF and ICANN)", , 801 . 803 [NTIA-Contract] 804 , "The NTIA Contract with ICANN", , . 808 [RFC-INDEX] 809 RFC Editor, , "Index of all Requests for Comments", RFC 810 Index, August 2014. 812 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 813 3", BCP 9, RFC 2026, October 1996. 815 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 816 Procedures", BCP 25, RFC 2418, September 1998. 818 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 819 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 820 May 2000. 822 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 823 Understanding Concerning the Technical Work of the 824 Internet Assigned Numbers Authority", RFC 2860, June 2000. 826 [RFC3172] Huston, G., "Management Guidelines & Operational 827 Requirements for the Address and Routing Parameter Area 828 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 830 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 831 Addresses", RFC 3307, August 2002. 833 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 834 3595, September 2003. 836 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 837 Recall Process: Operation of the Nominating and Recall 838 Committees", BCP 10, RFC 3777, June 2004. 840 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 841 Administrative Support Activity (IASA)", BCP 101, RFC 842 4071, April 2005. 844 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 845 Addresses", RFC 4193, October 2005. 847 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 848 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 849 May 2008. 851 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 852 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 853 March 2010. 855 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., 856 Internet Architecture Board, "Defining the Role and 857 Function of IETF Protocol Parameter Registry Operators", 858 RFC 6220, April 2011. 860 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 861 RFC 6761, February 2013. 863 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 864 Autonomous System (AS) Number Space", RFC 6793, December 865 2012. 867 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. 868 Amour, "Affirmation of the Modern Paradigm for Standards", 869 RFC 6852, January 2013. 871 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 872 "Special-Purpose IP Address Registries", BCP 153, RFC 873 6890, April 2013. 875 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 876 Internet Numbers Registry System", RFC 7020, August 2013. 878 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 879 2014. 881 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 882 7282, June 2014. 884 Appendix A. Changes 886 NOTE: This section to be removed by RFC Editor at publication. 888 A.1. Changes from -03 to -04 890 o Additional text regarding what is needed in Section III. 892 o Appropriate language modifications in section IV to match the 893 above changes in III. 895 o Acknowledgments edits. 897 A.2. Changes from -02 to -03 899 o Terminology consistency. 901 o Add IAB section. 903 o Changes based on WG discussion on what we prefer as part of the 904 transition regarding IPR. 906 o Add discussion about .ARPA domain. 908 o Elaboration of what registries are involved. 910 o Additional text around coordination with ICANN. 912 o Working groups can adopt items within their charters. 914 o IAB appointments generally last two years. 916 o Add mention of the Trust. 918 o Security Considerations update. 920 A.3. Changes from -01 to -02 922 o A better description special registries and BGP ASNs. 924 o Clarity on how the address space and ASNs are delegated. 926 o Many editorials corrected. 928 o Mention of the annual review as part of the SLAs. 930 o Change about how overlap is presented. 932 o A number of small wording changes based on feedback. 934 A.4. Changes from -00 to -01 936 o Front matter greatly reduced. 938 o Appendices with charter and RFP added. 940 o Jurisdiction text changed. 942 o Proposed changes include supplemental agreement(s) to address 943 jurisdiction, dispute resolution, and IPR, including names and 944 marks. 946 o Transition implications slightly modified to reference 947 supplemental agreement. 949 Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG 951 Charter for the IANA Stewardship Transition Coordination Group V.10 953 (August 27, 2014) 955 The IANA stewardship transition coordination group (ICG) has one 956 deliverable: a proposal to the U.S. Commerce Department National 957 Telecommunications and Information Administration (NTIA) regarding 958 the transition of NTIA's stewardship of the IANA functions to the 959 global multi-stakeholder community. The group will conduct itself 960 transparently, consult with a broad range of stakeholders, and ensure 961 that its proposals support the security and stability of the IANA 962 functions. 964 The group's mission is to coordinate the development of a proposal 965 among the communities affected by the IANA functions. The IANA 966 functions are divided into three main categories: domain names, 967 number resources, and other protocol parameters. The domain names 968 category falls further into the country code and generic domain name 969 sub-categories. While there is some overlap among all of these 970 categories, each poses distinct organizational, operational and 971 technical issues, and each tends to have distinct communities of 972 interest and expertise. For those reasons it is best to have work on 973 the three categories of IANA parameters proceed autonomously in 974 parallel and be based in the respective communities. 976 The IANA stewardship transition process is taking place alongside a 977 parallel and related process on enhancing ICANN accountability. 978 While maintaining the accountability of Internet identifier 979 governance is central to both processes, this group's scope is 980 focused on the arrangements required for the continuance of IANA 981 functions in an accountable and widely accepted manner after the 982 expiry of the NTIA-ICANN contract. Nevertheless, the two processes 983 are interrelated and interdependent and should appropriately 984 coordinate their work. 986 The coordination group has four main tasks: 987 (i) Act as liaison to all interested parties, including the three 988 "operational communities" (i.e., those with direct operational 989 or service relationship with IANA; namely names, numbers, 990 protocol parameters). This task consists of: 991 a. Soliciting proposals from the operational communities 992 b. Soliciting the input of the broad group of communities 993 affected by the IANA functions 994 (ii) Assess the outputs of the three operational communities for 995 compatibility and interoperability 996 (iii) Assemble a complete proposal for the transition 997 (iv) Information sharing and public communication 998 Describing each in more detail: 999 (i) Liaison 1000 a. Solicit proposals 1002 The ICG expects a plan from the country code and generic name 1003 communities (possibly a joint one), a plan from the numbers 1004 community, and a plan from the protocol parameters community. 1005 Members of the ICG will ensure that the communities from which they 1006 are drawn are working on their part of the transition plans. This 1007 involves informing them of requirements and schedules, tracking 1008 progress, and highlighting the results or remaining issues. The role 1009 of a coordination group member during this phase is to provide status 1010 updates about the progress of his or her community in developing 1011 their component, and to coordinate which community will develop a 1012 transition proposal for each area of overlap (e.g., special-use 1013 registry). 1015 While working on the development of their proposals, the operational 1016 communities are expected to address common requirements and issues 1017 relating to the transition, in as far as they affect their parts of 1018 the stewardship of IANA functions. 1020 b. Solicit broader input 1022 The ICG is open for input and feedback from all interested parties. 1023 While no set of formal requirements related to a transition proposal 1024 will be requested outside the operational communities, everyone's 1025 input is welcome across all topics. 1027 The ICG expects that all interested parties get involved as early as 1028 possible in the relevant community processes. Input received 1029 directly by the ICG may be referred to the relevant community 1030 discussion. 1032 The ICG members chosen from a particular community are the official 1033 communication channel between the ICG and that community. 1035 (ii) Assessment 1037 When the group receives output from the communities it will discuss 1038 and assess their compatibility and interoperability with the 1039 proposals of the other communities. Each proposal should be 1040 submitted with a clear record of how consensus has been reached for 1041 the proposal in the community, and provide an analysis that shows the 1042 proposal is in practice workable. The ICG should also compile the 1043 input it has received beyond the operational communities, and review 1044 the impacts of this input. 1046 The ICG might at some point detect problems with the component 1047 proposals. At that point the role of the ICG is to communicate that 1048 back to the relevant communities so that they (the relevant 1049 communities) can address the issues. It is not in the role of the 1050 ICG to develop proposals or to select from among competing proposals. 1052 (iii) Assembling and submitting a complete proposal 1054 The assembly effort involves taking the proposals for the different 1055 components and verifying that the whole fulfills the intended scope, 1056 meets the intended criteria, that there are no missing parts, and 1057 that the whole fits together. The whole also needs to include 1058 sufficient independent accountability mechanisms for running the IANA 1059 function. The ICG will then develop a draft final proposal that 1060 achieves rough consensus within the ICG itself. The ICG will then 1061 put this proposal up for public comment involving a reasonable period 1062 of time for reviewing the draft proposal, analyzing and preparing 1063 supportive or critical comments. The ICG will then review these 1064 comments and determine whether modifications are required. If no 1065 modifications are needed, and the coordination group agrees, the 1066 proposal will be submitted to NTIA. 1068 If changes are required to fix problems or to achieve broader 1069 support, the ICG will work with the operational communities in a 1070 manner similar to what was described in task (ii) above. Updates are 1071 subject to the same verification, review, and consensus processes as 1072 the initial proposals. If, in the ICG's opinion, broad public 1073 support for the proposal as articulated by the NTIA is not present, 1074 the parts of the proposal that are not supported return to the 1075 liaison phase. 1077 (iv) Information sharing 1079 The ICG serves as a central clearinghouse for public information 1080 about the IANA stewardship transition process. Its secretariat 1081 maintains an independent, publicly accessible and open website, under 1082 its own domain, where status updates, meetings and notices are 1083 announced, proposals are stored, the ICG members are listed, etc. As 1084 the development of the transition plans will take some time, it is 1085 important that information about ongoing work is distributed early 1086 and continuously. This will enable sharing of ideas and the 1087 detection of potential issues. 1089 Appendix C. IANA Stewardship Transition Coordination Group Request for 1090 Proposals 1092 IANA Stewardship Transition Coordination Group Request for Proposals 1094 8 September 2014 1096 Introduction 1098 Under the IANA1 Stewardship Transition Coordination Group (ICG) 1099 Charter,2 the ICG has four main tasks: 1101 (i) Act as liaison to all interested parties in the IANA 1102 stewardship transition, including the three "operational 1103 communities" (i.e., those with direct operational or service 1104 relationships with the IANA functions operator; namely names, 1105 numbers, protocol parameters). This task consists of: 
 1107 a. Soliciting proposals from the operational communities 1108 b. Soliciting the input of the broad group of communities 1109 affected by the
IANA functions 1111 (ii) Assess the outputs of the three operational communities for 1112 compatibility and interoperability (iii) Assemble a complete 1113 proposal for the transition 1115 (iv) Information sharing and public communication 1117 This Request for Proposals (RFP) addresses task (i) of the ICG 1118 Charter. This RFP does not preclude any form of input from the 1119 non-operational communities. 1121 0. Complete Formal Responses 1123 The IANA Stewardship Transition Coordination Group (ICG) seeks 1124 complete formal responses to this RFP through processes which are to 1125 be convened by each of the "operational communities" of IANA (i.e., 1126 those with direct operational or service relationships with the IANA 1127 functions operator, in connection with names, numbers, or protocol 1128 parameters). 1130 Proposals should be supported by the broad range of stakeholders 1131 participating in the proposal development process. Proposals should 1132 be developed through a transparent process that is open to and 1133 inclusive of all stakeholders interested in participating in the 1134 development of the proposal. In order to help the ICG maintain its 1135 light coordination role, all interested and affected parties are 1136 strongly encouraged to participate directly in these community 1137 processes. 1139 The following link provides information about ongoing community 1140 processes and how to participate in them, and that will continue to 1141 be updated over time: 1143 https://www.icann.org/en/stewardship/community 1145 In this RFP, "IANA" refers to the functions currently specified in 1146 the agreement between NTIA and ICANN 1147 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 1148 as any other functions traditionally performed by the IANA functions 1149 operator. SAC-067 1151 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 1152 provides one description of the many different meanings of the term 1153 "IANA" and may be useful reading in addition to the documents 1154 constituting the agreement itself. 1156 Communities are asked to adhere to open and inclusive processes in 1157 developing their responses, so that all community members may fully 1158 participate in and observe those processes. Communities are also 1159 asked to actively seek out and encourage wider participation by any 1160 other parties with interest in their response. 1162 A major challenge of the ICG will be to identify and help to 1163 reconcile differences between submitted proposals, in order to 1164 produce a single plan for the transition of IANA 1165 stewardship. Submitted Proposals should therefore focus on those 1166 elements that are considered to be truly essential to the transition 1167 of their specific IANA functions. The target deadline for all 1168 complete formal responses to this RFP is 15 January 2015. 1170 I. Comments 1172 While the ICG is requesting complete formal proposals through 1173 processes convened by each of the operational communities, and that 1174 all interested parties get involved as early as possible in the 1175 relevant community processes, some parties may choose to provide 1176 comments directly to the ICG about specific aspects of particular 1177 proposals, about the community processes, or about the ICG's own 1178 processes. Comments may be directly submitted to the ICG any time 1179 via email to icg-forum@icann.org. Comments will be publicly archived 1180 at . 1182 Commenters should be aware that ICG will direct comments received to 1183 the relevant operational communities if appropriate. The ICG will 1184 review comments received as time and resources permit and in 1185 accordance with the overall timeline for the transition. That is, 1186 comments received about specific proposals may not be reviewed until 1187 those proposals have been submitted to the ICG. The ICG may 1188 establish defined public comment periods about specific topics in 1189 the future, after the complete formal responses to the RFP have been 1190 received. 1192 Required Proposal Elements 1194 The ICG encourages each community to submit a single proposal that 1195 contains the elements described in this section. 1197 Communities are requested to describe the elements delineated in the 1198 sections below in as much detail possible, and according to the 1199 suggested format/structure, to allow the ICG to more easily 1200 assimilate the results. While each question is narrowly defined to 1201 allow for comparison between answers, respondents are encouraged to 1202 provide further information in explanatory sections, including 1203 descriptive summaries of policies/practices and associated 1204 references to source documents of specific policies/practices. In 1205 this way, the responses to the questionnaire will be useful at the 1206 operational level as well as to the broader stakeholder communities. 1208 In the interest of completeness and consistency, proposals should 1209 cross-reference wherever appropriate the current IANA Functions 1210 Contract[3] when describing existing arrangements and proposing 1211 changes to existing arrangements. 1213 0. Proposal type 1215 Identify which category of the IANA functions this submission 1216 proposes to address: 1217 [ ] Names [ ] Numbers [ ] Protocol Parameters 1219 I. Description of Community's Use of IANA Functions 1221 This section should list the specific, distinct IANA functions your 1222 community relies on. For each IANA function on which your community 1223 relies, please provide the following: 1225 o A description of the function; 1226 o A description of the customer(s) of the function; 1227 o What registries are involved in providing the function; 1228 o A description of any overlaps or interdependencies between your 1229 IANA requirements and the functions required by other customer 1230 communities. 1232 If your community relies on any other IANA service or activity 1233 beyond the scope of the IANA functions contract, you may describe 1234 them here. In this case please also describe how the service or 1235 activity should be addressed by the transition plan. 1237 II. Existing, Pre-Transition Arrangements 1239 This section should describe how existing IANA-related arrangements 1240 work, prior to the transition. 1242 [3] http://www.ntia.doc.gov/files/ntia/ 1243 publications/sf_26_pg_1-2-final_award_and_sacs.pdf 1245 A. Policy Sources 1247 This section should identify the specific source(s) of policy which 1248 must be followed by the IANA functions operator in its conduct of 1249 the services or activities described above. If there are distinct 1250 sources of policy or policy development for different IANA 1251 functions, then please describe these separately. For each source of 1252 policy or policy development, please provide the following: 1254 o Which IANA function (identified in Section I) are affected. 1255 o A description of how policy is developed and established and who 1256 is involved in policy development and establishment. 1257 o A description of how disputes about policy are resolved. 1258 o References to documentation of policy development and dispute 1259 resolution processes. 1261 B. Oversight and Accountability 1263 This section should describe all the ways in which oversight is 1264 conducted over the IANA functions operator's provision of the 1265 services and activities listed in Section I and all the ways in 1266 which the IANA functions operator is currently held accountable for 1267 the provision of those services. For each oversight or 1268 accountability mechanism, please provide as many of the following as 1269 are applicable: 1271 Which IANA functions (identified in Section I) are affected. If the 1272 policy sources identified in Section II.A are affected, identify 1273 which ones are affected and explain in what way. 1275 o A description of the entity or entities that provide oversight or 1276 perform accountability functions, including how individuals are 1277 selected or removed from participation in those entities. 1278 o A description of the mechanism (e.g., contract, reporting scheme, 1279 auditing scheme, etc.). This should include a description of the 1280 consequences of the IANA functions operator not meeting the 1281 standards established by the mechanism, the extent to which the 1282 output of the mechanism is transparent and the terms under which 1283 the mechanism may change. 1284 o Jurisdiction(s) in which the mechanism applies and the legal basis 1285 on which the mechanism rests. 1287 III. Proposed Post-Transition Oversight and Accountability 1288 Arrangements 1290 This section should describe what changes your community is 1291 proposing to the arrangements listed in Section II.B in light of the 1292 transition. If your community is proposing to replace one or more 1293 existing arrangements with new arrangements, that replacement should 1294 be explained and all of the elements listed in Section II.B should 1295 be described for the new arrangements. Your community should provide 1296 its rationale and justification for the new arrangements. 1298 If your community's proposal carries any implications for the 1299 interface between the IANA functions and existing policy arrangements 1300 described in Section II.A, those implications should be described 1301 here. 1303 If your community is not proposing changes to arrangements listed in 1304 Section II.B, the rationale and justification for that choice should 1305 be provided here. 1307 IV. Transition Implications 1309 This section should describe what your community views as the 1310 implications of the changes it proposed in Section III. These 1311 implications may include some or all of the following, or other 1312 implications specific to your community: 1314 Description of operational requirements to achieve continuity of 1315 service and possible new service integration throughout the 1316 transition. 1318 Risks to operational continuity and how they will be addressed. 1319 Description of any legal framework requirements in the absence of the 1320 NTIA contract. Description of how you have tested or evaluated the 1321 workability of any new technical or operational methods proposed in 1322 this document and how they compare to established arrangements. 1323 Description of how long the proposals in Section III are expected to 1324 take to complete, and any intermediate milestones that may occur 1325 before they are completed. 1327 V. NTIA Requirements 1329 Additionally, NTIA has established that the transition proposal must 1330 meet the following five requirements: 1331 o Support and enhance the multistakeholder model; 1332 o Maintain the security, stability, and resiliency of the Internet 1333 DNS; 1334 o Meet the needs and expectation of the global customers and 1335 partners of the IANA functions; 1336 o Maintain the openness of the Internet; 1337 o The proposal must not replace the NTIA role with a government-led 1338 or an inter-governmental organization solution. 1340 This section should explain how your community's proposal meets these 1341 requirements and how it responds to the global interest in the IANA 1342 functions. 1344 VI. Community Process 1345 This section should describe the process your community used for 1346 developing this proposal, including: 1347 o The steps that were taken to develop the proposal and to determine 1348 consensus. 1349 o Links to announcements, agendas, mailing lists, consultations and 1350 meeting proceedings. 1351 o An assessment of the level of consensus behind your community's 1352 proposal, including a description of areas of contention or 1353 disagreement. 1355 Authors' Addresses 1357 Eliot Lear (editor) 1358 Richtistrasse 7 1359 Wallisellen, ZH CH-8304 1360 Switzerland 1362 Phone: +41 44 878 9200 1363 Email: lear@cisco.com 1364 Russ Housley (editor) 1365 918 Spring Noll Drive 1366 Herndon, VA 20170 1367 USA 1369 Email: housley@vigilsec.com