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