idnits 2.17.1 draft-lear-iana-icg-response-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 687 has weird spacing: '...nsition http:...' -- The document date (August 30, 2014) is 3519 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 91 == Missing Reference: 'XXX LINK' is mentioned on line 128, but not defined -- Looks like a reference, but probably isn't: '2' on line 186 == Missing Reference: 'XXX' is mentioned on line 194, but not defined -- Looks like a reference, but probably isn't: '3' on line 431 == Missing Reference: 'Metrics' is mentioned on line 624, but not defined == Unused Reference: 'RFC2850' is defined on line 719, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear, Ed. 3 Internet-Draft R. Housley, Ed. 4 Intended status: Informational August 30, 2014 5 Expires: March 03, 2015 7 Draft Response to the Internet Coordination Group Request for Proposals 8 on IANA 9 draft-lear-iana-icg-response-00 11 Abstract 13 This document contains the a draft response to a request for 14 proposals from the IANA Stewardship Transition Coordination Group 15 regarding the protocol parameters registries. It is meant to be 16 included in an aggregate proposal that also includes contributions 17 covering names and addresses that will be submitted from their 18 respective operational communities. The IETF community is invited to 19 comment and propose changes to this document. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 03, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 56 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 2 57 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 58 4. Informative References . . . . . . . . . . . . . . . . . . . 16 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 61 1. IETF Introduction 63 In March of 2014 the U.S. National Telecommunications & Information 64 Administration (NTIA) announced its intent to transition oversight of 65 IANA functions. In that announcement, NTIA asked the Internet 66 Corporation for Assigned Names and Numbers (ICANN) to establish a 67 process to deliver a proposal for transition. As part of that 68 process, the IANA Stewardship Transition Coordination Group (ICG) was 69 formed. They solicited proposals regarding the respective functions 70 that IANA performs, in order that they may put forth a proposal to 71 the NTIA. 73 While there are interactions between all of the IANA functions and 74 IETF standards, this document specifically addresses the protocol 75 registries function. Section 1 (this section) contains an 76 introduction that is sourced solely within the IETF. Section 2 77 contains the questionnaire that was written by the ICG and a formal 78 response by the IETF. Because much of this memo is taken from a 79 questionnaire we mark answers to questions being asked as "IETF 80 Response:". There are Small changes to the content of the questions 81 asked in order to match the RFC format. 83 2. The Formal RFP Response 85 Introduction 87 NOTE: This section is taken in its entirety from the questionnaire, 88 version 10 (27 August 2014). 90 Under the IANA Stewardship Transition Coordination Group (ICG) 91 Charter [1], the ICG has four main tasks: 93 (i) Act as liaison to all interested parties in the IANA 94 stewardship transition, including the three "operational 95 communities" (i.e., those with direct operational or service 96 relationships with the IANA functions operator; namely names, 97 numbers, protocol parameters). This task consists of: 99 a. Soliciting proposals from the operational communities 100 b. Soliciting the input of the broad group of communities 101 affected by the IANA functions 102 (ii) Assess the outputs of the three operational communities 103 for compatibility and interoperability 104 (iii) Assemble a complete proposal for the transition 105 (iv) Information sharing and public communication 107 This Request for Proposals (RFP) addresses task (i) of the ICG 108 Charter. This RFP does not preclude any form of input from the non- 109 operational communities. 111 0. Complete Formal Responses 113 The IANA Stewardship Transition Coordination Group (ICG) seeks 114 complete formal responses to this RFP from the "operational 115 communities" of IANA (i.e., those with direct operational or service 116 relationships with the IANA functions operator, in connection with 117 names, numbers, or protocol parameters). 119 Proposals are expected to enjoy a broad consensus of support from all 120 interested parties. During the development of their proposals, the 121 operational communities are requested to consult and work with other 122 affected parties. Likewise, in order to help the ICG maintain its 123 light coordination role, all other affected parties are strongly 124 encouraged to participate in community processes. 126 The following link provides information about ongoing community 127 processes and how to participate in them, and that will continue to 128 be updated over time: [XXX LINK] 130 Communities are asked to adhere to open and inclusive processes in 131 developing their responses, so that all community members may fully 132 participate in and observe those processes. Communities are also 133 asked to actively seek out and encourage wider participation by any 134 other parties with interest in their response. 136 A major challenge of the ICG will be to identify and help to 137 reconcile differences between submitted proposals, in order to 138 produce a single plan for the transition of IANA stewardship. 139 Submitted Proposals should therefore focus on those elements that are 140 considered to be truly essential to the transition of their specific 141 IANA functions. 143 The target deadline for all complete formal responses to this RFP is 144 31 December 2014. 146 I. Comments 148 While the ICG is requesting complete formal proposals from the 149 operational communities only, and that all interested parties get 150 involved as early as possible in the relevant community processes, 151 some parties may choose to provide comments directly to the ICG about 152 specific aspects of particular proposals, about the community 153 processes, or about the ICG's own processes. Comments may be 154 directly submitted to the ICG any time via email to icg- 155 forum@icann.org. Comments will be publicly archived at . 158 Commenters should be aware that ICG will direct comments received to 159 the relevant operational communities if appropriate. The ICG will 160 review comments received as time and resources permit and in 161 accordance with the overall timeline for the transition. That is, 162 comments received about specific proposals may not be reviewed until 163 those proposals have been submitted to the ICG. The ICG may 164 establish defined public comment periods about specific topics in the 165 future, after the complete formal responses to the RFP have been 166 received. 168 Required Proposal Elements 170 The ICG encourages each community to submit a single proposal that 171 contains the elements described in this section. 173 Communities are requested to describe the elements delineated in the 174 sections below in as much detail possible, and according to the 175 suggested format/structure, to allow the ICG to more easily 176 assimilate the results. While each question is narrowly defined to 177 allow for comparison between answers, respondents are encouraged to 178 provide further information in explanatory sections, including 179 descriptive summaries of policies/practices and associated references 180 to source documents of specific policies/practices. In this way, the 181 responses to the questionnaire will be useful at the operational 182 level as well as to the broader stakeholder communities. 184 In the interest of completeness and consistency, proposals should 185 cross-reference wherever appropriate the current IANA Functions 186 Contract [2] when describing existing arrangements and proposing 187 changes to existing arrangements. 189 0. Proposal Type 190 Identify which category of the IANA functions this submission 191 proposes to address: 193 IETF Response: 194 [XXX] Protocol Parameters 196 This response states the existing practice of the IETF, and also 197 represents the views of the IAB and the IETF. 199 I. Description of Community's Use of IANA Functions 201 This section should list the specific, distinct IANA services or 202 activities your community relies on. For each IANA service or 203 activity on which your community relies, please provide the 204 following: 206 o A description of the customer(s) of the service or activity. 207 [N.B. the IETF response has swapped this question with the next.] 209 IETF Response: 211 The customer of the IANA protocol parameters function is the Internet 212 Engineering Task Force (IETF). 214 The IETF is a global voluntary standards organization whose goal is 215 to make the Internet work better [RFC3595]. IETF standards are 216 published in the RFC series. The IETF is responsible for the key 217 standards that are used on the Internet today, including IP, TCP, 218 DNS, BGP, and HTTP, to name but a few. 220 The IETF operates an open and transparent manner [RFC6852]. The 221 processes that govern the IETF are also published in the RFC series. 222 The Internet Standards Process is documented in [RFC2026]. That 223 document explains not only how standards are developed, but also how 224 disputes about decisions are resolved. RFC 2026 has been amended a 225 number of times, and those amendments are indicated in [RFC-INDEX]. 226 The standards process can be amended in the same manner that 227 standards are approved. That is, someone proposes a change by 228 submitting a temporary document known as an Internet-Draft, the 229 community discusses it, and if rough consensus can be found the 230 change is approved by the Internet Engineering Steering Community 231 (IESG). Anyone may propose such a change, and anyone may participate 232 in the community discussion. 234 o A description of the service or activity. 236 IETF Response: 238 Many IETF protocols make use of commonly defined protocol parameters. 239 These parameters are used by implementers, who are the IETF's primary 240 users of the IETF standards and other documents. To ensure 241 consistent interpretation of these parameter values by independent 242 implementations, a globally available registry contains the parameter 243 values and a pointer to documentation of the associated semantic 244 intent. The IETF uses the IANA protocol parameter registries for 245 this purpose. 247 o What registries are involved in providing the service or 248 activity. 250 IETF Response: 252 Administration of the protocol registries are themselves the service 253 that is provided to the IETF community by ICANN. 255 o A description of any overlaps or interdependencies between your 256 IANA requirements and the functions required by other customer 257 communities 259 IETF Response: 261 It is important to note that the IETF includes anyone who wishes to 262 participate, including anyone from ICANN or the RIRs, and many people 263 from those organizations regularly do. 265 o The IETF has specified a number of special use registries. These 266 registries require coordination with the GNSO. We already perform 267 this coordination. 269 o The IETF may, from time to time, define and allocate new ranges of 270 IP addresses. If one or more registries are required, the IETF 271 will coordinate with appropriate organizations, such as the RIRs 272 or ICANN. 274 o The IETF specifies the DNS protocol. From time to time there are 275 changes. We continue to coordinate with ICANN regarding those 276 changes. 278 o The IETF specifies minimum requirements for root servers. Should 279 those requirements change, we will inform ICANN. 281 o The routing architecture has evolved over time, and is expected to 282 continue to do so. Such evolution may have an impact on 283 appropriate IP address allocation strategies. As and when that 284 happens, we will consult with the RIR community, as we have done 285 in the past. 287 o IETF standards changes may have impact on operations of RIRs and 288 service providers. A recent example is the expansion of the BGP 289 community field from 16 to 32 bits.[RFC6793] It is important to 290 note that this change occurred out of operational necessity, and 291 it demonstrated strong alignment between the RIRs and the IETF. 293 [[RH2]I think there are two areas of overlap: 295 Addresses: special-purpose addresses, such as anycast. We need 296 to set up procedures to coordinate assignments. 298 Names: special-purpose names, such as .local. We need to set 299 up procedures to coordinate such assignments. ]] 301 III. Existing, Pre-Transition Arrangements 303 This section should describe how existing IANA-related arrangements 304 work, prior to the transition. 306 A. Policy Sources 308 This section should identify the specific source(s) of policy which 309 must be followed by the IANA functions operator in its conduct of the 310 services or activities described above. If there are distinct 311 sources of policy or policy development for different IANA 312 activities, then please describe these separately. For each source 313 of policy or policy development, please provide the following: 315 o Which IANA service or activity (identified in Section I) is 316 affected. 318 IETF Respponse: The protocol parameters registry. 320 o A description of how policy is developed and established and who 321 is involved in policy development and establishment. 323 IETF Response: 325 Policy for overall management of the registries is stated in RFCs in 326 [RFC6220] and [RFC5226]. The first of these documents explains the 327 model for how the registries are to be operated, how policy is set, 328 and how oversight takes place. RFC 5226 specifies the policies that 329 specification writers may employ when they define new protocol 330 registries in the "IANA Considerations" section of each 331 specification. All policies at the IETF begin with a proposal in the 332 form of an Internet-Draft. Anyone may submit such a proposal. If 333 there is sufficient interest, the Internet Engineering Steering Group 334 may choose to create a working group or an Area Director may choose 335 to sponsor the draft. In either case, anyone may comment on the 336 proposal as it progresses. A proposal cannot be passed by the IESG 337 unless it enjoys sufficient community support as to indicate rough 338 consensus [RFC7282] Last calls are made so that there is notice of 339 any proposed change to a policy or process. 341 o A description of how disputes about policy are resolved. 343 IETF Response: 345 Most disputes are handled at the lowest level through the working 346 group and rough consensus processes. Should anyone disagree with any 347 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 348 resolution and appeals process that includes the responsible Area 349 Director, the IESG, and the IAB. Should appeals be upheld, an 350 appropriate remedy is applied. In the case where an someone claims 351 that the procedures themselves are insufficient or inadequate in some 352 way to address a circumstance, one may appeal an IAB decision to the 353 Internet Society Board of Trustees. 355 o References to documentation of policy development and dispute 356 resolution processes. 358 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 359 conflict resolution and appeals process. 361 B. Oversight and Accountability 362 This section should describe all the ways in which oversight is 363 conducted over IANA functions operator's provision of the services 364 and activities listed in Section I and all the ways in which IANA 365 functions operator is currently held accountab le for the provision 366 of those services. For each oversight or accountability mechanism, 367 please provide as many of the following as are applicable: 369 o Which IANA service or activity (identified in Section I) is 370 affected. 372 IETF Response: the protocol parameters registries. 374 o If not all policy sources identified in Section II.A are affected, 375 identify which ones are affected. 377 IETF Response: all policy sources relating to the protocol parameters 378 registry have been specified in II.A. 380 o A description of the entity or entities that provide oversight or 381 perform accountability functions, including how individuals are 382 selected or removed from participation in those entities. 384 IETF Response: 386 The Internet Architecture Board (IAB) is an oversight body of the 387 IETF whose responsibilities include, among other things, confirming 388 appointment of IESG members, managing appeals as discussed above, 389 management of certain domains, including .ARPA [RFC3172], and general 390 architectural guidance to the broader community. The IAB is also 391 responsible for establishing liaison relationships with other 392 orgnaizations on behalf of the IETF. The IAB's charter is to be 393 found in [RFC2860]. 395 The IAB members are selected and may be recalled through a Nominating 396 Committee (NOMCOM) process, which is described in [RFC3777]. This 397 process provides for selection of active members of the community who 398 themselves agree upon a slate of candidates. Those candidates are 399 sent to the ISOC Board of Trustees for confirmation. In general, 400 members serve for two years. The IAB selects its own chair. 402 The IAB provides oversight of the protocol parameter registries of 403 the IETF, and is responsible for selecting appropriate operator(s) 404 and related per-registry arrangements. Especially when relationships 405 among protocols call for it, many registries are operated by, or in 406 conjunction with, other bodies. Unless the IAB or IETF has concluded 407 that special treatment is needed, the operator for registries is 408 currently ICANN. 410 o A description of the mechanism (e.g., contract, reporting scheme, 411 auditing scheme, etc.). This should include a description of the 412 consequences of the IANA functions operator not meeting the 413 standards established by the mechanism, the extent to which the 414 output of the mechanism is transparent and the terms under which 415 the mechanism may change. 417 IETF Response: 419 A memorandum of understanding (MoU) between ICANN and the IETF 420 community has been in place since 2000. It can be found in 421 [RFC2860]. It has been amended several times. The MoU defines the 422 work to be carried out by the IANA staff for the IETF and IRTF. 424 Day-to-day administration and contract management is the 425 responsibility of the IETF Administrative Director (IAD). The IETF 426 Administrative Oversight Committee (IAOC) oversees the IAD. IAOC 427 members are appointed by the Internet Society Board of Trustees, the 428 IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN 429 to establish annual IANA performance metrics and operational 430 procedures, and the resulting document is adopted as an addendum to 431 the MoU each year [3]. 433 To date there have been no unresolvable disputes or issues. In the 434 unlikely event that a more difficult situation should arise, the IAOC 435 and the IAB would engage ICANN management to address the matter. The 436 MoU also provides an option for either party to terminate the 437 arrangement with six months notice. Obviously such action would only 438 be undertaken after serious consideration. 440 o Jurisdiction(s) in which the mechanism applies and the legal basis 441 on which the mechanism rests. 443 IETF Response 445 Because of the nature of the agreement, questions of jurisdiction are 446 immaterial. 448 IV. Proposed changes to IANA Activities/Services 450 This section should describe what changes your community is proposing 451 to the arrangements listed in Section II.B in light of the 452 transition. If your community is proposing to replace one or more 453 existing arrangements with new arrangements, that replacement should 454 be explained and all of the elements listed in Section II.B should be 455 described for the new arrangements. Your community should provide 456 its rationale and justification for the new arrangements. 458 If your community's proposal carries any implications for existing 459 policy arrangements described in Section II.A, those implications 460 should be described here. 462 If your community is not proposing changes to arrangements listed in 463 Section II.B, the rationale and justification for that choice should 464 be provided here. 466 IETF Response: 468 No changes are required, as over the years since the creation of 469 ICANN, the IETF, ICANN, and IAB have together created a system of 470 agreements, policies, and oversight mechanisms that covers what is 471 needed. 473 First and foremost, IANA protocol parameter registry updates will 474 continue to function day-to-day, as they have been doing for the last 475 decade or more. The IETF community is quite satisfied with the 476 current arrangement with ICANN. RFC 2860 remains in force and has 477 served the IETF community very well. RFC 6220 has laid out an 478 appropriate service description and requirements. 480 Discussions during IETF 89 in London led to the following guiding 481 principles for IAB efforts that impact IANA protocol parameter 482 registries. These principles must be taken together; their order is 483 not significant. 485 1. The IETF protocol parameter registry function has been and 486 continues to be capably provided by the Internet technical community. 488 The strength and stability of the function and its foundation within 489 the Internet technical community are both important given how 490 critical protocol parameters are to the proper functioning of IETF 491 protocols. 493 We think the structures that sustain the protocol parameter registry 494 function needs to be strong enough that they can be offered 495 independently by the Internet technical community, without the need 496 for backing from external parties. And we believe we largely are 497 there already, although the system can be strengthened further, and 498 continuous improvements are being made. 500 2. The protocol parameter registry function requires openness, 501 transparency, and accountability. 503 Existing documentation of how the function is administered and 504 overseen is good [RFC2860], [RFC6220]. Further articulation and 505 clarity may be beneficial. It is important that the whole Internet 506 community can understand how the function works, and that the 507 processes for registering parameters and holding those who oversee 508 the protocol parameter function accountable for following those 509 processes are understood by all interested parties. We are committed 510 to making improvements here if necessary. 512 3. Any contemplated changes to the protocol parameter registry 513 function should respect existing Internet community agreements. 515 The protocol parameter registry is working well. The existing 516 Memorandum of Understanding in RFC 2860 defines "the technical work 517 to be carried out by the Internet Assigned Numbers Authority on 518 behalf of the Internet Engineering Task Force and the Internet 519 Research Task Force." Any modifications to the protocol parameter 520 registry function should be made using the IETF process to update RFC 521 6220 and other relevant RFCs. Put quite simply: evolution, not 522 revolution. 524 4. The Internet architecture requires and receives capable service 525 by Internet registries. 527 The stability of the Internet depends on capable provision of not 528 just IETF protocol parameters, but IP numbers, domain names, and 529 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 530 protocols. Thus we expect the role of the IETF in standards 531 development, architectural guidance, and allocation of certain name/ 532 number parameters to continue. IP multicast addresses and special- 533 use DNS names are two examples where close coordination is needed. 534 The IETF will continue to coordinate with ICANN, the RIRs, and other 535 parties that are mutually invested in the continued smooth operation 536 of the Internet registries. We fully understand the need to work 537 together. 539 5. The IETF will continue management of the protocol parameter 540 registry function as an integral component of the IETF standards 541 process and the use of resulting protocols. 543 RFC 6220 specifies the role and function of the protocol parameters 544 registry, which is critical to IETF standards processes and IETF 545 protocols. The IAB, on behalf of the IETF, has the responsibility to 546 define and manage the relationship with the protocol registry 547 operator role. This responsibility includes the selection and 548 management of the protocol parameter registry operator, as well as 549 management of the parameter registration process and the guidelines 550 for parameter allocation. 552 6. The protocol parameters registries are provided as a public 553 service. 555 Directions for the creation of protocol parameter registries and the 556 policies for subsequent additions and updates are specified in RFCs. 557 The protocol parameters registries are available to everyone, and 558 they are published in a form that allows their contents to be 559 included in other works without further permission. These works 560 include, but are not limited to, implementations of Internet 561 protocols and their associated documentation. 563 These principles will guide the IAB, IAOC, and the rest of the IETF 564 community as they work with ICANN to establish future IANA 565 performance metrics and operational procedures. 567 Transition Implications 569 This section should describe what your community views as the 570 implications of the changes it proposed in Section III. These 571 implications may include some or all of the following, or other 572 implications specific to your community: 574 Description of operational requirements to achieve continuity of 575 service and possible new service integration throughout the 576 transition. 578 Risks to operational continuity 580 Description of any legal framework requirements in the absence of 581 the NTIA contract 583 Description of how you have tested or evaluated the workability of 584 any new technical or operational methods proposed in this document 585 and how they compare to established arrangements. 587 IETF Response: 589 No structural changes are required. The principles listed above will 590 guide IAB, IAOC, and the rest of the IETF community as they work with 591 ICANN to establish future IANA performance metrics and operational 592 procedures, as they have in the past. 594 As no services are expected to change, no continuity issuees are 595 anticipated, and there are no new technical or operational methods 596 proposed by the IETF to test. The IETF leadership, ICANN, and the 597 RIRs maintain an ongoing informal dialog to spot any unforeseen 598 issues that might arise as a result of other changes. 600 V. NTIA Requirements 601 Additionally, NTIA has established that the transition proposal must 602 meet the following five requirements: 604 "Support and enhance the multistakeholder model;" 606 IETF Response: 608 Everyone is welcome to participate in IETF activities. The policies 609 and procedures are outlined in the documents we named above. In- 610 person attendance is not required for participation, and many people 611 participate in email discussions that have never attended an IETF 612 meeting. An email account is the only requirement to participate. 613 The IETF makes use of both formal and informal lines of communication 614 to collaborate with other organizations within the multistakeholder 615 ecosystem. 617 "Maintain the security, stability, and resiliency of the Internet 618 DNS;" 620 IETF Response: 622 The DNS relies on some of the IETF protocol parameters registries. 623 As the current IANA functions operator, ICANN performs its task very 624 well, usually exceeding the service level agreement metrics.[Metrics] 625 Security, stability, and resiliency of the Internet DNS is best 626 protected by maintaining the current service in its current form. 628 "Meet the needs and expectation of the global customers and partners 629 of the IANA services;" 631 IETF Response: 633 Implementers and their users from around the world make use of the 634 IETF standards and the associated IANA protocol parameter registries. 635 The current IANA protocol parameter registry system is meeting the 636 needs of these global customers. This proposal continues to meet 637 their needs by maintaining the existing processes that have served 638 them well in the past. 640 "Maintain the openness of the Internet." 642 IETF Response: 644 This proposal maintains the existing open framework that allows 645 anyone to participate in the development of IETF standards, including 646 the IANA protocol parameter registry policies. Further, an 647 implementer anywhere in the world has full access to the protocol 648 specification published n the RFC series and the protocol parameter 649 registries published at iana.org. Those who require assignments in 650 the IANA protocol registries will continue to be able to do so, as 651 specified by the existing policies for those registries. 653 {We will have an open discussion, make changes based on that 654 discussion, and then conduct a Last Call to confirm that there is 655 rough consensus for the proposal.} 657 VI. Community Process 659 This section should describe the process your community used for 660 developing this proposal, including: 662 The steps that were taken to develop the proposal and to determine 663 consensus. 665 IETF Response: 667 The IESG established the IANAPLAN working group to develop this 668 response. Anyone was welcome to join the discussion and participate 669 in the development of this response. An open mailing list 670 (ianaplan@ietf.org) was associated with the working group. In 671 addition, IETF's IANA practices have been discussed in the broader 672 community, and all input is welcome. 674 o Links to announcements, agendas, mailing lists, consultations and 675 meeting proceedings. 677 IETF Response: [xxx to be completed in more detail] 679 The following list is not exhaustive, as there have been many open 680 discussions about this transition within the IETF community in the 681 past few months. 683 Creation of an open mailing list to discuss the transition 684 http://www.ietf.org/mail-archive/web/ietf-announce/current/ 685 msg12978.html 687 Announcement of a public session on the transition http:// 688 www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html 690 Announcement by the IESG of the intent to form a working group 691 http://www.ietf.org/mail-archive/web/ietf-announce/current/ 692 msg13170.html 694 o An assessment of the level of consensus behind your community's 695 proposal, including a description of areas of contention or 696 disagreement. 698 IETF Response: To be completed as the process progresses. 700 3. Acknowledgments 702 This document does not define new processes, and so it seems we 703 acknowledge all of the preceding IAB members and members of the 704 community who developed the processes that we describe. The initial 705 version of this document was developed collaboratively through both 706 the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular 707 thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew 708 Sullivan, Leslie Daigle, and Barry Leiba. 710 4. Informative References 712 [RFC-INDEX] 713 RFC Editor, , "Index of all Requests for Comments", RFC 714 Index, August 2014. 716 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 717 3", BCP 9, RFC 2026, October 1996. 719 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 720 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 721 May 2000. 723 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 724 Understanding Concerning the Technical Work of the 725 Internet Assigned Numbers Authority", RFC 2860, June 2000. 727 [RFC3172] Huston, G., "Management Guidelines & Operational 728 Requirements for the Address and Routing Parameter Area 729 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 731 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 732 3595, September 2003. 734 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 735 Recall Process: Operation of the Nominating and Recall 736 Committees", BCP 10, RFC 3777, June 2004. 738 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 739 Administrative Support Activity (IASA)", BCP 101, RFC 740 4071, April 2005. 742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 744 May 2008. 746 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., 747 Internet Architecture Board, "Defining the Role and 748 Function of IETF Protocol Parameter Registry Operators", 749 RFC 6220, April 2011. 751 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 752 Autonomous System (AS) Number Space", RFC 6793, December 753 2012. 755 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. 756 Amour, "Affirmation of the Modern Paradigm for Standards", 757 RFC 6852, January 2013. 759 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 760 7282, June 2014. 762 Authors' Addresses 764 Eliot Lear (editor) 765 Richtistrasse 7 766 Wallisellen, ZH CH-8304 767 Switzerland 769 Phone: +41 44 878 9200 770 Email: lear@cisco.com 772 Russ Housley (editor) 773 918 Spring Noll Drive 774 Herndon, VA 20170 775 USA 777 Email: housley@vigilsec.com