idnits 2.17.00 (12 Aug 2021) /tmp/idnits29687/draft-ietf-ianaplan-icg-response-09.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 (January 6, 2015) is 2692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 1417 -- 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: draft-leiba-cotton-iana-5226bis has been published as RFC 8126 -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) Summary: 4 errors (**), 0 flaws (~~), 2 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: July 10, 2015 6 January 6, 2015 8 Draft Response to the Internet Coordination Group Request for Proposals 9 on the IANA protocol parameters registries 10 draft-ietf-ianaplan-icg-response-09 12 Abstract 14 The U.S. NTIA has solicited a request from ICANN to propose how the 15 NTIA should end its oversight of the IANA functions. After broad 16 consultations, ICANN has in turn created the IANA Stewardship 17 Transition Coordination Group. That group solicited proposals for 18 thre three major IANA functions: names, numbers, and protocol 19 parameters. This document contains the IETF response to that 20 solicitation for protocol parameters. It is meant to be included in 21 an aggregate response to the NTIA alongside those for names and 22 numbering resources that are being developed by their respective 23 operational communities. 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 July 10, 2015. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . 21 68 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 22 69 A.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 22 70 A.2. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 22 71 A.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 23 72 A.4. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 23 73 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 23 74 A.6. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 23 75 A.7. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 23 76 A.8. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 24 77 A.9. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 24 78 Appendix B. The Charter of the IANA Stewardship Coordination 79 Group (ICG . . . . . . . . . . . . . . . . . . . . . 24 80 Appendix C. IANA Stewardship Transition Coordination Group 81 Request for Proposals . . . . . . . . . . . . . . . 27 82 Appendix D. Completed ICG response for the NTIA . . . . . . . . 33 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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. 100 While there are interactions between all of the IANA functions and 101 IETF standards, this document specifically addresses the protocol 102 parameters registries function. Section 1 (this section) contains an 103 introduction that is sourced solely within the IETF. Section 2 104 contains the questionnaire that was written by the ICG and a formal 105 response by the IETF. We have quoted questions from that 106 questionnaire with ">>> ", and we have prefaced answers to questions 107 being asked with "IETF Response:". Note that there are small changes 108 to the questions asked in order to match the RFC format. 110 We note that the following text was stated as footnote in the 111 original RFP: 113 In this RFP, "IANA" refers to the functions currently 114 specified in the agreement between NTIA and ICANN 115 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as 116 well as any other functions traditionally performed by the IANA 117 functions operator. SAC-067 118 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 119 provides one description of the many different meanings of the 120 term "IANA" and may be useful reading in addition to the 121 documents constituting the agreement itself. 123 2. The Formal RFP Response 125 The entire Request for Proposals, including introduction, can be 126 found in Appendix C. 128 >>> 129 >>> 0. Proposal Type 130 >>> 131 >>> Identify which category of the IANA functions this 132 >>> submission proposes to address: 133 >>> 135 IETF Response: 136 Protocol Parameters 138 This response states the existing practice of the IETF, and also 139 represents the views of the Internet Architecture Board and the IETF. 141 >>> 142 >>> I. Description of Community's Use of IANA Functions 143 >>> 144 >>> This section should list the specific, distinct IANA services 145 >>> or activities your community relies on. For each IANA service 146 >>> or activity on which your community relies, please provide the 147 >>> following: 148 >>> A description of the service or activity. 149 >>> 151 IETF Response: 153 Many IETF protocols make use of commonly defined protocol parameters. 154 These parameters are used by implementers, who are the primary users 155 of the IETF standards and other documents. To ensure consistent 156 interpretation of these parameter values by independent 157 implementations, and to promote universal interoperability, these 158 IETF protocol specifications define and require globally available 159 registries containing the parameter values and a pointer to any 160 associated documentation. The IETF uses the IANA protocol parameters 161 registries to store this information in a public location. The IETF 162 community presently accesses the protocol parameter registries via 163 references based on the iana.org domain name, and makes use of the 164 term "IANA" in the protocol parameter registry processes [RFC5226]. 166 ICANN currently operates the .ARPA top level domain on behalf of the 167 Internet Architecture Board (IAB). This zone is used for certain 168 Internet infrastructure services that are delegated beneath it. The 169 IETF considers .ARPA part of the protocol parameters registries for 170 purposes of this response. 172 >>> 173 >>> A description of the customer(s) of the service or activity. 174 >>> 176 IETF Response: 178 The IANA protocol parameters registries operator maintains the 179 protocol parameters registries for the IETF in conformance with all 180 relevant IETF policies, in accordance with the Memorandum of 181 Understanding [RFC2860] and associated supplemental agreements that 182 include service level agreements (SLAs) established between the IETF 183 and ICANN [MOUSUP]. 185 The IETF is a global organization that produces voluntary standards, 186 whose mission is to produce high quality, relevant technical and 187 engineering documents that influence the way people design, use, and 188 manage the Internet in such a way as to make the Internet work better 190 [RFC3935]. IETF standards are published in the RFC series. The IETF 191 is responsible for the key standards that are used on the Internet 192 today, including IP, TCP, DNS, BGP, and HTTP, to name but a few. 194 The IETF operates in an open and transparent manner [RFC6852]. The 195 processes that govern the IETF are also published in the RFC series. 196 The Internet Standards Process is documented in [RFC2026]. That 197 document explains not only how standards are developed, but also how 198 disputes about decisions are resolved. RFC 2026 has been amended a 199 number of times [BCP9info]. The standards process can be amended in 200 the same manner that standards are approved. That is, someone 201 proposes a change by submitting a temporary document known as an 202 Internet-Draft, the community discusses it, and if rough consensus 203 can be found the change is approved by the Internet Engineering 204 Steering Group (IESG), who also have day-to-day responsibility for 205 declaring IETF consensus on technical decisions, including those that 206 affect the IANA protocol parameters registries. Anyone may propose a 207 change during a Last Call, and anyone may participate in the 208 community discussion. 210 >>> 211 >>> What registries are involved in providing the service or 212 >>> activity. 213 >>> 215 IETF Response: 217 The protocol parameters registries are the product of IETF work. 218 These also include the top-level registry for the entire IP address 219 space and some of its sub-registries, autonomous system number space, 220 and a number of special use registries with regard to domain names. 221 For more detail please refer to the documentation in the "overlaps or 222 interdependencies" section. 224 Administration of the protocol parameters registries is the service 225 that is provided to the IETF. 227 >>> 228 >>> A description of any overlaps or interdependencies between your 229 >>> IANA requirements and the functions required by other customer 230 >>> communities. 231 >>> 233 IETF Response: 235 In this context, the IETF considers "overlap" to be where there is in 236 some way shared responsibility for a single registry across multiple 237 organizations. In this sense, there is no overlap between 238 organizations because responsibility for each registry is carefully 239 delineated. There are, however, points of interaction between other 240 organizations, and a few cases where the IETF may further define the 241 scope of a registry for technical purposes. This is the case with 242 both names and numbers, as described in the paragraphs below. In all 243 cases, the IETF coordinates with the appropriate organizations. 245 It is important to note that the IETF does not have formal 246 membership. The term "the IETF" includes anyone who wishes to 247 participate in the IETF, and IETF participants may also be members of 248 other communities. Staff and participants from ICANN and the 249 Regional Internet Registries (RIRs) regularly participate in IETF 250 activities. 252 o The IETF has specified a number of special use registries with 253 regard to domain names. These registries require coordination 254 with ICANN as the policy authority for the DNS root, including 255 community groups that are responsible for ICANN policy on domain 256 names such as the Generic Names Supporting Organization (GNSO) and 257 the Country Code Names Supporting Organization (ccNSO). There are 258 already mechanisms in place to perform this coordination, and the 259 capacity to modify those mechanisms to meet new conditions as they 260 might arise. [RFC6761] 262 o The IETF specifies the DNS protocol. From time to time there have 263 been and will be updates to that protocol. As we make changes we 264 will broadly consult the operational community about the impact of 265 those changes, as we have done in the past. 267 o The IETF specifies minimum requirements for root servers. 268 [RFC2870] Those requirements are currently under review, in 269 consultations with the root server community. 271 o The routing architecture has evolved over time, and is expected to 272 continue to do so. Such evolution may have an impact on 273 appropriate IP address allocation strategies. If and when that 274 happens, the IETF will consult and coordinate with the RIR 275 community, as we have done in the past. 277 o The IETF is responsible for policy relating to the entire IP 278 address space and AS number space. Through the IANA protocol 279 parameters registries, the IETF delegates unicast IP address and 280 AS number ranges to the RIRs [RFC7020],[RFC7249]. Special address 281 allocation, such as multicast and anycast addresses, often require 282 coordination. Another example of IP addresses that are not 283 administered by the RIR system is Unique Local Addresses (ULAs) 284 [RFC4193], where local networks employ a prefix that is not 285 intended to be routed on the public Internet. New special address 286 allocations are added, from time to time, related to the evolution 287 of the standards. In all cases, these special assignments are 288 listed in the IANA protocol paramters registries. 290 o The IETF maintains sub-registries for special IPv4 and IPv6 291 assignments. These are specified in [RFC3307], [RFC5771], and 292 [RFC6890]. The IETF coordinates such assignments with the RIRs. 294 o Changes to IETF standards may have impact on operations of RIRs 295 and service providers. A recent example is the extensions to BGP 296 to carry the Autonomous System numbers as four-octet entities 297 [RFC6793]. It is important to note that this change occurred out 298 of operational necessity, and it demonstrated strong alignment 299 between the RIRs and the IETF. 301 >>> II. Existing, Pre-Transition Arrangements 303 >>> 304 >>> This section should describe how existing IANA-related 305 >>> arrangements work, prior to the transition. 306 >>> 307 >>> A. Policy Sources 308 >>> 309 >>> 310 >>> This section should identify the specific source(s) of policy 311 >>> which must be followed by the IANA functions operator in its 312 >>> conduct of the services or activities described above. If there 313 >>> are distinct sources of policy or policy development for 314 >>> different IANA activities, then please describe these 315 >>> separately. For each source of policy or policy development, 316 >>> please provide the following: 317 >>> 318 >>> Which IANA service or activity (identified in Section I) is 319 >>> affected. 320 >>> 322 IETF Response: The protocol parameters registries. 324 >>> 325 >>> A description of how policy is developed and established and 326 >>> who is involved in policy development and establishment. 327 >>> 329 IETF Response: 331 Policy for overall management of the protocol parameters registries 332 is stated in [RFC6220] and [RFC5226]. The first of these documents 333 explains the model for how the registries are to be operated, how 334 policy is set, and how oversight takes place. RFC 5226 specifies the 335 policies that specification writers may employ when they define new 336 protocol registries in the "IANA Considerations" section of each 337 specification. All policies at the IETF begin with a proposal in the 338 form of an Internet-Draft. Anyone may submit such a proposal. If 339 there is sufficient interest, a working group whose scope includes 340 the proposed work may choose to adopt it, the IESG may choose to 341 create a working group, or an Area Director may choose to sponsor the 342 draft. In any case, anyone may comment on the proposal as it 343 progresses. A proposal cannot be passed by the IESG unless it enjoys 344 sufficient community support as to indicate rough consensus 345 [RFC7282]. In each case, a "Last Call" is made so that there is 346 notice of any proposed change to a policy or process. Anyone may 347 comment during a Last Call. For example, this process is currently 348 being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis]. 350 >>> 351 >>> A description of how disputes about policy are resolved. 352 >>> 354 IETF Response: 356 Most disputes are handled at the lowest level through the working 357 group and rough consensus processes. Should anyone disagree with any 358 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 359 resolution and appeals process that includes the responsible Area 360 Director, the IESG, and the IAB. Should appeals be upheld, an 361 appropriate remedy is applied. In the case where someone claims that 362 the procedures themselves are insufficient or inadequate in some way 363 to address a circumstance, one may appeal an IAB decision to the 364 Internet Society Board of Trustees. 366 >>> 367 >>> References to documentation of policy development and dispute 368 >>> resolution processes. 369 >>> 371 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 372 conflict resolution and appeals process. [RFC2418] specifies working 373 group procedures. Note that both of these documents have been 374 amended in later RFCs as indicated in the [RFC-INDEX]. 376 >>> 377 >>> B. Oversight and Accountability 378 >>> 379 >>> This section should describe all the ways in which oversight is 380 >>> conducted over IANA functions operator's provision of the 381 >>> services and activities listed in Section I and all the ways in 382 >>> which IANA functions operator is currently held accountab le for 383 >>> the provision of those services. For each oversight or 384 >>> accountability mechanism, please provide as many of the 385 >>> following as are applicable: 386 >>> 387 >>> Which IANA service or activity (identified in Section I) is 388 >>> affected. 389 >>> 391 IETF Response: the protocol parameters registries. 393 >>> 394 >>> If not all policy sources identified in Section II.A are 395 >>> affected, identify which ones are affected. 396 >>> 398 IETF Response: All policy sources relating to the protocol parameters 399 registry are affected. 401 >>> 402 >>> A description of the entity or entities that provide oversight 403 >>> or perform accountability functions, including how individuals 404 >>> are selected or removed from participation in those entities. 405 >>> 407 IETF Response: 409 The Internet Architecture Board (IAB) is an oversight body of the 410 IETF whose responsibilities include, among other things, confirming 411 appointment of IESG members, managing appeals as discussed above, 412 management of certain domains, including .ARPA [RFC3172], and general 413 architectural guidance to the broader community. The IAB must 414 approve the appointment of an organization to act as IANA operator on 415 behalf of the IETF. The IAB is also responsible for establishing 416 liaison relationships with other organizations on behalf of the IETF. 417 The IAB's charter is to be found in [RFC2850]. 419 The IAB members are selected and may be recalled through a Nominating 420 Committee (NOMCOM) process, which is described in [RFC3777] and its 421 updates. This process provides for selection of active members of 422 the community who themselves agree upon a slate of candidates. The 423 active members are chosen randomly from volunteers with a history of 424 participation in the IETF, with limits regarding having too many 425 active members with the same affiliation. The selection of the 426 active members is performed in a manner that makes it possible for 427 anyone to verify that the correct procedure was followed. The slate 428 of candidates selected by the active members are sent to the Internet 429 Society Board of Trustees for confirmation. In general, members are 430 appointed for terms of two years. The IAB selects its own chair. 432 The IAB provides oversight of the protocol parameters registries of 433 the IETF, and is responsible for selecting appropriate operator(s) 434 and related per-registry arrangements. Especially when relationships 435 among protocols call for it, registries are at times operated by, or 436 in conjunction with, other bodies. Unless the IAB or IETF has 437 concluded that special treatment is needed, the operator for 438 registries is currently ICANN. 440 >>> 441 >>> A description of the mechanism (e.g., contract, reporting 442 >>> scheme, auditing scheme, etc.). This should include a 443 >>> description of the consequences of the IANA functions operator 444 >>> not meeting the standards established by the mechanism, the 445 >>> extent to which the output of the mechanism is transparent and 446 >>> the terms under which the mechanism may change. 447 >>> 449 IETF Response: 451 A memorandum of understanding (MoU) between ICANN and the IETF 452 community has been in place since 2000. It can be found in 453 [RFC2860]. The MoU defines the work to be carried out by the IANA 454 functions operator for the IETF and the Internet Research Task Force 455 (IRTF), a peer organization to the IETF that focuses on 456 research.[RFC2014] Each year a service level agreement is negotiated 457 that supplements the MoU. 459 Day-to-day administration and contract management is the 460 responsibility of the IETF Administrative Director (IAD). The IETF 461 Administrative Oversight Committee (IAOC) oversees the IAD. The 462 members of the IAOC are also the trustees of the IETF Trust, whose 463 main purpose is to hold certain intellectual property for the benefit 464 of the IETF as a whole. IAOC members are appointed by the Internet 465 Society Board of Trustees, the IAB, the IESG, and the NOMCOM 466 [RFC4071]. The IAOC works with the IANA functions operator to 467 establish annual IANA performance metrics [METRICS] and operational 468 procedures, and the resulting document is adopted as an supplement to 469 the MoU each year [MOUSUP]. Starting from 2014, in accordance with 470 these supplements, an annual audit is performed to ensure that 471 protocol parameter requests are being processed according to the 472 established policies. The conclusions of this audit will be 473 available for anyone in the world to review. 475 To date there have been no unresolvable disputes or issues between 476 the IETF and the current IANA functions operator. [RFC2860] 477 specifies that should a technical dispute arise, "the IANA shall seek 478 and follow technical guidance exclusively from the IESG." In the 479 unlikely event that a more difficult situation should arise, the IAOC 480 and the IAB would engage ICANN management to address the matter. The 481 MoU also provides an option for either party to terminate the 482 arrangement with six months notice. Obviously such action would only 483 be undertaken after serious consideration. In that case a new IANA 484 functions operator would be selected, and a new agreement with that 485 operator would be established. 487 >>> 488 >>> Jurisdiction(s) in which the mechanism applies and the legal 489 >>> basis on which the mechanism rests. 490 >>> 492 IETF Response 494 This mechanism is global in nature. The current agreement does not 495 specify a jurisdiction. 497 >>>III. Proposed Post-Transition Oversight and Accountability 498 Arrangements 500 >>> 501 >>> This section should describe what changes your community is 502 >>> proposing to the arrangements listed in Section II.B in light of 503 >>> the transition. If your community is proposing to replace one or 504 >>> more existing arrangements with new arrangements, that 505 >>> replacement should be explained and all of the elements listed 506 >>> in Section II.B should be described for the new 507 >>> arrangements. Your community should provide its rationale and 508 >>> justification for the new arrangements. 509 >>> 510 >>> If your community's proposal carries any implications for 511 >>> existing policy arrangements described in Section II.A, those 512 >>> implications should be described here. 513 >>> 514 >>> If your community is not proposing changes to arrangements 515 >>> listed in Section II.B, the rationale and justification for that 516 >>> choice should be provided here. 517 >>> 519 IETF Response: 521 No new organizations or structures are required. Over the years 522 since the creation of ICANN, the IETF, ICANN, and IAB have together 523 created a system of agreements, policies, and oversight mechanisms 524 that already cover what is needed. This system has worked well 525 without any operational involvement from the NTIA. 527 IANA protocol parameters registry updates will continue to function 528 day-to-day, as they have been doing for the last decade or more. The 529 IETF community is very satisfied with the current arrangement with 530 ICANN. RFC 2860 remains in force and has served the IETF community 531 very well. RFC 6220 has laid out an appropriate service description 532 and requirements. 534 However in the absence of the NTIA contract a few new arrangements 535 may be needed in order to ensure the IETF community's expectations 536 are met. Those expectations are the following: 538 o The protocol parameters registries are in the public domain. It 539 is the preference of the IETF community that all relevant parties 540 acknowledge that fact as part of the transition. 542 o It is possible in the future that the operation of the protocol 543 parameters registries may be transitioned from ICANN to subsequent 544 operator(s). It is the preference of the IETF community that, as 545 part of the NTIA transition, ICANN acknowledge that it will carry 546 out the obligations established under C.7.3 and I.61 of the 547 current IANA functions contract between ICANN and the NTIA 548 [NTIA-Contract] to achieve a smooth transition to subsequent 549 operator(s), should the need arise. Furthermore, in the event of 550 a transition it is the expectation of the IETF community that 551 ICANN, the IETF, and subsequent operator(s) will work together to 552 minimize disruption in the use the protocol parameters registries 553 or other resources currently located at iana.org. 555 In developing our response we have been mindful of the following 556 points that the IETF community has discussed over the last year 557 [ProtoParamEvo14] that have led to the following guiding principles 558 for IAB efforts that impact IANA protocol parameter registries. 559 These principles must be taken together; their order is not 560 significant. 562 1. The IETF protocol parameters registries function has been and 563 continues to be capably provided by the Internet technical community. 565 The strength and stability of the function and its foundation within 566 the Internet technical community are both important given how 567 critical protocol parameters are to the proper functioning of IETF 568 protocols. 570 We think the structures that sustain the protocol parameters 571 registries function need to be strong enough that they can be offered 572 independently by the Internet technical community, without the need 573 for backing from external parties. And we believe we largely are 574 there already, although the system can be strengthened further, and 575 continuous improvements are being made. 577 2. The protocol parameters registries function requires openness, 578 transparency, and accountability. 580 Existing documentation of how the function is administered and 581 overseen is good [RFC2860], [RFC6220]. Further articulation and 582 clarity may be beneficial. It is important that the whole Internet 583 community can understand how the function works, and that the 584 processes for registering parameters and holding those who oversee 585 the protocol parameters function accountable for following those 586 processes are understood by all interested parties. We are committed 587 to making improvements here if necessary. 589 3. Any contemplated changes to the protocol parameters registries 590 function should respect existing Internet community agreements. 592 The protocol parameters registries function is working well. The 593 existing Memorandum of Understanding in RFC 2860 defines "the 594 technical work to be carried out by the Internet Assigned Numbers 595 Authority on behalf of the Internet Engineering Task Force and the 596 Internet Research Task Force." Any modifications to the protocol 597 parameters registries function should be made using the IETF process 598 to update RFC 6220 and other relevant RFCs. Put quite simply: 599 evolution, not revolution. 601 4. The Internet architecture requires and receives capable service 602 by Internet registries. 604 The stability of the Internet depends on capable provision of not 605 just IETF protocol parameters, but IP numbers, domain names, and 606 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 607 protocols. Thus we expect the role of the IETF in standards 608 development, architectural guidance, and allocation of certain name/ 609 number parameters to continue. IP multicast addresses and special- 610 use DNS names are two examples where close coordination is needed. 611 The IETF will continue to coordinate with ICANN, the RIRs, and other 612 parties that are mutually invested in the continued smooth operation 613 of the Internet registries. We fully understand the need to work 614 together. 616 5. The IETF will continue management of the protocol parameter 617 registry function as an integral component of the IETF standards 618 process and the use of resulting protocols. 620 RFC 6220 specifies the role and function of the protocol parameters 621 registry, which is critical to IETF standards processes and IETF 622 protocols. The IAB, on behalf of the IETF, has the responsibility to 623 define and manage the relationship with the protocol registry 624 operator role. This responsibility includes the selection and 625 management of the protocol parameter registry operator, as well as 626 management of the parameter registration process and the guidelines 627 for parameter allocation. 629 6. The protocol parameters registries are provided as a public 630 service. 632 Directions for the creation of protocol parameters registries and the 633 policies for subsequent additions and updates are specified in RFCs. 634 The protocol parameters registries are available to everyone, and 635 they are published in a form that allows their contents to be 636 included in other works without further permission. These works 637 include, but are not limited to, implementations of Internet 638 protocols and their associated documentation. 640 These principles will guide the IAB, IAOC, and the rest of the IETF 641 community as they work with ICANN to establish future IANA 642 performance metrics and operational procedures. 644 >>> IV Transition Implications 646 >>> 647 >>> This section should describe what your community views as the 648 >>> implications of the changes it proposed in Section III. These 649 >>> implications may include some or all of the following, or other 650 >>> implications specific to your community: 651 >>> 652 >>> o Description of operational requirements to achieve continuity 653 >>> of service and possible new service integration throughout 654 >>> the transition. 655 >>> o Risks to operational continuity 656 >>> o Description of any legal framework requirements in the 657 >>> absence of the NTIA contract 658 >>> o Description of how you have tested or evaluated the 659 >>> workability of any new technical or operational methods 660 >>> proposed in this document and how they compare to established 661 >>> arrangements. 662 >>> 663 IETF Response: 665 No structural changes are required for the handling of protocol 666 parameters. The principles listed above will guide IAB, IAOC, and 667 the rest of the IETF community as they work with ICANN to establish 668 future IANA performance metrics and operational procedures, as they 669 have in the past. 671 As no services are expected to change, no continuity issues are 672 anticipated, and there are no new technical or operational methods 673 proposed by the IETF to test. The IETF leadership, ICANN, and the 674 RIRs maintain an ongoing informal dialog to spot any unforeseen 675 issues that might arise as a result of other changes. 677 What is necessary as part of transition is the completion of any 678 supplemental agreement(s) necessary to achieve the requirements 679 outlined in our response in Section III of this RFP. 681 >>> 682 >>> V. NTIA Requirements 683 >>> 684 >>> Additionally, NTIA has established that the transition proposal 685 >>> must meet the following five requirements: 686 >>> 687 >>> "Support and enhance the multistakeholder model;" 688 >>> 690 IETF Response: 692 Because the IETF is open to everyone, participation is open to all 693 stakeholders. IETF processes outlined in Section I were used to 694 develop this proposal. Those same processes have been and shall be 695 used to amend governance of the protocol parameters function. As 696 mentioned previously, anyone may propose amendments to those 697 processes, and anyone may take part in the decision process. 699 >>> 700 >>> "Maintain the security, stability, and resiliency of the 701 >>> Internet DNS;" 702 >>> 704 IETF Response: 706 No changes are proposed in this document that affect the security, 707 stability, and resiliency of the DNS. 709 >>> 710 >>> "Meet the needs and expectation of the global customers and 711 >>> partners of the IANA services;" 712 >>> 714 IETF Response: 716 Implementers and their users from around the world make use of the 717 IETF standards and the associated IANA protocol parameters 718 registries. The current IANA protocol parameters registries system 719 is meeting the needs of these global customers. This proposal 720 continues to meet their needs by maintaining the existing processes 721 that have served them well in the past. 723 >>> 725 >>> 726 >>> "Maintain the openness of the Internet." 727 >>> 729 IETF Response: 731 This proposal maintains the existing open framework that allows 732 anyone to participate in the development of IETF standards, including 733 the IANA protocol parameters registries policies. Further, an 734 implementer anywhere in the world has full access to the protocol 735 specification published in the RFC series and the protocol parameters 736 registries published at iana.org. Those who require assignments in 737 the IANA protocol registries will continue to have their requests 738 satisfied, as specified by the existing policies for those 739 registries. 741 >>> 742 >>> "The proposal must not replace the NTIA role with a 743 >>> government-led or an inter-governmental organization solution." 744 >>> 746 Policy oversight is performed by the IAB, which is neither a 747 government-led or an intergovernmental organization. 749 >>> 750 >>> VI. Community Process 751 >>> 752 >>> This section should describe the process your community used for 753 >>> developing this proposal, including: 754 >>> 755 >>> o The steps that were taken to develop the proposal and to 756 >>> determine consensus. 757 >>> 759 IETF Response: 761 The IESG established the IANAPLAN working group to develop this 762 response. Anyone was welcome to join the discussion and participate 763 in the development of this response. An open mailing list 764 (ianaplan@ietf.org) has been associated with the working group. In 765 addition, IETF's IANA practices have been discussed in the broader 766 community, and all input has been welcome. Normal IETF procedures 767 [RFC2026] [RFC2418] were used to determine rough consensus. The 768 chairs of the working group reviewed open issues and, after an 769 internal working group last call, determined that all had been 770 satisfactorily addressed, and subsequently the IESG did a formal 771 IETF-wide Last Call followed by a formal review and determined that 772 the document had rough consensus. 774 >>> 775 >>> Links to announcements, agendas, mailing lists, consultations and 776 >>> meeting proceedings. 777 >>> 779 IETF Response: 781 The following list is not exhaustive, as there have been many open 782 discussions about this transition within the IETF community in the 783 past few months. 785 Creation of an open mailing list to discuss the transition: 786 http://mailarchive.ietf.org/arch/msg/ietf-announce/Ztd2ed9U04qSxI- 787 k9-Oj80jJLXc 789 Announcement of a public session on the transition: 790 http://mailarchive.ietf.org/arch/msg/ietf-announce/ 791 M5zVmFFvTbtgVyMB_fjUSW4rJ0c 793 Announcement by the IESG of the intent to form a working group: 794 http://mailarchive.ietf.org/arch/msg/ietf-announce/ 795 QsvU9qX98G2KqB18jy6UfhwKjXk 797 The working group discussion: http://www.ietf.org/mail- 798 archive/web/ianaplan/current/maillist.html 800 2014-10-06 Interim Meeting Agenda, Minutes, and presentations: 801 http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/ 802 proceedings.html 804 Working group last call: http://mailarchive.ietf.org/arch/msg/ianapl 805 an/EGF9rfJxn5QpQnRXmS2QxYKYR8k 807 Agenda from IETF 91 IANAPLAN WG meeting: 808 http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan 810 Minutes of IETF 91 IANAPLAN WG meeting: 811 http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan 813 Shepherd write-up: http://datatracker.ietf.org/doc/draft-ietf- 814 ianaplan-icg-response/shepherdwriteup/ 816 IETF last call: http://mailarchive.ietf.org/arch/msg/ietf-announce/ 817 i5rx6PfjJCRax3Lu4qZ_38P8wBg 819 >>> 820 >>> An assessment of the level of consensus behind your community's 821 >>> proposal, including a description of areas of contention or 822 >>> disagreement. 823 >>> 825 IETF Response: 827 This document has attained rough consensus of the IETF Working Group 828 and of the IETF community as a whole, as judged first by the working 829 group chairs and then by the sponsoring Area Director, and then by 830 the IESG in accordance with [RFC2026] during the 18 December 2014 831 IESG telechat. The IESG has approved the draft, pending insertion of 832 this answer in this section and the IAB approval note. The IAB 833 approved a statement for inclusion in the document on 19 December 834 2014. 836 Over the course of the development of the document, several 837 suggestions were raised that did not enjoy sufficient support to be 838 included. Two general areas of suggestion that generated much 839 discussion were 841 o A suggestion for a stronger statement over what terms the IAOC 842 should negotiate. 844 o A suggestion that "iana.org" and other associated marks be 845 transferred to the IETF trust. 847 At the end of the working group process, although there was not 848 unanimous support for the results, the working group chairs concluded 849 that rough consensus existed in the working group. The document 850 shepherd's summary of the WG consensus for this document can be found 851 here: 853 https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ 854 shepherdwriteup/ 856 During IETF last call, additional people voiced support for the 857 document. There were several editorial comments that resulted in 858 changes, as well as some discussion of more substantial comments some 859 of which resulted in text changes. There was some discussion of 860 comments already discussed earlier in the process, and but no new 861 objections were raised during the IETF last call. A summary of the 862 last call comments can be found from here: 864 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html 866 New draft versions were prepared that took into account all the 867 agreed changes from the last call. The final version was then 868 approved by the IESG. 870 3. IANA Considerations 872 This memo is a response to a request for proposals. No parameter 873 allocations or changes are sought. 875 4. Security Considerations 877 While the agreement, supplements, policies, and procedures around the 878 IANA function have shown strong resiliency, the IETF will continue to 879 work with all relevant parties to facilitate improvements while 880 maintaining availability of the IANA registries. 882 5. IAB Note 884 The IAB supports the response in this document. 886 6. Acknowledgments 888 This document describes processes that have been developed by many 889 members of the community over many years. The initial version of 890 this document was developed collaboratively through both the IAB IANA 891 Strategy Program and the IETF IANAPLAN WG. Particular thanks go to 892 Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John 893 Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John 894 Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew 895 Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf. 897 7. References 899 7.1. Normative References 901 [BCP9info] 902 "Information on "The Internet Standards Process -- 903 Revision 3"", . 905 [METRICS] "Performance Standards Metrics Report", 906 . 908 [MOUSUP] "Supplements to RFC 2860 (the Memorandum of Understanding 909 between the IETF and ICANN)", 910 . 912 [NTIA-Announce] 913 "NTIA Announcement of Intent to Transition Key Internet 914 Domain Name Functions", March 2014, 915 . 919 [NTIA-Contract] 920 "The NTIA Contract with ICANN", 921 . 924 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 925 3", BCP 9, RFC 2026, October 1996. 927 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 928 Procedures", BCP 25, RFC 2418, September 1998. 930 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 931 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 932 May 2000. 934 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 935 Understanding Concerning the Technical Work of the 936 Internet Assigned Numbers Authority", RFC 2860, June 2000. 938 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 939 Addresses", RFC 3307, August 2002. 941 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 942 Recall Process: Operation of the Nominating and Recall 943 Committees", BCP 10, RFC 3777, June 2004. 945 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 946 95, RFC 3935, October 2004. 948 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 949 Administrative Support Activity (IASA)", BCP 101, RFC 950 4071, April 2005. 952 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 953 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 954 May 2008. 956 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 957 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 958 March 2010. 960 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and 961 Internet Architecture Board, "Defining the Role and 962 Function of IETF Protocol Parameter Registry Operators", 963 RFC 6220, April 2011. 965 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 966 RFC 6761, February 2013. 968 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 969 "Special-Purpose IP Address Registries", BCP 153, RFC 970 6890, April 2013. 972 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 973 7282, June 2014. 975 7.2. Informative References 977 [I-D.leiba-cotton-iana-5226bis] 978 Cotton, M., Leiba, B., and T. Narten, "Guidelines for 979 Writing an IANA Considerations Section in RFCs", draft- 980 leiba-cotton-iana-5226bis-11 (work in progress), November 981 2014. 983 [ProtoParamEvo14] 984 "IAB statement on Guiding the Evolution of the IANA 985 Protocol Parameter Registries", March 2014, 986 . 989 [RFC-INDEX] 990 RFC Editor, , "Index of all Requests for Comments", RFC 991 Index, August 2014. 993 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 994 and Procedures", BCP 8, RFC 2014, October 1996. 996 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 997 Name Server Operational Requirements", BCP 40, RFC 2870, 998 June 2000. 1000 [RFC3172] Huston, G., "Management Guidelines & Operational 1001 Requirements for the Address and Routing Parameter Area 1002 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 1004 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1005 Addresses", RFC 4193, October 2005. 1007 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1008 Autonomous System (AS) Number Space", RFC 6793, December 1009 2012. 1011 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. 1012 Amour, "Affirmation of the Modern Paradigm for Standards", 1013 RFC 6852, January 2013. 1015 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 1016 Internet Numbers Registry System", RFC 7020, August 2013. 1018 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 1019 2014. 1021 Appendix A. Changes 1023 NOTE: This section to be removed by RFC Editor at publication. 1025 A.1. Changes from -08 to -09 1027 o Update URL for summary of the IETF Last Call. 1029 o Two minor editorial improvements. 1031 A.2. Changes from -07 to -08 1033 o Update text describing the consensus process. 1035 o Insert IAB approval text. 1037 o Point to the proceedings of IETF 91 for IANAPLAN WG agenda and 1038 minutes. 1040 A.3. Changes from -06 to -07 1042 o Merge "No new changes are needed" with "No new organizations or 1043 structures are required". Fewer words to say the same thing. 1045 o consult to consult and coordinate. 1047 o RFC Editor comments. 1049 o Edits resulting from Security Area review by Sean Turner. 1051 o Edits resulting from AD comments. 1053 A.4. Changes from -05 to -06 1055 o Inclusion of agreed substantial comments from the AD. 1057 o Editorial changes. 1059 A.5. Changes from -04 to -05 1061 o Change to simpler text for answer about stability and security. 1063 o Mention of RFC 5226bis. 1065 A.6. Changes from -03 to -04 1067 o Additional text regarding what is needed in Section III. 1069 o Appropriate language modifications in section IV to match the 1070 above changes in III. 1072 o Acknowledgments edits. 1074 A.7. Changes from -02 to -03 1076 o Terminology consistency. 1078 o Add IAB section. 1080 o Changes based on WG discussion on what we prefer as part of the 1081 transition regarding IPR. 1083 o Add discussion about .ARPA domain. 1085 o Elaboration of what registries are involved. 1087 o Additional text around coordination with ICANN. 1089 o Working groups can adopt items within their charters. 1091 o IAB appointments generally last two years. 1093 o Add mention of the Trust. 1095 o Security Considerations update. 1097 A.8. Changes from -01 to -02 1099 o A better description special registries and BGP ASNs. 1101 o Clarity on how the address space and ASNs are delegated. 1103 o Many editorials corrected. 1105 o Mention of the annual review as part of the SLAs. 1107 o Change about how overlap is presented. 1109 o A number of small wording changes based on feedback. 1111 A.9. Changes from -00 to -01 1113 o Front matter greatly reduced. 1115 o Appendices with charter and RFP added. 1117 o Jurisdiction text changed. 1119 o Proposed changes include supplemental agreement(s) to address 1120 jurisdiction, dispute resolution, and IPR, including names and 1121 marks. 1123 o Transition implications slightly modified to reference 1124 supplemental agreement. 1126 Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG 1128 Charter for the IANA Stewardship Transition Coordination Group V.10 1130 (August 27, 2014) 1131 The IANA stewardship transition coordination group (ICG) has one 1132 deliverable: a proposal to the U.S. Commerce Department National 1133 Telecommunications and Information Administration (NTIA) regarding 1134 the transition of NTIA's stewardship of the IANA functions to the 1135 global multi-stakeholder community. The group will conduct itself 1136 transparently, consult with a broad range of stakeholders, and ensure 1137 that its proposals support the security and stability of the IANA 1138 functions. 1140 The group's mission is to coordinate the development of a proposal 1141 among the communities affected by the IANA functions. The IANA 1142 functions are divided into three main categories: domain names, 1143 number resources, and other protocol parameters. The domain names 1144 category falls further into the country code and generic domain name 1145 sub-categories. While there is some overlap among all of these 1146 categories, each poses distinct organizational, operational and 1147 technical issues, and each tends to have distinct communities of 1148 interest and expertise. For those reasons it is best to have work on 1149 the three categories of IANA parameters proceed autonomously in 1150 parallel and be based in the respective communities. 1152 The IANA stewardship transition process is taking place alongside a 1153 parallel and related process on enhancing ICANN accountability. 1154 While maintaining the accountability of Internet identifier 1155 governance is central to both processes, this group's scope is 1156 focused on the arrangements required for the continuance of IANA 1157 functions in an accountable and widely accepted manner after the 1158 expiry of the NTIA-ICANN contract. Nevertheless, the two processes 1159 are interrelated and interdependent and should appropriately 1160 coordinate their work. 1162 The coordination group has four main tasks: 1163 (i) Act as liaison to all interested parties, including the three 1164 "operational communities" (i.e., those with direct operational 1165 or service relationship with IANA; namely names, numbers, 1166 protocol parameters). This task consists of: 1167 a. Soliciting proposals from the operational communities 1168 b. Soliciting the input of the broad group of communities 1169 affected by the IANA functions 1170 (ii) Assess the outputs of the three operational communities for 1171 compatibility and interoperability 1172 (iii) Assemble a complete proposal for the transition 1173 (iv) Information sharing and public communication 1174 Describing each in more detail: 1175 (i) Liaison 1176 a. Solicit proposals 1178 The ICG expects a plan from the country code and generic name 1179 communities (possibly a joint one), a plan from the numbers 1180 community, and a plan from the protocol parameters community. 1181 Members of the ICG will ensure that the communities from which they 1182 are drawn are working on their part of the transition plans. This 1183 involves informing them of requirements and schedules, tracking 1184 progress, and highlighting the results or remaining issues. The role 1185 of a coordination group member during this phase is to provide status 1186 updates about the progress of his or her community in developing 1187 their component, and to coordinate which community will develop a 1188 transition proposal for each area of overlap (e.g., special-use 1189 registry). 1191 While working on the development of their proposals, the operational 1192 communities are expected to address common requirements and issues 1193 relating to the transition, in as far as they affect their parts of 1194 the stewardship of IANA functions. 1196 b. Solicit broader input 1198 The ICG is open for input and feedback from all interested parties. 1199 While no set of formal requirements related to a transition proposal 1200 will be requested outside the operational communities, everyone's 1201 input is welcome across all topics. 1203 The ICG expects that all interested parties get involved as early as 1204 possible in the relevant community processes. Input received 1205 directly by the ICG may be referred to the relevant community 1206 discussion. 1208 The ICG members chosen from a particular community are the official 1209 communication channel between the ICG and that community. 1211 (ii) Assessment 1213 When the group receives output from the communities it will discuss 1214 and assess their compatibility and interoperability with the 1215 proposals of the other communities. Each proposal should be 1216 submitted with a clear record of how consensus has been reached for 1217 the proposal in the community, and provide an analysis that shows the 1218 proposal is in practice workable. The ICG should also compile the 1219 input it has received beyond the operational communities, and review 1220 the impacts of this input. 1222 The ICG might at some point detect problems with the component 1223 proposals. At that point the role of the ICG is to communicate that 1224 back to the relevant communities so that they (the relevant 1225 communities) can address the issues. It is not in the role of the 1226 ICG to develop proposals or to select from among competing proposals. 1228 (iii) Assembling and submitting a complete proposal 1230 The assembly effort involves taking the proposals for the different 1231 components and verifying that the whole fulfills the intended scope, 1232 meets the intended criteria, that there are no missing parts, and 1233 that the whole fits together. The whole also needs to include 1234 sufficient independent accountability mechanisms for running the IANA 1235 function. The ICG will then develop a draft final proposal that 1236 achieves rough consensus within the ICG itself. The ICG will then 1237 put this proposal up for public comment involving a reasonable period 1238 of time for reviewing the draft proposal, analyzing and preparing 1239 supportive or critical comments. The ICG will then review these 1240 comments and determine whether modifications are required. If no 1241 modifications are needed, and the coordination group agrees, the 1242 proposal will be submitted to NTIA. 1244 If changes are required to fix problems or to achieve broader 1245 support, the ICG will work with the operational communities in a 1246 manner similar to what was described in task (ii) above. Updates are 1247 subject to the same verification, review, and consensus processes as 1248 the initial proposals. If, in the ICG's opinion, broad public 1249 support for the proposal as articulated by the NTIA is not present, 1250 the parts of the proposal that are not supported return to the 1251 liaison phase. 1253 (iv) Information sharing 1255 The ICG serves as a central clearinghouse for public information 1256 about the IANA stewardship transition process. Its secretariat 1257 maintains an independent, publicly accessible and open website, under 1258 its own domain, where status updates, meetings and notices are 1259 announced, proposals are stored, the ICG members are listed, etc. As 1260 the development of the transition plans will take some time, it is 1261 important that information about ongoing work is distributed early 1262 and continuously. This will enable sharing of ideas and the 1263 detection of potential issues. 1265 Appendix C. IANA Stewardship Transition Coordination Group Request for 1266 Proposals 1268 IANA Stewardship Transition Coordination Group Request for Proposals 1270 8 September 2014 1272 Introduction 1273 Under the IANA Stewardship Transition Coordination Group (ICG) 1274 Charter, the ICG has four main tasks: 1276 (i) Act as liaison to all interested parties in the IANA 1277 stewardship transition, including the three "operational 1278 communities" (i.e., those with direct operational or service 1279 relationships with the IANA functions operator; namely names, 1280 numbers, protocol parameters). This task consists of: 1282 a. Soliciting proposals from the operational communities 1283 b. Soliciting the input of the broad group of communities 1284 affected by the IANA functions 1286 (ii) Assess the outputs of the three operational communities for 1287 compatibility and interoperability 1289 (iii) Assemble a complete 1290 proposal for the transition 1292 (iv) Information sharing and public communication 1294 This Request for Proposals (RFP) addresses task (i) of the ICG 1295 Charter. This RFP does not preclude any form of input from the 1296 non-operational communities. 1298 0. Complete Formal Responses 1300 The IANA Stewardship Transition Coordination Group (ICG) seeks 1301 complete formal responses to this RFP through processes which are to 1302 be convened by each of the "operational communities" of IANA (i.e., 1303 those with direct operational or service relationships with the IANA 1304 functions operator, in connection with names, numbers, or protocol 1305 parameters). 1307 Proposals should be supported by the broad range of stakeholders 1308 participating in the proposal development process. Proposals should 1309 be developed through a transparent process that is open to and 1310 inclusive of all stakeholders interested in participating in the 1311 development of the proposal. In order to help the ICG maintain its 1312 light coordination role, all interested and affected parties are 1313 strongly encouraged to participate directly in these community 1314 processes. 1316 The following link provides information about ongoing community 1317 processes and how to participate in them, and that will continue to 1318 be updated over time: 1320 https://www.icann.org/en/stewardship/community 1321 In this RFP, "IANA" refers to the functions currently specified in 1322 the agreement between NTIA and ICANN 1323 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 1324 as any other functions traditionally performed by the IANA functions 1325 operator. SAC-067 1327 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 1328 provides one description of the many different meanings of the term 1329 "IANA" and may be useful reading in addition to the documents 1330 constituting the agreement itself. 1332 Communities are asked to adhere to open and inclusive processes in 1333 developing their responses, so that all community members may fully 1334 participate in and observe those processes. Communities are also 1335 asked to actively seek out and encourage wider participation by any 1336 other parties with interest in their response. 1338 A major challenge of the ICG will be to identify and help to 1339 reconcile differences between submitted proposals, in order to 1340 produce a single plan for the transition of IANA 1341 stewardship. Submitted Proposals should therefore focus on those 1342 elements that are considered to be truly essential to the transition 1343 of their specific IANA functions. The target deadline for all 1344 complete formal responses to this RFP is 15 January 2015. 1346 I. Comments 1348 While the ICG is requesting complete formal proposals through 1349 processes convened by each of the operational communities, and that 1350 all interested parties get involved as early as possible in the 1351 relevant community processes, some parties may choose to provide 1352 comments directly to the ICG about specific aspects of particular 1353 proposals, about the community processes, or about the ICG's own 1354 processes. Comments may be directly submitted to the ICG any time 1355 via email to icg-forum@icann.org. Comments will be publicly archived 1356 at . 1358 Commenters should be aware that ICG will direct comments received to 1359 the relevant operational communities if appropriate. The ICG will 1360 review comments received as time and resources permit and in 1361 accordance with the overall timeline for the transition. That is, 1362 comments received about specific proposals may not be reviewed until 1363 those proposals have been submitted to the ICG. The ICG may 1364 establish defined public comment periods about specific topics in 1365 the future, after the complete formal responses to the RFP have been 1366 received. 1368 Required Proposal Elements 1369 The ICG encourages each community to submit a single proposal that 1370 contains the elements described in this section. 1372 Communities are requested to describe the elements delineated in the 1373 sections below in as much detail possible, and according to the 1374 suggested format/structure, to allow the ICG to more easily 1375 assimilate the results. While each question is narrowly defined to 1376 allow for comparison between answers, respondents are encouraged to 1377 provide further information in explanatory sections, including 1378 descriptive summaries of policies/practices and associated 1379 references to source documents of specific policies/practices. In 1380 this way, the responses to the questionnaire will be useful at the 1381 operational level as well as to the broader stakeholder communities. 1383 In the interest of completeness and consistency, proposals should 1384 cross-reference wherever appropriate the current IANA Functions 1385 Contract[3] when describing existing arrangements and proposing 1386 changes to existing arrangements. 1388 0. Proposal type 1390 Identify which category of the IANA functions this submission 1391 proposes to address: 1392 [ ] Names [ ] Numbers [ ] Protocol Parameters 1394 I. Description of Community's Use of IANA Functions 1396 This section should list the specific, distinct IANA functions your 1397 community relies on. For each IANA function on which your community 1398 relies, please provide the following: 1400 o A description of the function; 1401 o A description of the customer(s) of the function; 1402 o What registries are involved in providing the function; 1403 o A description of any overlaps or interdependencies between your 1404 IANA requirements and the functions required by other customer 1405 communities. 1407 If your community relies on any other IANA service or activity 1408 beyond the scope of the IANA functions contract, you may describe 1409 them here. In this case please also describe how the service or 1410 activity should be addressed by the transition plan. 1412 II. Existing, Pre-Transition Arrangements 1414 This section should describe how existing IANA-related arrangements 1415 work, prior to the transition. 1417 [3] http://www.ntia.doc.gov/files/ntia/ 1418 publications/sf_26_pg_1-2-final_award_and_sacs.pdf 1420 A. Policy Sources 1422 This section should identify the specific source(s) of policy which 1423 must be followed by the IANA functions operator in its conduct of 1424 the services or activities described above. If there are distinct 1425 sources of policy or policy development for different IANA 1426 functions, then please describe these separately. For each source of 1427 policy or policy development, please provide the following: 1429 o Which IANA function (identified in Section I) are affected. 1430 o A description of how policy is developed and established and who 1431 is involved in policy development and establishment. 1432 o A description of how disputes about policy are resolved. 1433 o References to documentation of policy development and dispute 1434 resolution processes. 1436 B. Oversight and Accountability 1438 This section should describe all the ways in which oversight is 1439 conducted over the IANA functions operator's provision of the 1440 services and activities listed in Section I and all the ways in 1441 which the IANA functions operator is currently held accountable for 1442 the provision of those services. For each oversight or 1443 accountability mechanism, please provide as many of the following as 1444 are applicable: 1446 Which IANA functions (identified in Section I) are affected. If the 1447 policy sources identified in Section II.A are affected, identify 1448 which ones are affected and explain in what way. 1450 o A description of the entity or entities that provide oversight or 1451 perform accountability functions, including how individuals are 1452 selected or removed from participation in those entities. 1453 o A description of the mechanism (e.g., contract, reporting scheme, 1454 auditing scheme, etc.). This should include a description of the 1455 consequences of the IANA functions operator not meeting the 1456 standards established by the mechanism, the extent to which the 1457 output of the mechanism is transparent and the terms under which 1458 the mechanism may change. 1459 o Jurisdiction(s) in which the mechanism applies and the legal basis 1460 on which the mechanism rests. 1462 III. Proposed Post-Transition Oversight and Accountability 1463 Arrangements 1465 This section should describe what changes your community is 1466 proposing to the arrangements listed in Section II.B in light of the 1467 transition. If your community is proposing to replace one or more 1468 existing arrangements with new arrangements, that replacement should 1469 be explained and all of the elements listed in Section II.B should 1470 be described for the new arrangements. Your community should provide 1471 its rationale and justification for the new arrangements. 1473 If your community's proposal carries any implications for the 1474 interface between the IANA functions and existing policy arrangements 1475 described in Section II.A, those implications should be described 1476 here. 1478 If your community is not proposing changes to arrangements listed in 1479 Section II.B, the rationale and justification for that choice should 1480 be provided here. 1482 IV. Transition Implications 1484 This section should describe what your community views as the 1485 implications of the changes it proposed in Section III. These 1486 implications may include some or all of the following, or other 1487 implications specific to your community: 1489 Description of operational requirements to achieve continuity of 1490 service and possible new service integration throughout the 1491 transition. 1493 Risks to operational continuity and how they will be addressed. 1494 Description of any legal framework requirements in the absence of the 1495 NTIA contract. Description of how you have tested or evaluated the 1496 workability of any new technical or operational methods proposed in 1497 this document and how they compare to established arrangements. 1498 Description of how long the proposals in Section III are expected to 1499 take to complete, and any intermediate milestones that may occur 1500 before they are completed. 1502 V. NTIA Requirements 1504 Additionally, NTIA has established that the transition proposal must 1505 meet the following five requirements: 1506 o Support and enhance the multistakeholder model; 1507 o Maintain the security, stability, and resiliency of the Internet 1508 DNS; 1509 o Meet the needs and expectation of the global customers and 1510 partners of the IANA functions; 1511 o Maintain the openness of the Internet; 1512 o The proposal must not replace the NTIA role with a government-led 1513 or an inter-governmental organization solution. 1515 This section should explain how your community's proposal meets these 1516 requirements and how it responds to the global interest in the IANA 1517 functions. 1519 VI. Community Process 1520 This section should describe the process your community used for 1521 developing this proposal, including: 1522 o The steps that were taken to develop the proposal and to determine 1523 consensus. 1524 o Links to announcements, agendas, mailing lists, consultations and 1525 meeting proceedings. 1526 o An assessment of the level of consensus behind your community's 1527 proposal, including a description of areas of contention or 1528 disagreement. 1530 Appendix D. Completed ICG response for the NTIA 1532 To be filled in with completed response. 1534 Authors' Addresses 1536 Eliot Lear (editor) 1537 Richtistrasse 7 1538 Wallisellen, ZH CH-8304 1539 Switzerland 1541 Phone: +41 44 878 9200 1542 Email: lear@cisco.com 1544 Russ Housley (editor) 1545 918 Spring Knoll Drive 1546 Herndon, VA 20170 1547 USA 1549 Email: housley@vigilsec.com