idnits 2.17.1 draft-ietf-ianaplan-icg-response-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2016) is 2822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 1456 == Missing Reference: 'Internal-cg' is mentioned on line 1706, but not defined -- Duplicate reference: RFC2026, mentioned in 'RFC2026', was also mentioned in 'BCP9info'. -- Duplicate reference: RFC2860, mentioned in 'RFC2860', was also mentioned in 'MOUSUP'. ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6220 (Obsoleted by RFC 8722) == Outdated reference: A later version (-20) exists of draft-leiba-cotton-iana-5226bis-16 -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IANAPLAN E. Lear, Ed. 3 Internet-Draft 4 Intended status: Informational R. Housley, Ed. 5 Expires: January 29, 2017 July 28, 2016 7 Response to the IANA Stewardship Transition Coordination Group (ICG) 8 Request for Proposals on the IANA protocol parameters registries 9 draft-ietf-ianaplan-icg-response-10 11 Abstract 13 The U.S. NTIA solicited a request from ICANN to propose how the NTIA 14 should end its oversight of the IANA functions. After broad 15 consultations, ICANN in turn created the IANA Stewardship Transition 16 Coordination Group. That group solicited proposals for thre three 17 major IANA functions: names, numbers, and protocol parameters. This 18 document contains the IETF response to that solicitation for protocol 19 parameters. It was included in an aggregate response to the NTIA 20 alongside those for names and numbering resources that are being 21 developed by their respective operational communities. A reference 22 to that response may be found in the introduction, and additional 23 correspendence is included in the Appendix. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 29, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 63 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 67 7.2. Informative References . . . . . . . . . . . . . . . . . 22 68 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 23 69 A.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 23 70 A.2. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 23 71 A.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 23 72 A.4. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 24 73 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 24 74 A.6. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 24 75 A.7. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 24 76 A.8. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 25 77 A.9. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 25 78 Appendix B. The Charter of the IANA Stewardship Coordination 79 Group (ICG) . . . . . . . . . . . . . . . . . . . . 25 80 Appendix C. IANA Stewardship Transition Coordination Group 81 Request for Proposals . . . . . . . . . . . . . . . 28 82 Appendix D. Correspondence of the IETF to the ICG . . . . . . . 34 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 85 1. IETF Introduction 87 In March of 2014 the U.S. National Telecommunications & Information 88 Administration (NTIA) announced its intent to transition oversight of 89 Internet Assigned Numbers Authority (IANA) functions [NTIA-Announce]. 90 In that announcement, NTIA asked the Internet Corporation for 91 Assigned Names and Numbers (ICANN) to establish a process to deliver 92 a proposal for transition. As part of that process, the IANA 93 Stewardship Transition Coordination Group (ICG) was formed. The 94 charter for the ICG can be found in Appendix B. The ICG in turn 95 solicited proposals regarding post-transition arrangements from the 96 names, numbers, and protocol parameters communities in order to put 97 forth a proposal to the NTIA. The final request for proposal (RFP) 98 can be found in Appendix C. The response from the ICG to the NTIA 99 may be found at [ICG-Response]. 101 While there are interactions between all of the IANA functions and 102 IETF standards, this document specifically addresses the protocol 103 parameters registries function. Section 1 (this section) contains an 104 introduction that is sourced solely within the IETF. Section 2 105 contains the questionnaire that was written by the ICG and a formal 106 response by the IETF. We have quoted questions from that 107 questionnaire with ">>> ", and we have prefaced answers to questions 108 being asked with "IETF Response:". Note that there are small changes 109 to the questions asked in order to match the RFC format. 111 We note that the following text was stated as footnote in the 112 original RFP: 114 In this RFP, "IANA" refers to the functions currently 115 specified in the agreement between NTIA and ICANN 116 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as 117 well as any other functions traditionally performed by the IANA 118 functions operator. SAC-067 119 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 120 provides one description of the many different meanings of the 121 term "IANA" and may be useful reading in addition to the 122 documents constituting the agreement itself. 124 2. The Formal RFP Response 126 The entire Request for Proposals, including introduction, can be 127 found in Appendix C. 129 >>> 130 >>> 0. Proposal Type 131 >>> 132 >>> Identify which category of the IANA functions this 133 >>> submission proposes to address: 134 >>> 136 IETF Response: 137 Protocol Parameters 139 This response states the existing practice of the IETF, and also 140 represents the views of the Internet Architecture Board and the IETF. 142 >>> 143 >>> I. Description of Community's Use of IANA Functions 144 >>> 145 >>> This section should list the specific, distinct IANA services 146 >>> or activities your community relies on. For each IANA service 147 >>> or activity on which your community relies, please provide the 148 >>> following: 149 >>> A description of the service or activity. 150 >>> 152 IETF Response: 154 Many IETF protocols make use of commonly defined protocol parameters. 155 These parameters are used by implementers, who are the primary users 156 of the IETF standards and other documents. To ensure consistent 157 interpretation of these parameter values by independent 158 implementations, and to promote universal interoperability, these 159 IETF protocol specifications define and require globally available 160 registries containing the parameter values and a pointer to any 161 associated documentation. The IETF uses the IANA protocol parameters 162 registries to store this information in a public location. The IETF 163 community presently accesses the protocol parameter registries via 164 references based on the iana.org domain name, and makes use of the 165 term "IANA" in the protocol parameter registry processes [RFC5226]. 167 ICANN currently operates the .ARPA top level domain on behalf of the 168 Internet Architecture Board (IAB). This zone is used for certain 169 Internet infrastructure services that are delegated beneath it. The 170 IETF considers .ARPA part of the protocol parameters registries for 171 purposes of this response. 173 >>> 174 >>> A description of the customer(s) of the service or activity. 175 >>> 177 IETF Response: 179 The IANA protocol parameters registries operator maintains the 180 protocol parameters registries for the IETF in conformance with all 181 relevant IETF policies, in accordance with the Memorandum of 182 Understanding [RFC2860] and associated supplemental agreements that 183 include service level agreements (SLAs) established between the IETF 184 and ICANN [MOUSUP]. 186 The IETF is a global organization that produces voluntary standards, 187 whose mission is to produce high quality, relevant technical and 188 engineering documents that influence the way people design, use, and 189 manage the Internet in such a way as to make the Internet work better 191 [RFC3935]. IETF standards are published in the RFC series. The IETF 192 is responsible for the key standards that are used on the Internet 193 today, including IP, TCP, DNS, BGP, and HTTP, to name but a few. 195 The IETF operates in an open and transparent manner [RFC6852]. The 196 processes that govern the IETF are also published in the RFC series. 197 The Internet Standards Process is documented in [RFC2026]. That 198 document explains not only how standards are developed, but also how 199 disputes about decisions are resolved. RFC 2026 has been amended a 200 number of times [BCP9info]. The standards process can be amended in 201 the same manner that standards are approved. That is, someone 202 proposes a change by submitting a temporary document known as an 203 Internet-Draft, the community discusses it, and if rough consensus 204 can be found the change is approved by the Internet Engineering 205 Steering Group (IESG), who also have day-to-day responsibility for 206 declaring IETF consensus on technical decisions, including those that 207 affect the IANA protocol parameters registries. Anyone may propose a 208 change during a Last Call, and anyone may participate in the 209 community discussion. 211 >>> 212 >>> What registries are involved in providing the service or 213 >>> activity. 214 >>> 216 IETF Response: 218 The protocol parameters registries are the product of IETF work. 219 These also include the top-level registry for the entire IP address 220 space and some of its sub-registries, autonomous system number space, 221 and a number of special use registries with regard to domain names. 222 For more detail please refer to the documentation in the "overlaps or 223 interdependencies" section. 225 Administration of the protocol parameters registries is the service 226 that is provided to the IETF. 228 >>> 229 >>> A description of any overlaps or interdependencies between your 230 >>> IANA requirements and the functions required by other customer 231 >>> communities. 232 >>> 234 IETF Response: 236 In this context, the IETF considers "overlap" to be where there is in 237 some way shared responsibility for a single registry across multiple 238 organizations. In this sense, there is no overlap between 239 organizations because responsibility for each registry is carefully 240 delineated. There are, however, points of interaction between other 241 organizations, and a few cases where the IETF may further define the 242 scope of a registry for technical purposes. This is the case with 243 both names and numbers, as described in the paragraphs below. In all 244 cases, the IETF coordinates with the appropriate organizations. 246 It is important to note that the IETF does not have formal 247 membership. The term "the IETF" includes anyone who wishes to 248 participate in the IETF, and IETF participants may also be members of 249 other communities. Staff and participants from ICANN and the 250 Regional Internet Registries (RIRs) regularly participate in IETF 251 activities. 253 o The IETF has specified a number of special use registries with 254 regard to domain names. These registries require coordination 255 with ICANN as the policy authority for the DNS root, including 256 community groups that are responsible for ICANN policy on domain 257 names such as the Generic Names Supporting Organization (GNSO) and 258 the Country Code Names Supporting Organization (ccNSO). There are 259 already mechanisms in place to perform this coordination, and the 260 capacity to modify those mechanisms to meet new conditions as they 261 might arise. [RFC6761] 263 o The IETF specifies the DNS protocol. From time to time there have 264 been and will be updates to that protocol. As we make changes we 265 will broadly consult the operational community about the impact of 266 those changes, as we have done in the past. 268 o The IETF specifies minimum requirements for root servers. 269 [RFC2870] Those requirements are currently under review, in 270 consultations with the root server community. 272 o The routing architecture has evolved over time, and is expected to 273 continue to do so. Such evolution may have an impact on 274 appropriate IP address allocation strategies. If and when that 275 happens, the IETF will consult and coordinate with the RIR 276 community, as we have done in the past. 278 o The IETF is responsible for policy relating to the entire IP 279 address space and AS number space. Through the IANA protocol 280 parameters registries, the IETF delegates unicast IP address and 281 AS number ranges to the RIRs [RFC7020],[RFC7249]. Special address 282 allocation, such as multicast and anycast addresses, often require 283 coordination. Another example of IP addresses that are not 284 administered by the RIR system is Unique Local Addresses (ULAs) 285 [RFC4193], where local networks employ a prefix that is not 286 intended to be routed on the public Internet. New special address 287 allocations are added, from time to time, related to the evolution 288 of the standards. In all cases, these special assignments are 289 listed in the IANA protocol paramters registries. 291 o The IETF maintains sub-registries for special IPv4 and IPv6 292 assignments. These are specified in [RFC3307], [RFC5771], and 293 [RFC6890]. The IETF coordinates such assignments with the RIRs. 295 o Changes to IETF standards may have impact on operations of RIRs 296 and service providers. A recent example is the extensions to BGP 297 to carry the Autonomous System numbers as four-octet entities 298 [RFC6793]. It is important to note that this change occurred out 299 of operational necessity, and it demonstrated strong alignment 300 between the RIRs and the IETF. 302 >>> II. Existing, Pre-Transition Arrangements 304 >>> 305 >>> This section should describe how existing IANA-related 306 >>> arrangements work, prior to the transition. 307 >>> 308 >>> A. Policy Sources 309 >>> 310 >>> 311 >>> This section should identify the specific source(s) of policy 312 >>> which must be followed by the IANA functions operator in its 313 >>> conduct of the services or activities described above. If there 314 >>> are distinct sources of policy or policy development for 315 >>> different IANA activities, then please describe these 316 >>> separately. For each source of policy or policy development, 317 >>> please provide the following: 318 >>> 319 >>> Which IANA service or activity (identified in Section I) is 320 >>> affected. 321 >>> 323 IETF Response: The protocol parameters registries. 325 >>> 326 >>> A description of how policy is developed and established and 327 >>> who is involved in policy development and establishment. 328 >>> 330 IETF Response: 332 Policy for overall management of the protocol parameters registries 333 is stated in [RFC6220] and [RFC5226]. The first of these documents 334 explains the model for how the registries are to be operated, how 335 policy is set, and how oversight takes place. RFC 5226 specifies the 336 policies that specification writers may employ when they define new 337 protocol registries in the "IANA Considerations" section of each 338 specification. All policies at the IETF begin with a proposal in the 339 form of an Internet-Draft. Anyone may submit such a proposal. If 340 there is sufficient interest, a working group whose scope includes 341 the proposed work may choose to adopt it, the IESG may choose to 342 create a working group, or an Area Director may choose to sponsor the 343 draft. In any case, anyone may comment on the proposal as it 344 progresses. A proposal cannot be passed by the IESG unless it enjoys 345 sufficient community support as to indicate rough consensus 346 [RFC7282]. In each case, a "Last Call" is made so that there is 347 notice of any proposed change to a policy or process. Anyone may 348 comment during a Last Call. For example, this process is currently 349 being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis]. 351 >>> 352 >>> A description of how disputes about policy are resolved. 353 >>> 355 IETF Response: 357 Most disputes are handled at the lowest level through the working 358 group and rough consensus processes. Should anyone disagree with any 359 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 360 resolution and appeals process that includes the responsible Area 361 Director, the IESG, and the IAB. Should appeals be upheld, an 362 appropriate remedy is applied. In the case where someone claims that 363 the procedures themselves are insufficient or inadequate in some way 364 to address a circumstance, one may appeal an IAB decision to the 365 Internet Society Board of Trustees. 367 >>> 368 >>> References to documentation of policy development and dispute 369 >>> resolution processes. 370 >>> 372 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 373 conflict resolution and appeals process. [RFC2418] specifies working 374 group procedures. Note that both of these documents have been 375 amended in later RFCs as indicated in the [RFC-INDEX]. 377 >>> 378 >>> B. Oversight and Accountability 379 >>> 380 >>> This section should describe all the ways in which oversight is 381 >>> conducted over IANA functions operator's provision of the 382 >>> services and activities listed in Section I and all the ways in 383 >>> which IANA functions operator is currently held accountab le for 384 >>> the provision of those services. For each oversight or 385 >>> accountability mechanism, please provide as many of the 386 >>> following as are applicable: 387 >>> 388 >>> Which IANA service or activity (identified in Section I) is 389 >>> affected. 390 >>> 392 IETF Response: the protocol parameters registries. 394 >>> 395 >>> If not all policy sources identified in Section II.A are 396 >>> affected, identify which ones are affected. 397 >>> 399 IETF Response: All policy sources relating to the protocol parameters 400 registry are affected. 402 >>> 403 >>> A description of the entity or entities that provide oversight 404 >>> or perform accountability functions, including how individuals 405 >>> are selected or removed from participation in those entities. 406 >>> 408 IETF Response: 410 The Internet Architecture Board (IAB) is an oversight body of the 411 IETF whose responsibilities include, among other things, confirming 412 appointment of IESG members, managing appeals as discussed above, 413 management of certain domains, including .ARPA [RFC3172], and general 414 architectural guidance to the broader community. The IAB must 415 approve the appointment of an organization to act as IANA operator on 416 behalf of the IETF. The IAB is also responsible for establishing 417 liaison relationships with other organizations on behalf of the IETF. 418 The IAB's charter is to be found in [RFC2850]. 420 The IAB members are selected and may be recalled through a Nominating 421 Committee (NOMCOM) process, which is described in [RFC3777] and its 422 updates. This process provides for selection of active members of 423 the community who themselves agree upon a slate of candidates. The 424 active members are chosen randomly from volunteers with a history of 425 participation in the IETF, with limits regarding having too many 426 active members with the same affiliation. The selection of the 427 active members is performed in a manner that makes it possible for 428 anyone to verify that the correct procedure was followed. The slate 429 of candidates selected by the active members are sent to the Internet 430 Society Board of Trustees for confirmation. In general, members are 431 appointed for terms of two years. The IAB selects its own chair. 433 The IAB provides oversight of the protocol parameters registries of 434 the IETF, and is responsible for selecting appropriate operator(s) 435 and related per-registry arrangements. Especially when relationships 436 among protocols call for it, registries are at times operated by, or 437 in conjunction with, other bodies. Unless the IAB or IETF has 438 concluded that special treatment is needed, the operator for 439 registries is currently ICANN. 441 >>> 442 >>> A description of the mechanism (e.g., contract, reporting 443 >>> scheme, auditing scheme, etc.). This should include a 444 >>> description of the consequences of the IANA functions operator 445 >>> not meeting the standards established by the mechanism, the 446 >>> extent to which the output of the mechanism is transparent and 447 >>> the terms under which the mechanism may change. 448 >>> 450 IETF Response: 452 A memorandum of understanding (MoU) between ICANN and the IETF 453 community has been in place since 2000. It can be found in 454 [RFC2860]. The MoU defines the work to be carried out by the IANA 455 functions operator for the IETF and the Internet Research Task Force 456 (IRTF), a peer organization to the IETF that focuses on 457 research.[RFC2014] Each year a service level agreement is negotiated 458 that supplements the MoU. 460 Day-to-day administration and contract management is the 461 responsibility of the IETF Administrative Director (IAD). The IETF 462 Administrative Oversight Committee (IAOC) oversees the IAD. The 463 members of the IAOC are also the trustees of the IETF Trust, whose 464 main purpose is to hold certain intellectual property for the benefit 465 of the IETF as a whole. IAOC members are appointed by the Internet 466 Society Board of Trustees, the IAB, the IESG, and the NOMCOM 467 [RFC4071]. The IAOC works with the IANA functions operator to 468 establish annual IANA performance metrics [METRICS] and operational 469 procedures, and the resulting document is adopted as an supplement to 470 the MoU each year [MOUSUP]. Starting from 2014, in accordance with 471 these supplements, an annual audit is performed to ensure that 472 protocol parameter requests are being processed according to the 473 established policies. The conclusions of this audit will be 474 available for anyone in the world to review. 476 To date there have been no unresolvable disputes or issues between 477 the IETF and the current IANA functions operator. [RFC2860] 478 specifies that should a technical dispute arise, "the IANA shall seek 479 and follow technical guidance exclusively from the IESG." In the 480 unlikely event that a more difficult situation should arise, the IAOC 481 and the IAB would engage ICANN management to address the matter. The 482 MoU also provides an option for either party to terminate the 483 arrangement with six months notice. Obviously such action would only 484 be undertaken after serious consideration. In that case a new IANA 485 functions operator would be selected, and a new agreement with that 486 operator would be established. 488 >>> 489 >>> Jurisdiction(s) in which the mechanism applies and the legal 490 >>> basis on which the mechanism rests. 491 >>> 493 IETF Response 495 This mechanism is global in nature. The current agreement does not 496 specify a jurisdiction. 498 >>>III. Proposed Post-Transition Oversight and Accountability 499 Arrangements 501 >>> 502 >>> This section should describe what changes your community is 503 >>> proposing to the arrangements listed in Section II.B in light of 504 >>> the transition. If your community is proposing to replace one or 505 >>> more existing arrangements with new arrangements, that 506 >>> replacement should be explained and all of the elements listed 507 >>> in Section II.B should be described for the new 508 >>> arrangements. Your community should provide its rationale and 509 >>> justification for the new arrangements. 510 >>> 511 >>> If your community's proposal carries any implications for 512 >>> existing policy arrangements described in Section II.A, those 513 >>> implications should be described here. 514 >>> 515 >>> If your community is not proposing changes to arrangements 516 >>> listed in Section II.B, the rationale and justification for that 517 >>> choice should be provided here. 518 >>> 520 IETF Response: 522 No new organizations or structures are required. Over the years 523 since the creation of ICANN, the IETF, ICANN, and IAB have together 524 created a system of agreements, policies, and oversight mechanisms 525 that already cover what is needed. This system has worked well 526 without any operational involvement from the NTIA. 528 IANA protocol parameters registry updates will continue to function 529 day-to-day, as they have been doing for the last decade or more. The 530 IETF community is very satisfied with the current arrangement with 531 ICANN. RFC 2860 remains in force and has served the IETF community 532 very well. RFC 6220 has laid out an appropriate service description 533 and requirements. 535 However in the absence of the NTIA contract a few new arrangements 536 may be needed in order to ensure the IETF community's expectations 537 are met. Those expectations are the following: 539 o The protocol parameters registries are in the public domain. It 540 is the preference of the IETF community that all relevant parties 541 acknowledge that fact as part of the transition. 543 o It is possible in the future that the operation of the protocol 544 parameters registries may be transitioned from ICANN to subsequent 545 operator(s). It is the preference of the IETF community that, as 546 part of the NTIA transition, ICANN acknowledge that it will carry 547 out the obligations established under C.7.3 and I.61 of the 548 current IANA functions contract between ICANN and the NTIA 549 [NTIA-Contract] to achieve a smooth transition to subsequent 550 operator(s), should the need arise. Furthermore, in the event of 551 a transition it is the expectation of the IETF community that 552 ICANN, the IETF, and subsequent operator(s) will work together to 553 minimize disruption in the use the protocol parameters registries 554 or other resources currently located at iana.org. 556 In developing our response we have been mindful of the following 557 points that the IETF community has discussed over the last year 558 [ProtoParamEvo14] that have led to the following guiding principles 559 for IAB efforts that impact IANA protocol parameter registries. 560 These principles must be taken together; their order is not 561 significant. 563 1. The IETF protocol parameters registries function has been and 564 continues to be capably provided by the Internet technical community. 566 The strength and stability of the function and its foundation within 567 the Internet technical community are both important given how 568 critical protocol parameters are to the proper functioning of IETF 569 protocols. 571 We think the structures that sustain the protocol parameters 572 registries function need to be strong enough that they can be offered 573 independently by the Internet technical community, without the need 574 for backing from external parties. And we believe we largely are 575 there already, although the system can be strengthened further, and 576 continuous improvements are being made. 578 2. The protocol parameters registries function requires openness, 579 transparency, and accountability. 581 Existing documentation of how the function is administered and 582 overseen is good [RFC2860], [RFC6220]. Further articulation and 583 clarity may be beneficial. It is important that the whole Internet 584 community can understand how the function works, and that the 585 processes for registering parameters and holding those who oversee 586 the protocol parameters function accountable for following those 587 processes are understood by all interested parties. We are committed 588 to making improvements here if necessary. 590 3. Any contemplated changes to the protocol parameters registries 591 function should respect existing Internet community agreements. 593 The protocol parameters registries function is working well. The 594 existing Memorandum of Understanding in RFC 2860 defines "the 595 technical work to be carried out by the Internet Assigned Numbers 596 Authority on behalf of the Internet Engineering Task Force and the 597 Internet Research Task Force." Any modifications to the protocol 598 parameters registries function should be made using the IETF process 599 to update RFC 6220 and other relevant RFCs. Put quite simply: 600 evolution, not revolution. 602 4. The Internet architecture requires and receives capable service 603 by Internet registries. 605 The stability of the Internet depends on capable provision of not 606 just IETF protocol parameters, but IP numbers, domain names, and 607 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 608 protocols. Thus we expect the role of the IETF in standards 609 development, architectural guidance, and allocation of certain name/ 610 number parameters to continue. IP multicast addresses and special- 611 use DNS names are two examples where close coordination is needed. 612 The IETF will continue to coordinate with ICANN, the RIRs, and other 613 parties that are mutually invested in the continued smooth operation 614 of the Internet registries. We fully understand the need to work 615 together. 617 5. The IETF will continue management of the protocol parameter 618 registry function as an integral component of the IETF standards 619 process and the use of resulting protocols. 621 RFC 6220 specifies the role and function of the protocol parameters 622 registry, which is critical to IETF standards processes and IETF 623 protocols. The IAB, on behalf of the IETF, has the responsibility to 624 define and manage the relationship with the protocol registry 625 operator role. This responsibility includes the selection and 626 management of the protocol parameter registry operator, as well as 627 management of the parameter registration process and the guidelines 628 for parameter allocation. 630 6. The protocol parameters registries are provided as a public 631 service. 633 Directions for the creation of protocol parameters registries and the 634 policies for subsequent additions and updates are specified in RFCs. 635 The protocol parameters registries are available to everyone, and 636 they are published in a form that allows their contents to be 637 included in other works without further permission. These works 638 include, but are not limited to, implementations of Internet 639 protocols and their associated documentation. 641 These principles will guide the IAB, IAOC, and the rest of the IETF 642 community as they work with ICANN to establish future IANA 643 performance metrics and operational procedures. 645 >>> IV Transition Implications 647 >>> 648 >>> This section should describe what your community views as the 649 >>> implications of the changes it proposed in Section III. These 650 >>> implications may include some or all of the following, or other 651 >>> implications specific to your community: 652 >>> 653 >>> o Description of operational requirements to achieve continuity 654 >>> of service and possible new service integration throughout 655 >>> the transition. 656 >>> o Risks to operational continuity 657 >>> o Description of any legal framework requirements in the 658 >>> absence of the NTIA contract 659 >>> o Description of how you have tested or evaluated the 660 >>> workability of any new technical or operational methods 661 >>> proposed in this document and how they compare to established 662 >>> arrangements. 663 >>> 664 IETF Response: 666 No structural changes are required for the handling of protocol 667 parameters. The principles listed above will guide IAB, IAOC, and 668 the rest of the IETF community as they work with ICANN to establish 669 future IANA performance metrics and operational procedures, as they 670 have in the past. 672 As no services are expected to change, no continuity issues are 673 anticipated, and there are no new technical or operational methods 674 proposed by the IETF to test. The IETF leadership, ICANN, and the 675 RIRs maintain an ongoing informal dialog to spot any unforeseen 676 issues that might arise as a result of other changes. 678 What is necessary as part of transition is the completion of any 679 supplemental agreement(s) necessary to achieve the requirements 680 outlined in our response in Section III of this RFP. 682 >>> 683 >>> V. NTIA Requirements 684 >>> 685 >>> Additionally, NTIA has established that the transition proposal 686 >>> must meet the following five requirements: 687 >>> 688 >>> "Support and enhance the multistakeholder model;" 689 >>> 691 IETF Response: 693 Because the IETF is open to everyone, participation is open to all 694 stakeholders. IETF processes outlined in Section I were used to 695 develop this proposal. Those same processes have been and shall be 696 used to amend governance of the protocol parameters function. As 697 mentioned previously, anyone may propose amendments to those 698 processes, and anyone may take part in the decision process. 700 >>> 701 >>> "Maintain the security, stability, and resiliency of the 702 >>> Internet DNS;" 703 >>> 705 IETF Response: 707 No changes are proposed in this document that affect the security, 708 stability, and resiliency of the DNS. 710 >>> 711 >>> "Meet the needs and expectation of the global customers and 712 >>> partners of the IANA services;" 713 >>> 715 IETF Response: 717 Implementers and their users from around the world make use of the 718 IETF standards and the associated IANA protocol parameters 719 registries. The current IANA protocol parameters registries system 720 is meeting the needs of these global customers. This proposal 721 continues to meet their needs by maintaining the existing processes 722 that have served them well in the past. 724 >>> 726 >>> 727 >>> "Maintain the openness of the Internet." 728 >>> 730 IETF Response: 732 This proposal maintains the existing open framework that allows 733 anyone to participate in the development of IETF standards, including 734 the IANA protocol parameters registries policies. Further, an 735 implementer anywhere in the world has full access to the protocol 736 specification published in the RFC series and the protocol parameters 737 registries published at iana.org. Those who require assignments in 738 the IANA protocol registries will continue to have their requests 739 satisfied, as specified by the existing policies for those 740 registries. 742 >>> 743 >>> "The proposal must not replace the NTIA role with a 744 >>> government-led or an inter-governmental organization solution." 745 >>> 747 Policy oversight is performed by the IAB, which is neither a 748 government-led or an intergovernmental organization. 750 >>> 751 >>> VI. Community Process 752 >>> 753 >>> This section should describe the process your community used for 754 >>> developing this proposal, including: 755 >>> 756 >>> o The steps that were taken to develop the proposal and to 757 >>> determine consensus. 758 >>> 760 IETF Response: 762 The IESG established the IANAPLAN working group to develop this 763 response. Anyone was welcome to join the discussion and participate 764 in the development of this response. An open mailing list 765 (ianaplan@ietf.org) has been associated with the working group. In 766 addition, IETF's IANA practices have been discussed in the broader 767 community, and all input has been welcome. Normal IETF procedures 768 [RFC2026] [RFC2418] were used to determine rough consensus. The 769 chairs of the working group reviewed open issues and, after an 770 internal working group last call, determined that all had been 771 satisfactorily addressed, and subsequently the IESG did a formal 772 IETF-wide Last Call followed by a formal review and determined that 773 the document had rough consensus. 775 >>> 776 >>> Links to announcements, agendas, mailing lists, consultations and 777 >>> meeting proceedings. 778 >>> 780 IETF Response: 782 The following list is not exhaustive, as there have been many open 783 discussions about this transition within the IETF community in the 784 past few months. 786 Creation of an open mailing list to discuss the transition: 787 http://mailarchive.ietf.org/arch/msg/ietf-announce/Ztd2ed9U04qSxI- 788 k9-Oj80jJLXc 790 Announcement of a public session on the transition: 791 http://mailarchive.ietf.org/arch/msg/ietf-announce/ 792 M5zVmFFvTbtgVyMB_fjUSW4rJ0c 794 Announcement by the IESG of the intent to form a working group: 795 http://mailarchive.ietf.org/arch/msg/ietf-announce/ 796 QsvU9qX98G2KqB18jy6UfhwKjXk 798 The working group discussion: http://www.ietf.org/mail- 799 archive/web/ianaplan/current/maillist.html 801 2014-10-06 Interim Meeting Agenda, Minutes, and presentations: 802 http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/ 803 proceedings.html 805 Working group last call: http://mailarchive.ietf.org/arch/msg/ianapl 806 an/EGF9rfJxn5QpQnRXmS2QxYKYR8k 808 Agenda from IETF 91 IANAPLAN WG meeting: 809 http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan 811 Minutes of IETF 91 IANAPLAN WG meeting: 812 http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan 814 Shepherd write-up: http://datatracker.ietf.org/doc/draft-ietf- 815 ianaplan-icg-response/shepherdwriteup/ 817 IETF last call: http://mailarchive.ietf.org/arch/msg/ietf-announce/ 818 i5rx6PfjJCRax3Lu4qZ_38P8wBg 820 >>> 821 >>> An assessment of the level of consensus behind your community's 822 >>> proposal, including a description of areas of contention or 823 >>> disagreement. 824 >>> 826 IETF Response: 828 This document has attained rough consensus of the IETF Working Group 829 and of the IETF community as a whole, as judged first by the working 830 group chairs and then by the sponsoring Area Director, and then by 831 the IESG in accordance with [RFC2026] during the 18 December 2014 832 IESG telechat. The IESG has approved the draft, pending insertion of 833 this answer in this section and the IAB approval note. The IAB 834 approved a statement for inclusion in the document on 19 December 835 2014. 837 Over the course of the development of the document, several 838 suggestions were raised that did not enjoy sufficient support to be 839 included. Two general areas of suggestion that generated much 840 discussion were 842 o A suggestion for a stronger statement over what terms the IAOC 843 should negotiate. 845 o A suggestion that "iana.org" and other associated marks be 846 transferred to the IETF trust. 848 At the end of the working group process, although there was not 849 unanimous support for the results, the working group chairs concluded 850 that rough consensus existed in the working group. The document 851 shepherd's summary of the WG consensus for this document can be found 852 here: 854 https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ 855 shepherdwriteup/ 857 During IETF last call, additional people voiced support for the 858 document. There were several editorial comments that resulted in 859 changes, as well as some discussion of more substantial comments some 860 of which resulted in text changes. There was some discussion of 861 comments already discussed earlier in the process, and but no new 862 objections were raised during the IETF last call. A summary of the 863 last call comments can be found from here: 865 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html 867 New draft versions were prepared that took into account all the 868 agreed changes from the last call. The final version was then 869 approved by the IESG. 871 3. IANA Considerations 873 This memo is a response to a request for proposals. No parameter 874 allocations or changes are sought. 876 4. Security Considerations 878 While the agreement, supplements, policies, and procedures around the 879 IANA function have shown strong resiliency, the IETF will continue to 880 work with all relevant parties to facilitate improvements while 881 maintaining availability of the IANA registries. 883 5. IAB Note 885 The IAB supports the response in this document. 887 6. Acknowledgments 889 This document describes processes that have been developed by many 890 members of the community over many years. The initial version of 891 this document was developed collaboratively through both the IAB IANA 892 Strategy Program and the IETF IANAPLAN WG. Particular thanks go to 893 Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John 894 Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John 895 Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew 896 Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf. 898 7. References 900 7.1. Normative References 902 [BCP9info] 903 "Information on "The Internet Standards Process -- 904 Revision 3"", . 906 [METRICS] "Performance Standards Metrics Report", 907 . 909 [MOUSUP] "Supplements to RFC 2860 (the Memorandum of Understanding 910 between the IETF and ICANN)", 911 . 913 [NTIA-Announce] 914 "NTIA Announcement of Intent to Transition Key Internet 915 Domain Name Functions", March 2014, 916 . 920 [NTIA-Contract] 921 "The NTIA Contract with ICANN", 922 . 925 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 926 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 927 . 929 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 930 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 931 September 1998, . 933 [RFC2850] Internet Architecture Board and B. Carpenter, Ed., 934 "Charter of the Internet Architecture Board (IAB)", 935 BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, 936 . 938 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 939 Understanding Concerning the Technical Work of the 940 Internet Assigned Numbers Authority", RFC 2860, 941 DOI 10.17487/RFC2860, June 2000, 942 . 944 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 945 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 946 . 948 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 949 and Recall Process: Operation of the Nominating and Recall 950 Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, 951 . 953 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 954 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 955 . 957 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 958 IETF Administrative Support Activity (IASA)", BCP 101, 959 RFC 4071, DOI 10.17487/RFC4071, April 2005, 960 . 962 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 963 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 964 DOI 10.17487/RFC5226, May 2008, 965 . 967 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 968 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 969 DOI 10.17487/RFC5771, March 2010, 970 . 972 [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., 973 Huston, G., Ed., and Internet Architecture Board, 974 "Defining the Role and Function of IETF Protocol Parameter 975 Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April 976 2011, . 978 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 979 RFC 6761, DOI 10.17487/RFC6761, February 2013, 980 . 982 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 983 "Special-Purpose IP Address Registries", BCP 153, 984 RFC 6890, DOI 10.17487/RFC6890, April 2013, 985 . 987 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 988 RFC 7282, DOI 10.17487/RFC7282, June 2014, 989 . 991 7.2. Informative References 993 [I-D.leiba-cotton-iana-5226bis] 994 Cotton, M., Leiba, B., and D. Narten, "Guidelines for 995 Writing an IANA Considerations Section in RFCs", draft- 996 leiba-cotton-iana-5226bis-16 (work in progress), June 997 2016. 999 [ICG-Response] 1000 "Proposal to Transition the Stewardship of the Internet 1001 Assigned Numbers Authority (IANA) Functions from the U.S. 1002 Commerce Department's National Telecommunications and 1003 Information Administration (NTIA) to the Global 1004 Multistakeholder Community", March 2016, 1005 . 1008 [ProtoParamEvo14] 1009 "IAB statement on Guiding the Evolution of the IANA 1010 Protocol Parameter Registries", March 2014, 1011 . 1014 [RFC-INDEX] 1015 RFC Editor, , "Index of all Requests for Comments", 1016 RFC Index, August 2014. 1018 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 1019 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 1020 October 1996, . 1022 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 1023 Name Server Operational Requirements", RFC 2870, 1024 DOI 10.17487/RFC2870, June 2000, 1025 . 1027 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1028 Requirements for the Address and Routing Parameter Area 1029 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1030 September 2001, . 1032 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1033 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1034 . 1036 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1037 Autonomous System (AS) Number Space", RFC 6793, 1038 DOI 10.17487/RFC6793, December 2012, 1039 . 1041 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. 1042 St.Amour, "Affirmation of the Modern Paradigm for 1043 Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013, 1044 . 1046 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 1047 Internet Numbers Registry System", RFC 7020, 1048 DOI 10.17487/RFC7020, August 2013, 1049 . 1051 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, 1052 DOI 10.17487/RFC7249, May 2014, 1053 . 1055 Appendix A. Changes 1057 NOTE: This section to be removed by RFC Editor at publication. 1059 A.1. Changes from -08 to -09 1061 o Update URL for summary of the IETF Last Call. 1063 o Two minor editorial improvements. 1065 A.2. Changes from -07 to -08 1067 o Update text describing the consensus process. 1069 o Insert IAB approval text. 1071 o Point to the proceedings of IETF 91 for IANAPLAN WG agenda and 1072 minutes. 1074 A.3. Changes from -06 to -07 1076 o Merge "No new changes are needed" with "No new organizations or 1077 structures are required". Fewer words to say the same thing. 1079 o consult to consult and coordinate. 1081 o RFC Editor comments. 1083 o Edits resulting from Security Area review by Sean Turner. 1085 o Edits resulting from AD comments. 1087 A.4. Changes from -05 to -06 1089 o Inclusion of agreed substantial comments from the AD. 1091 o Editorial changes. 1093 A.5. Changes from -04 to -05 1095 o Change to simpler text for answer about stability and security. 1097 o Mention of RFC 5226bis. 1099 A.6. Changes from -03 to -04 1101 o Additional text regarding what is needed in Section III. 1103 o Appropriate language modifications in section IV to match the 1104 above changes in III. 1106 o Acknowledgments edits. 1108 A.7. Changes from -02 to -03 1110 o Terminology consistency. 1112 o Add IAB section. 1114 o Changes based on WG discussion on what we prefer as part of the 1115 transition regarding IPR. 1117 o Add discussion about .ARPA domain. 1119 o Elaboration of what registries are involved. 1121 o Additional text around coordination with ICANN. 1123 o Working groups can adopt items within their charters. 1125 o IAB appointments generally last two years. 1127 o Add mention of the Trust. 1129 o Security Considerations update. 1131 A.8. Changes from -01 to -02 1133 o A better description special registries and BGP ASNs. 1135 o Clarity on how the address space and ASNs are delegated. 1137 o Many editorials corrected. 1139 o Mention of the annual review as part of the SLAs. 1141 o Change about how overlap is presented. 1143 o A number of small wording changes based on feedback. 1145 A.9. Changes from -00 to -01 1147 o Front matter greatly reduced. 1149 o Appendices with charter and RFP added. 1151 o Jurisdiction text changed. 1153 o Proposed changes include supplemental agreement(s) to address 1154 jurisdiction, dispute resolution, and IPR, including names and 1155 marks. 1157 o Transition implications slightly modified to reference 1158 supplemental agreement. 1160 Appendix B. The Charter of the IANA Stewardship Coordination Group 1161 (ICG) 1163 Charter for the IANA Stewardship Transition Coordination Group V.10 1165 (August 27, 2014) 1167 The IANA stewardship transition coordination group (ICG) has one 1168 deliverable: a proposal to the U.S. Commerce Department National 1169 Telecommunications and Information Administration (NTIA) regarding 1170 the transition of NTIA's stewardship of the IANA functions to the 1171 global multi-stakeholder community. The group will conduct itself 1172 transparently, consult with a broad range of stakeholders, and ensure 1173 that its proposals support the security and stability of the IANA 1174 functions. 1176 The group's mission is to coordinate the development of a proposal 1177 among the communities affected by the IANA functions. The IANA 1178 functions are divided into three main categories: domain names, 1179 number resources, and other protocol parameters. The domain names 1180 category falls further into the country code and generic domain name 1181 sub-categories. While there is some overlap among all of these 1182 categories, each poses distinct organizational, operational and 1183 technical issues, and each tends to have distinct communities of 1184 interest and expertise. For those reasons it is best to have work on 1185 the three categories of IANA parameters proceed autonomously in 1186 parallel and be based in the respective communities. 1188 The IANA stewardship transition process is taking place alongside a 1189 parallel and related process on enhancing ICANN accountability. 1190 While maintaining the accountability of Internet identifier 1191 governance is central to both processes, this group's scope is 1192 focused on the arrangements required for the continuance of IANA 1193 functions in an accountable and widely accepted manner after the 1194 expiry of the NTIA-ICANN contract. Nevertheless, the two processes 1195 are interrelated and interdependent and should appropriately 1196 coordinate their work. 1198 The coordination group has four main tasks: 1199 (i) Act as liaison to all interested parties, including the three 1200 "operational communities" (i.e., those with direct operational 1201 or service relationship with IANA; namely names, numbers, 1202 protocol parameters). This task consists of: 1203 a. Soliciting proposals from the operational communities 1204 b. Soliciting the input of the broad group of communities 1205 affected by the IANA functions 1206 (ii) Assess the outputs of the three operational communities for 1207 compatibility and interoperability 1208 (iii) Assemble a complete proposal for the transition 1209 (iv) Information sharing and public communication 1210 Describing each in more detail: 1211 (i) Liaison 1212 a. Solicit proposals 1214 The ICG expects a plan from the country code and generic name 1215 communities (possibly a joint one), a plan from the numbers 1216 community, and a plan from the protocol parameters community. 1217 Members of the ICG will ensure that the communities from which they 1218 are drawn are working on their part of the transition plans. This 1219 involves informing them of requirements and schedules, tracking 1220 progress, and highlighting the results or remaining issues. The role 1221 of a coordination group member during this phase is to provide status 1222 updates about the progress of his or her community in developing 1223 their component, and to coordinate which community will develop a 1224 transition proposal for each area of overlap (e.g., special-use 1225 registry). 1227 While working on the development of their proposals, the operational 1228 communities are expected to address common requirements and issues 1229 relating to the transition, in as far as they affect their parts of 1230 the stewardship of IANA functions. 1232 b. Solicit broader input 1234 The ICG is open for input and feedback from all interested parties. 1235 While no set of formal requirements related to a transition proposal 1236 will be requested outside the operational communities, everyone's 1237 input is welcome across all topics. 1239 The ICG expects that all interested parties get involved as early as 1240 possible in the relevant community processes. Input received 1241 directly by the ICG may be referred to the relevant community 1242 discussion. 1244 The ICG members chosen from a particular community are the official 1245 communication channel between the ICG and that community. 1247 (ii) Assessment 1249 When the group receives output from the communities it will discuss 1250 and assess their compatibility and interoperability with the 1251 proposals of the other communities. Each proposal should be 1252 submitted with a clear record of how consensus has been reached for 1253 the proposal in the community, and provide an analysis that shows the 1254 proposal is in practice workable. The ICG should also compile the 1255 input it has received beyond the operational communities, and review 1256 the impacts of this input. 1258 The ICG might at some point detect problems with the component 1259 proposals. At that point the role of the ICG is to communicate that 1260 back to the relevant communities so that they (the relevant 1261 communities) can address the issues. It is not in the role of the 1262 ICG to develop proposals or to select from among competing proposals. 1264 (iii) Assembling and submitting a complete proposal 1266 The assembly effort involves taking the proposals for the different 1267 components and verifying that the whole fulfills the intended scope, 1268 meets the intended criteria, that there are no missing parts, and 1269 that the whole fits together. The whole also needs to include 1270 sufficient independent accountability mechanisms for running the IANA 1271 function. The ICG will then develop a draft final proposal that 1272 achieves rough consensus within the ICG itself. The ICG will then 1273 put this proposal up for public comment involving a reasonable period 1274 of time for reviewing the draft proposal, analyzing and preparing 1275 supportive or critical comments. The ICG will then review these 1276 comments and determine whether modifications are required. If no 1277 modifications are needed, and the coordination group agrees, the 1278 proposal will be submitted to NTIA. 1280 If changes are required to fix problems or to achieve broader 1281 support, the ICG will work with the operational communities in a 1282 manner similar to what was described in task (ii) above. Updates are 1283 subject to the same verification, review, and consensus processes as 1284 the initial proposals. If, in the ICG's opinion, broad public 1285 support for the proposal as articulated by the NTIA is not present, 1286 the parts of the proposal that are not supported return to the 1287 liaison phase. 1289 (iv) Information sharing 1291 The ICG serves as a central clearinghouse for public information 1292 about the IANA stewardship transition process. Its secretariat 1293 maintains an independent, publicly accessible and open website, under 1294 its own domain, where status updates, meetings and notices are 1295 announced, proposals are stored, the ICG members are listed, etc. As 1296 the development of the transition plans will take some time, it is 1297 important that information about ongoing work is distributed early 1298 and continuously. This will enable sharing of ideas and the 1299 detection of potential issues. 1301 Appendix C. IANA Stewardship Transition Coordination Group Request for 1302 Proposals 1304 IANA Stewardship Transition Coordination Group Request for Proposals 1306 8 September 2014 1308 Introduction 1310 Under the IANA Stewardship Transition Coordination Group (ICG) 1311 Charter, the ICG has four main tasks: 1313 (i) Act as liaison to all interested parties in the IANA 1314 stewardship transition, including the three "operational 1315 communities" (i.e., those with direct operational or service 1316 relationships with the IANA functions operator; namely names, 1317 numbers, protocol parameters). This task consists of: 1319 a. Soliciting proposals from the operational communities 1320 b. Soliciting the input of the broad group of communities 1321 affected by the IANA functions 1323 (ii) Assess the outputs of the three operational communities for 1324 compatibility and interoperability 1326 (iii) Assemble a complete 1327 proposal for the transition 1329 (iv) Information sharing and public communication 1331 This Request for Proposals (RFP) addresses task (i) of the ICG 1332 Charter. This RFP does not preclude any form of input from the 1333 non-operational communities. 1335 0. Complete Formal Responses 1337 The IANA Stewardship Transition Coordination Group (ICG) seeks 1338 complete formal responses to this RFP through processes which are to 1339 be convened by each of the "operational communities" of IANA (i.e., 1340 those with direct operational or service relationships with the IANA 1341 functions operator, in connection with names, numbers, or protocol 1342 parameters). 1344 Proposals should be supported by the broad range of stakeholders 1345 participating in the proposal development process. Proposals should 1346 be developed through a transparent process that is open to and 1347 inclusive of all stakeholders interested in participating in the 1348 development of the proposal. In order to help the ICG maintain its 1349 light coordination role, all interested and affected parties are 1350 strongly encouraged to participate directly in these community 1351 processes. 1353 The following link provides information about ongoing community 1354 processes and how to participate in them, and that will continue to 1355 be updated over time: 1357 https://www.icann.org/en/stewardship/community 1359 In this RFP, "IANA" refers to the functions currently specified in 1360 the agreement between NTIA and ICANN 1361 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 1362 as any other functions traditionally performed by the IANA functions 1363 operator. SAC-067 1365 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 1366 provides one description of the many different meanings of the term 1367 "IANA" and may be useful reading in addition to the documents 1368 constituting the agreement itself. 1370 Communities are asked to adhere to open and inclusive processes in 1371 developing their responses, so that all community members may fully 1372 participate in and observe those processes. Communities are also 1373 asked to actively seek out and encourage wider participation by any 1374 other parties with interest in their response. 1376 A major challenge of the ICG will be to identify and help to 1377 reconcile differences between submitted proposals, in order to 1378 produce a single plan for the transition of IANA 1379 stewardship. Submitted Proposals should therefore focus on those 1380 elements that are considered to be truly essential to the transition 1381 of their specific IANA functions. The target deadline for all 1382 complete formal responses to this RFP is 15 January 2015. 1384 I. Comments 1386 While the ICG is requesting complete formal proposals through 1387 processes convened by each of the operational communities, and that 1388 all interested parties get involved as early as possible in the 1389 relevant community processes, some parties may choose to provide 1390 comments directly to the ICG about specific aspects of particular 1391 proposals, about the community processes, or about the ICG's own 1392 processes. Comments may be directly submitted to the ICG any time 1393 via email to icg-forum@icann.org. Comments will be publicly archived 1394 at . 1396 Commenters should be aware that ICG will direct comments received to 1397 the relevant operational communities if appropriate. The ICG will 1398 review comments received as time and resources permit and in 1399 accordance with the overall timeline for the transition. That is, 1400 comments received about specific proposals may not be reviewed until 1401 those proposals have been submitted to the ICG. The ICG may 1402 establish defined public comment periods about specific topics in 1403 the future, after the complete formal responses to the RFP have been 1404 received. 1406 Required Proposal Elements 1408 The ICG encourages each community to submit a single proposal that 1409 contains the elements described in this section. 1411 Communities are requested to describe the elements delineated in the 1412 sections below in as much detail possible, and according to the 1413 suggested format/structure, to allow the ICG to more easily 1414 assimilate the results. While each question is narrowly defined to 1415 allow for comparison between answers, respondents are encouraged to 1416 provide further information in explanatory sections, including 1417 descriptive summaries of policies/practices and associated 1418 references to source documents of specific policies/practices. In 1419 this way, the responses to the questionnaire will be useful at the 1420 operational level as well as to the broader stakeholder communities. 1422 In the interest of completeness and consistency, proposals should 1423 cross-reference wherever appropriate the current IANA Functions 1424 Contract[3] when describing existing arrangements and proposing 1425 changes to existing arrangements. 1427 0. Proposal type 1429 Identify which category of the IANA functions this submission 1430 proposes to address: 1431 [ ] Names [ ] Numbers [ ] Protocol Parameters 1433 I. Description of Community's Use of IANA Functions 1435 This section should list the specific, distinct IANA functions your 1436 community relies on. For each IANA function on which your community 1437 relies, please provide the following: 1439 o A description of the function; 1440 o A description of the customer(s) of the function; 1441 o What registries are involved in providing the function; 1442 o A description of any overlaps or interdependencies between your 1443 IANA requirements and the functions required by other customer 1444 communities. 1446 If your community relies on any other IANA service or activity 1447 beyond the scope of the IANA functions contract, you may describe 1448 them here. In this case please also describe how the service or 1449 activity should be addressed by the transition plan. 1451 II. Existing, Pre-Transition Arrangements 1453 This section should describe how existing IANA-related arrangements 1454 work, prior to the transition. 1456 [3] http://www.ntia.doc.gov/files/ntia/ 1457 publications/sf_26_pg_1-2-final_award_and_sacs.pdf 1459 A. Policy Sources 1461 This section should identify the specific source(s) of policy which 1462 must be followed by the IANA functions operator in its conduct of 1463 the services or activities described above. If there are distinct 1464 sources of policy or policy development for different IANA 1465 functions, then please describe these separately. For each source of 1466 policy or policy development, please provide the following: 1468 o Which IANA function (identified in Section I) are affected. 1469 o A description of how policy is developed and established and who 1470 is involved in policy development and establishment. 1471 o A description of how disputes about policy are resolved. 1472 o References to documentation of policy development and dispute 1473 resolution processes. 1475 B. Oversight and Accountability 1477 This section should describe all the ways in which oversight is 1478 conducted over the IANA functions operator's provision of the 1479 services and activities listed in Section I and all the ways in 1480 which the IANA functions operator is currently held accountable for 1481 the provision of those services. For each oversight or 1482 accountability mechanism, please provide as many of the following as 1483 are applicable: 1485 Which IANA functions (identified in Section I) are affected. If the 1486 policy sources identified in Section II.A are affected, identify 1487 which ones are affected and explain in what way. 1489 o A description of the entity or entities that provide oversight or 1490 perform accountability functions, including how individuals are 1491 selected or removed from participation in those entities. 1492 o A description of the mechanism (e.g., contract, reporting scheme, 1493 auditing scheme, etc.). This should include a description of the 1494 consequences of the IANA functions operator not meeting the 1495 standards established by the mechanism, the extent to which the 1496 output of the mechanism is transparent and the terms under which 1497 the mechanism may change. 1498 o Jurisdiction(s) in which the mechanism applies and the legal basis 1499 on which the mechanism rests. 1501 III. Proposed Post-Transition Oversight and Accountability 1502 Arrangements 1504 This section should describe what changes your community is 1505 proposing to the arrangements listed in Section II.B in light of the 1506 transition. If your community is proposing to replace one or more 1507 existing arrangements with new arrangements, that replacement should 1508 be explained and all of the elements listed in Section II.B should 1509 be described for the new arrangements. Your community should provide 1510 its rationale and justification for the new arrangements. 1512 If your community's proposal carries any implications for the 1513 interface between the IANA functions and existing policy arrangements 1514 described in Section II.A, those implications should be described 1515 here. 1517 If your community is not proposing changes to arrangements listed in 1518 Section II.B, the rationale and justification for that choice should 1519 be provided here. 1521 IV. Transition Implications 1523 This section should describe what your community views as the 1524 implications of the changes it proposed in Section III. These 1525 implications may include some or all of the following, or other 1526 implications specific to your community: 1528 Description of operational requirements to achieve continuity of 1529 service and possible new service integration throughout the 1530 transition. 1532 Risks to operational continuity and how they will be addressed. 1533 Description of any legal framework requirements in the absence of the 1534 NTIA contract. Description of how you have tested or evaluated the 1535 workability of any new technical or operational methods proposed in 1536 this document and how they compare to established arrangements. 1537 Description of how long the proposals in Section III are expected to 1538 take to complete, and any intermediate milestones that may occur 1539 before they are completed. 1541 V. NTIA Requirements 1543 Additionally, NTIA has established that the transition proposal must 1544 meet the following five requirements: 1545 o Support and enhance the multistakeholder model; 1546 o Maintain the security, stability, and resiliency of the Internet 1547 DNS; 1548 o Meet the needs and expectation of the global customers and 1549 partners of the IANA functions; 1550 o Maintain the openness of the Internet; 1551 o The proposal must not replace the NTIA role with a government-led 1552 or an inter-governmental organization solution. 1554 This section should explain how your community's proposal meets these 1555 requirements and how it responds to the global interest in the IANA 1556 functions. 1558 VI. Community Process 1559 This section should describe the process your community used for 1560 developing this proposal, including: 1562 o The steps that were taken to develop the proposal and to determine 1563 consensus. 1564 o Links to announcements, agendas, mailing lists, consultations and 1565 meeting proceedings. 1566 o An assessment of the level of consensus behind your community's 1567 proposal, including a description of areas of contention or 1568 disagreement. 1570 Appendix D. Correspondence of the IETF to the ICG 1572 The following messages were sent to the ICG: 1574 From: Jari Arkko 1575 Subject: Re: [Internal-cg] Question from the ICG 1576 Date: 20 Feb 2015 23:46:20 GMT+2 1577 To: Alissa Cooper , ICG 1578 Cc: Izumi Okutani 1580 Dear Alissa and the ICG, 1582 We refer to the question that the ICG asked the IETF community 1583 on 9 Feb 2015 1585 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html 1587 > The numbers proposal sees these changes as a requirement of the 1588 > transition and the protocols parameters proposal does not. If 1589 these 1590 > aspects of the proposals are perceived as incompatible would the 1591 numbers 1592 > and protocol parameters communities be willing to modify their 1593 proposals 1594 > to reconcile them? 1596 We do not observe incompatibilities between the proposals from the 1597 numbers and protocol parameters communities. The numbers 1598 community expresses a preference to transfer the trademark and 1599 domain, while the IETF proposal does not oppose such transfer. 1600 This is not an incompatibility, it is something that can be 1601 satisfied by implementation of both number and protocol 1602 parameters community's proposals, as already specified. 1604 To confirm this, and to determine whether the transfer 1605 of the trademark and domain would be acceptable, 1606 we consulted the community. It is the opinion of the 1607 IANAPLAN working group that they would support a 1608 decision by the IETF Trust to hold the trademark and domain 1609 on behalf of the Internet community. For details, see 1610 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html 1612 The IETF Trust also looked at this issue. The trustees decided that 1613 the IETF Trust would be willing to hold intellectual property rights 1614 relating to the IANA function, including the IANA trademark and the 1615 IANA.ORG domain name. For details, see 1616 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html 1618 In short, we find no incompatibility between the proposals and no 1619 need to modify the protocol parameters proposal. 1621 Best Regards, 1622 Jari Arkko and Russ Housley on behalf of the IETF community and 1623 the IETF Trust 1625 From: Jari Arkko 1626 Subject: [Internal-cg] IETF response to the time frame inquiry 1627 Date: 5 Jun 2015 13:39:50 GMT+3 1628 To: Alissa Cooper 1629 Cc: ICG 1631 This is a response to a query regarding transition finalisation and 1632 implementation time frames, sent to the IANAPLAN working 1633 group list by the chairs of the IANA Transition Coordination 1634 Group (ICG) on May 27th. 1636 While I am carrying this response back to the ICG, the substance 1637 of this response has been discussed in the IANAPLAN working 1638 group and the relevant parts of IETF leadership. I believe this 1639 response represents the (rough) consensus opinion that 1640 emerged in the discussion, as well as the current state 1641 of IANA arrangement updates that our leadership bodies 1642 have been working on. 1644 The IETF is ready today to take the next steps in the 1645 implementation of the transition of the stewardship. 1646 In our case, most of the necessary framework is already 1647 in place and implemented in preceding years. 1649 The remaining step is an updated agreement with 1650 ICANN which addresses two issues. These issues are 1651 outlined in Section 2.III in the Internet Draft 1652 draft-ietf-ianaplan-icg-response-09.txt: 1654 o The protocol parameters registries are in the public domain. It 1655 is the preference of the IETF community that all relevant parties 1656 acknowledge that fact as part of the transition. 1658 o It is possible in the future that the operation of the protocol 1659 parameters registries may be transitioned from ICANN to subsequent 1660 operator(s). It is the preference of the IETF community that, as 1661 part of the NTIA transition, ICANN acknowledge that it will carry 1662 out the obligations established under C.7.3 and I.61 of the 1663 current IANA functions contract between ICANN and the NTIA 1664 [NTIA-Contract] to achieve a smooth transition to subsequent 1665 operator(s), should the need arise. Furthermore, in the event of 1666 a transition it is the expectation of the IETF community that 1667 ICANN, the IETF, and subsequent operator(s) will work together to 1668 minimize disruption in the use of the protocol parameters registries 1669 or other resources currently located at iana.org. 1671 The IETF Administrative Oversight Committee (IAOC) has 1672 decided to use an update of our yearly IETF-ICANN Service Level 1673 Agreement (SLA) as the mechanism for this updated 1674 agreement. They have drafted the update and from our 1675 perspective it could be immediately executed. Once the updated 1676 agreement is in place, the transition would be substantially 1677 complete, with only the NTIA contract lapse or termination 1678 as a final step. 1680 Of course, we are not alone in this process. Interactions 1681 with other parts of the process may bring additional 1682 tasks that need to be executed either before or 1683 after the transition. First, the ICG, the RIRs, 1684 and IETF have discussed the possibility of aligning 1685 the treatment of IANA trademarks and domains. The 1686 IETF Trust has signalled that it would be willing to do this, 1687 if asked. We are awaiting coordination on this 1688 to complete, but see no problem in speedy 1689 execution once the decision is made. From our 1690 perspective this is not a prerequisite for the transition, 1691 however. 1693 In addition, the names community has proposed the 1694 creation of a 'Post Transition IANA' (PTI). If the existing 1695 agreements between the IETF and ICANN remain in place 1696 and the SLAs discussed above are not affected, the IETF 1697 transition would take place as described above. That is 1698 our preference. If the final details of the PTI plan require 1699 further action from the IETF, more work and community 1700 agreement would be required. The timeline for that work 1701 cannot be set until the scope is known. 1703 Jari Arkko, IETF Chair 1704 (reporting his summary of the situation) 1705 From: Jari Arkko 1706 Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the 1707 ICG question on coordination 1708 Date: 8 Oct 2015 10:13:07 GMT+3 1709 To: IANA etc etc Coordination Group 1711 The IANAPLAN working group has discussed the coordination 1712 question from the ICG. In the working group's opinion, 1713 informal coordination exists today and will continue, which 1714 is consistent with the commitment requested by the ICG. 1716 This is also consistent with an overall coordination commitment 1717 already indicated in the IANAPLAN proposal. The proposal 1718 is a consensus document of the IETF. From the proposal: 1720 The IETF will continue to coordinate with ICANN, the RIRs, and other 1721 parties that are mutually invested in the continued smooth operation 1722 of the Internet registries. 1724 The coordination approach is also consistent with the 1725 comments that were sent by the IAB to the ICG during the 1726 public comment period. See 1727 https://www.iab.org/documents/correspondence-reports-documents/2015- 1728 2/iab-comments-on-icg-proposal/. 1730 Jari Arkko, 1731 IETF Chair and the Area Director for the IANAPLAN WG 1733 Authors' Addresses 1735 Eliot Lear (editor) 1736 Richtistrasse 7 1737 Wallisellen, ZH CH-8304 1738 Switzerland 1740 Phone: +41 44 878 9200 1741 Email: lear@cisco.com 1743 Russ Housley (editor) 1744 918 Spring Knoll Drive 1745 Herndon, VA 20170 1746 USA 1748 Email: housley@vigilsec.com