idnits 2.17.1 draft-ietf-ianaplan-icg-response-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XXX' is mentioned on line 120, but not defined -- Looks like a reference, but probably isn't: '3' on line 1175 -- Duplicate reference: RFC2860, mentioned in 'RFC2860', was also mentioned in 'MOUSUP'. -- Obsolete informational reference (is this intentional?): RFC 3777 (Obsoleted by RFC 7437) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6220 (Obsoleted by RFC 8722) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IANAPLAN E. Lear, Ed. 3 Internet-Draft R. Housley, Ed. 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 Draft Response to the Internet Coordination Group Request for Proposals 8 on IANA 9 draft-ietf-ianaplan-icg-response-02 11 Abstract 13 This document contains the a response to a request for proposals from 14 the IANA Stewardship Transition Coordination Group regarding the 15 protocol parameters registries. It is meant to be included in an 16 aggregate proposal that also includes contributions covering domain 17 names and numbering resources that will be submitted from their 18 respective operational communities. The IETF community is invited to 19 comment and propose changes to this document. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 30, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 56 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 60 6. Informative References . . . . . . . . . . . . . . . . . . . 17 61 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19 62 A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 19 63 A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20 64 Appendix B. The Charter of the IANA Stewardship Coordination 65 Group (ICG . . . . . . . . . . . . . . . . . . . . . 20 66 Appendix C. IANA Stewardship Transition Coordination Group 67 Request for Proposals . . . . . . . . . . . . . . . 23 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 70 1. IETF Introduction 72 In March of 2014 the U.S. National Telecommunications & Information 73 Administration (NTIA) announced its intent to transition oversight of 74 Internet Assigned Numbers Authority (IANA) functions. In that 75 announcement, NTIA asked the Internet Corporation for Assigned Names 76 and Numbers (ICANN) to establish a process to deliver a proposal for 77 transition. As part of that process, the IANA Stewardship Transition 78 Coordination Group (ICG) was formed. The charter for the ICG can be 79 found in Appendix B. They solicited proposals regarding the 80 respective functions that IANA performs, in order that they may put 81 forth a proposal to the NTIA. The final request for proposal (RFP) 82 can be found in Appendix C. 84 While there are interactions between all of the IANA functions and 85 IETF standards, this document specifically addresses the protocol 86 parameters registries function. Section 1 (this section) contains an 87 introduction that is sourced solely within the IETF. Section 2 88 contains the questionnaire that was written by the ICG and a formal 89 response by the IETF. Because much of this memo is taken from a 90 questionnaire we have quoted questions with ">>> " and we have 91 prefaced answers to questions being asked with "IETF Response:". 92 Note that there are small changes to the content of the questions 93 asked in order to match the RFC format. 95 As if to demonstrate the last point, the following text was included 96 in a footnote in the original propsoal. 98 In this RFP, "IANA" refers to the functions currently specified in 99 the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ 100 iana-functions-purchase-order] as well as any other functions 101 traditionally performed by the IANA functions operator. SAC-067 102 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides 103 one description of the many different meanings of the term "IANA" and 104 may be useful reading in addition to the documents constituting the 105 agreement itself. 107 2. The Formal RFP Response 109 The entire Request for Comments, including introduction, can be found 110 in Appendix C. 112 >>> 113 >>> 0. Proposal Type 114 >>> 115 >>> Identify which category of the IANA functions this 116 >>> submission proposes to address: 117 >>> 119 IETF Response: 120 [XXX] Protocol Parameters 122 This response states the existing practice of the IETF, and also 123 represents the views of the Internet Architecture Board and the IETF. 125 >>> 126 >>> I. Description of Community's Use of IANA Functions 127 >>> 128 >>> This section should list the specific, distinct IANA services 129 >>> or activities your community relies on. For each IANA service 130 >>> or activity on which your community relies, please provide the 131 >>> following: 132 >>> A description of the service or activity. 133 >>> 135 IETF Response: 137 Many IETF protocols make use of commonly defined protocol parameters. 138 These parameters are used by implementers, who are the IETF's primary 139 users of the IETF standards and other documents. To ensure 140 consistent interpretation of these parameter values by independent 141 implementations, and to promote universal interoperability, these 142 IETF protocol specifications define and require globally available 143 registries containing the parameter values and a pointer to 144 documentation of the associated semantic intent. The IETF uses the 145 IANA protocol parameters registries to store this information in a 146 public location. 148 >>> 149 >>> A description of the customer(s) of the service or activity. 150 >>> 152 IETF Response: 154 The IANA protocol parameters registries operator maintains the 155 protocol parameters registries for the IETF in accordance with all 156 relevant IETF policies, in accordance with the Memorandum of 157 Understanding[RFC2860] and associated supplemental agreements that 158 include service level agreements (SLAs) established between the IETF 159 and ICANN[MOUSUP]. 161 The IETF is a global voluntary standards organization whose goal is 162 to make the Internet work better [RFC3595]. IETF standards are 163 published in the RFC series. The IETF is responsible for the key 164 standards that are used on the Internet today, including IP, TCP, 165 DNS, BGP, and HTTP, to name but a few. 167 The IETF operates in an open and transparent manner [RFC6852]. The 168 processes that govern the IETF are also published in the RFC series. 169 The Internet Standards Process is documented in [RFC2026]. That 170 document explains not only how standards are developed, but also how 171 disputes about decisions are resolved. RFC 2026 has been amended a 172 number of times, and those amendments are indicated in [RFC-INDEX]. 173 The standards process can be amended in the same manner that 174 standards are approved. That is, someone proposes a change by 175 submitting a temporary document known as an Internet-Draft, the 176 community discusses it, and if rough consensus can be found the 177 change is approved by the Internet Engineering Steering Group (IESG), 178 who also have day-to-day responsibility for declaring IETF consensus 179 on technical decisions, including those that affect IANA. Anyone may 180 propose a change during a Last Call, and anyone may participate in 181 the community discussion. 183 >>> 184 >>> What registries are involved in providing the service or 185 >>> activity. 186 >>> 188 IETF Response: 190 The protocol parameters registries are the product of IETF work. 191 Administration of the protocol parameters registries is the service 192 that is provided to the IETF. 194 >>> 195 >>> A description of any overlaps or interdependencies between your 196 >>> IANA requirements and the functions required by other customer 197 >>> communities 198 >>> 200 IETF Response: 202 In this context, the IETF considers "overlap" to be where there is in 203 some way shared responsibility for a single registry across multiple 204 organizations. In this sense, there is no overlap between 205 organizations because responsibility for each registry is carefully 206 delineated. There are, however, points of interaction between other 207 organizations, and a few cases where we may further define the scope 208 of a registry for technical purposes. This is the case with both 209 names and numbers, as described in the paragraphs below. In all 210 cases, the IETF engages directly with the appropriate organizations 211 to ensure that each organization's policies are followed. 213 It is important to note that the IETF includes anyone who wishes to 214 participate. Staff and participants from ICANN or the Regional 215 Internet Registries (RIRs) regularly participate in IETF activities. 217 o The IETF has specified a number of special use registries with 218 regard to domain names. These registries require coordination 219 with the Generic Names Support Organization (GNSO). We already 220 perform this coordination.[RFC6761] 222 o The IETF specifies the DNS protocol. From time to time there have 223 been and will be updates to that protocol. As we make changes we 224 will broadly consult the operational community about the impact of 225 those changes, as we have done in the past. 227 o The IETF specifies minimum requirements for root servers. Should 228 those requirements change, we will inform ICANN. 230 o The routing architecture has evolved over time, and is expected to 231 continue to do so. Such evolution may have an impact on 232 appropriate IP address allocation strategies. As and when that 233 happens, we will consult with the RIR community, as we have done 234 in the past. 236 o The IETF is responsible for policy relating to the entire IP 237 address space and AS number space. Through IANA, the IETF 238 delegates unicast IP address and AS number ranges to the RIR 239 system [RFC7020],[RFC7249]. Special address allocation, such a 240 multicast and anycast addresses, often require coordination. 241 Another example of IP addresses that are not administered by the 242 RIR system is Unique Local Addresses (ULAs) [RFC4193], where local 243 networks employ a prefix that is not intended to be routed on the 244 public Internet. New special address allocations are added, from 245 time to time, related to the evolution of the standards. In all 246 cases, these special assignments are listed in the IANA 247 registries. 249 o The IETF maintains sub-registries for special IPv4 and IPv6 250 assignments. These are specified in [RFC3307], [RFC5771], and 251 [RFC6890]. The IETF coordinates such assignments with the RIRs. 253 o IETF standards changes may have impact on operations of RIRs and 254 service providers. A recent example is the extensions to BGP to 255 carry the Autonomous System numbers as four-octet entities 256 [RFC6793]. It is important to note that this change occurred out 257 of operational necessity, and it demonstrated strong alignment 258 between the RIRs and the IETF. 260 >>> II. Existing, Pre-Transition Arrangements 262 >>> 263 >>> This section should describe how existing IANA-related 264 >>> arrangements work, prior to the transition. 265 >>> 266 >>> A. Policy Sources 267 >>> 268 >>> 269 >>> This section should identify the specific source(s) of policy 270 >>> which must be followed by the IANA functions operator in its 271 >>> conduct of the services or activities described above. If there 272 >>> are distinct sources of policy or policy development for 273 >>> different IANA activities, then please describe these 274 >>> separately. For each source of policy or policy development, 275 >>> please provide the following: 276 >>> 277 >>> Which IANA service or activity (identified in Section I) is 278 >>> affected. 279 >>> 281 IETF Response: The protocol parameters registries. 283 >>> 284 >>> A description of how policy is developed and established and 285 >>> who is involved in policy development and establishment. 286 >>> 288 IETF Response: 290 Policy for overall management of the registries is stated in 291 [RFC6220] and [RFC5226]. The first of these documents explains the 292 model for how the registries are to be operated, how policy is set, 293 and how oversight takes place. RFC 5226 specifies the policies that 294 specification writers may employ when they define new protocol 295 registries in the "IANA Considerations" section of each 296 specification. All policies at the IETF begin with a proposal in the 297 form of an Internet-Draft. Anyone may submit such a proposal. If 298 there is sufficient interest, the Internet Engineering Steering Group 299 may choose to create a working group or an Area Director may choose 300 to sponsor the draft. In either case, anyone may comment on the 301 proposal as it progresses. A proposal cannot be passed by the IESG 302 unless it enjoys sufficient community support as to indicate rough 303 consensus [RFC7282]. In each case, a "Last Call" is made so that 304 there is notice of any proposed change to a policy or process. 305 Anyone may comment during a Last Call. 307 >>> 308 >>> A description of how disputes about policy are resolved. 309 >>> 311 IETF Response: 313 Most disputes are handled at the lowest level through the working 314 group and rough consensus processes. Should anyone disagree with any 315 action, Section 6.5 of [RFC2026] specifies a multi-level conflict 316 resolution and appeals process that includes the responsible Area 317 Director, the IESG, and the IAB. Should appeals be upheld, an 318 appropriate remedy is applied. In the case where someone claims that 319 the procedures themselves are insufficient or inadequate in some way 320 to address a circumstance, one may appeal an IAB decision to the 321 Internet Society Board of Trustees. 323 >>> 324 >>> References to documentation of policy development and dispute 325 >>> resolution processes. 326 >>> 327 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a 328 conflict resolution and appeals process. [RFC2418] specifies working 329 group procedures. Note that both of these documents have been 330 amended in later RFCs as indicated in the [RFC-INDEX]. Please also 331 see the references at the bottom of this document. 333 >>> 334 >>> B. Oversight and Accountability 335 >>> 336 >>> This section should describe all the ways in which oversight is 337 >>> conducted over IANA functions operator's provision of the 338 >>> services and activities listed in Section I and all the ways in 339 >>> which IANA functions operator is currently held accountab le for 340 >>> the provision of those services. For each oversight or 341 >>> accountability mechanism, please provide as many of the 342 >>> following as are applicable: 343 >>> 344 >>> Which IANA service or activity (identified in Section I) is 345 >>> affected. 346 >>> 348 IETF Response: the protocol parameters registries. 350 >>> 351 >>> If not all policy sources identified in Section II.A are 352 >>> affected, identify which ones are affected. 353 >>> 355 IETF Response: all policy sources relating to the protocol parameters 356 registry are affected. 358 >>> 359 >>> A description of the entity or entities that provide oversight 360 >>> or perform accountability functions, including how individuals 361 >>> are selected or removed from participation in those entities. 362 >>> 364 IETF Response: 366 The Internet Architecture Board (IAB) is an oversight body of the 367 IETF whose responsibilities include, among other things, confirming 368 appointment of IESG members, managing appeals as discussed above, 369 management of certain domains, including .ARPA [RFC3172], and general 370 architectural guidance to the broader community. The IAB must 371 approve the appointment of an organization to act as IANA on behalf 372 of the IETF. The IAB is also responsible for establishing liaison 373 relationships with other orgnaizations on behalf of the IETF. The 374 IAB's charter is to be found in [RFC2850]. 376 The IAB members are selected and may be recalled through a Nominating 377 Committee (NOMCOM) process, which is described in [RFC3777]. This 378 process provides for selection of active members of the community who 379 themselves agree upon a slate of candidates. Those candidates are 380 sent to the Internet Society Board of Trustees for confirmation. In 381 general, members serve for two years. The IAB selects its own chair. 383 The IAB provides oversight of the protocol parameters registries of 384 the IETF, and is responsible for selecting appropriate operator(s) 385 and related per-registry arrangements. Especially when relationships 386 among protocols call for it, many registries are operated by, or in 387 conjunction with, other bodies. Unless the IAB or IETF has concluded 388 that special treatment is needed, the operator for registries is 389 currently ICANN. 391 >>> 392 >>> A description of the mechanism (e.g., contract, reporting 393 >>> scheme, auditing scheme, etc.). This should include a 394 >>> description of the consequences of the IANA functions operator 395 >>> not meeting the standards established by the mechanism, the 396 >>> extent to which the output of the mechanism is transparent and 397 >>> the terms under which the mechanism may change. 398 >>> 400 IETF Response: 402 A memorandum of understanding (MoU) between ICANN and the IETF 403 community has been in place since 2000. It can be found in 404 [RFC2860]. The MoU defines the work to be carried out by the IANA 405 staff for the IETF and the Internet Research Task Force (IRTF), a 406 peer organization to the IETF that focuses on research. Each year a 407 service level agreement is negotiated that supplements the MoU. 409 Day-to-day administration and contract management is the 410 responsibility of the IETF Administrative Director (IAD). The IETF 411 Administrative Oversight Committee (IAOC) oversees the IAD. IAOC 412 members are appointed by the Internet Society Board of Trustees, the 413 IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with the 414 IANA functions operator to establish annual IANA performance metrics 415 and operational procedures, and the resulting document is adopted as 416 an supplement to the MoU each year [MOUSUP]. In accordance with 417 these supplements, an annual review is performed to ensure that 418 protocol parameter requests are being processed according to the 419 established policies. 421 To date there have been no unresolvable disputes or issues. In the 422 unlikely event that a more difficult situation should arise, the IAOC 423 and the IAB would engage ICANN management to address the matter. The 424 MoU also provides an option for either party to terminate the 425 arrangement with six months notice. Obviously such action would only 426 be undertaken after serious consideration. 428 >>> 429 >>> Jurisdiction(s) in which the mechanism applies and the legal 430 >>> basis on which the mechanism rests. 431 >>> 433 IETF Response 435 This mechanism is global in nature. The current agreement does not 436 specify a jurisdiction. 438 >>>III. Proposed Post-Transition Oversight and Accountability 439 Arrangements 441 >>> 442 >>> This section should describe what changes your community is 443 >>> proposing to the arrangements listed in Section II.B in light of 444 >>> the transition. If your community is proposing to replace one or 445 >>> more existing arrangements with new arrangements, that 446 >>> replacement should be explained and all of the elements listed 447 >>> in Section II.B should be described for the new 448 >>> arrangements. Your community should provide its rationale and 449 >>> justification for the new arrangements. 450 >>> 451 >>> If your community's proposal carries any implications for 452 >>> existing policy arrangements described in Section II.A, those 453 >>> implications should be described here. 454 >>> 455 >>> If your community is not proposing changes to arrangements 456 >>> listed in Section II.B, the rationale and justification for that 457 >>> choice should be provided here. 458 >>> 460 IETF Response: 462 No major changes are required, however, the IETF community has 463 expressed a desire for several points to be addressed by supplemental 464 agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA 465 regime. Over the years since the creation of ICANN, the IETF, ICANN, 466 and IAB have together created a system of agreements, policies, and 467 oversight mechanisms that covers what is needed. 469 First and foremost, IANA protocol parameters registry updates will 470 continue to function day-to-day, as they have been doing for the last 471 decade or more. The IETF community is quite satisfied with the 472 current arrangement with ICANN. RFC 2860 remains in force and has 473 served the IETF community very well. RFC 6220 has laid out an 474 appropriate service description and requirements. 476 To address issues raised by the IETF community relating to 477 intellectual property rights, the IAOC is asked to engage the 478 appropriate parties, both inside and outside the IETF, to make clear 479 that data in the protocol parameters registries is in the public 480 domain. 482 To address a desire by the IETF community to have mechanisms that 483 allow for additional dispute resolution between the IETF and the 484 current IANA protocol registries operator, the IAOC is asked to 485 conclude a supplemental agreement regarding jurisdiction and any 486 necessary dispute resolution mechanisms that are mutually acceptable 487 to the parties. 489 To address concerns regarding appropriate contingencies to transition 490 to another operator, the IAOC is asked to conclude a supplemental 491 agreement that- 493 1. maintains the IANA functions operator's obligations established 494 under C.7.3 and I.61 of the current IANA functions contract 495 between ICANN and the NTIA [NTIA-Contract]; and 497 2. requires the transfer of any associated marks and identifiers to 498 subsequent operators. 500 Discussions during IETF 89 in London led to the following guiding 501 principles for IAB efforts that impact IANA protocol parameter 502 registries. These principles must be taken together; their order is 503 not significant. 505 1. The IETF protocol parameters registries function has been and 506 continues to be capably provided by the Internet technical community. 508 The strength and stability of the function and its foundation within 509 the Internet technical community are both important given how 510 critical protocol parameters are to the proper functioning of IETF 511 protocols. 513 We think the structures that sustain the protocol parameters 514 registries function needs to be strong enough that they can be 515 offered independently by the Internet technical community, without 516 the need for backing from external parties. And we believe we 517 largely are there already, although the system can be strengthened 518 further, and continuous improvements are being made. 520 2. The protocol parameters registries function requires openness, 521 transparency, and accountability. 523 Existing documentation of how the function is administered and 524 overseen is good [RFC2860], [RFC6220]. Further articulation and 525 clarity may be beneficial. It is important that the whole Internet 526 community can understand how the function works, and that the 527 processes for registering parameters and holding those who oversee 528 the protocol parameters function accountable for following those 529 processes are understood by all interested parties. We are committed 530 to making improvements here if necessary. 532 3. Any contemplated changes to the protocol parameters registries 533 function should respect existing Internet community agreements. 535 The protocol parameters registries function is working well. The 536 existing Memorandum of Understanding in RFC 2860 defines "the 537 technical work to be carried out by the Internet Assigned Numbers 538 Authority on behalf of the Internet Engineering Task Force and the 539 Internet Research Task Force." Any modifications to the protocol 540 parameters registries function should be made using the IETF process 541 to update RFC 6220 and other relevant RFCs. Put quite simply: 542 evolution, not revolution. 544 4. The Internet architecture requires and receives capable service 545 by Internet registries. 547 The stability of the Internet depends on capable provision of not 548 just IETF protocol parameters, but IP numbers, domain names, and 549 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 550 protocols. Thus we expect the role of the IETF in standards 551 development, architectural guidance, and allocation of certain name/ 552 number parameters to continue. IP multicast addresses and special- 553 use DNS names are two examples where close coordination is needed. 554 The IETF will continue to coordinate with ICANN, the RIRs, and other 555 parties that are mutually invested in the continued smooth operation 556 of the Internet registries. We fully understand the need to work 557 together. 559 5. The IETF will continue management of the protocol parameter 560 registry function as an integral component of the IETF standards 561 process and the use of resulting protocols. 563 RFC 6220 specifies the role and function of the protocol parameters 564 registry, which is critical to IETF standards processes and IETF 565 protocols. The IAB, on behalf of the IETF, has the responsibility to 566 define and manage the relationship with the protocol registry 567 operator role. This responsibility includes the selection and 568 management of the protocol parameter registry operator, as well as 569 management of the parameter registration process and the guidelines 570 for parameter allocation. 572 6. The protocol parameters registries are provided as a public 573 service. 575 Directions for the creation of protocol parameters registries and the 576 policies for subsequent additions and updates are specified in RFCs. 577 The protocol parameters registries are available to everyone, and 578 they are published in a form that allows their contents to be 579 included in other works without further permission. These works 580 include, but are not limited to, implementations of Internet 581 protocols and their associated documentation. 583 These principles will guide the IAB, IAOC, and the rest of the IETF 584 community as they work with ICANN to establish future IANA 585 performance metrics and operational procedures. 587 >>> IV Transition Implications 589 >>> 590 >>> This section should describe what your community views as the 591 >>> implications of the changes it proposed in Section III. These 592 >>> implications may include some or all of the following, or other 593 >>> implications specific to your community: 594 >>> 595 >>> o Description of operational requirements to achieve continuity 596 >>> of service and possible new service integration throughout 597 >>> the transition. 598 >>> o Risks to operational continuity 599 >>> o Description of any legal framework requirements in the 600 >>> absence of the NTIA contract 601 >>> o Description of how you have tested or evaluated the 602 >>> workability of any new technical or operational methods 603 >>> proposed in this document and how they compare to established 604 >>> arrangements. 605 >>> 607 IETF Response: 609 No structural changes are required. The principles listed above will 610 guide IAB, IAOC, and the rest of the IETF community as they work with 611 ICANN to establish future IANA performance metrics and operational 612 procedures, as they have in the past. 614 As no services are expected to change, no continuity issues are 615 anticipated, and there are no new technical or operational methods 616 proposed by the IETF to test. The IETF leadership, ICANN, and the 617 RIRs maintain an ongoing informal dialog to spot any unforeseen 618 issues that might arise as a result of other changes. 620 What is necessary as part of transition is the completion of 621 supplemental agreement(s) discussed in the previous section of this 622 RFP. 624 >>> 625 >>> V. NTIA Requirements 626 >>> 627 >>> Additionally, NTIA has established that the transition proposal 628 >>> must meet the following five requirements: 629 >>> 630 >>> "Support and enhance the multistakeholder model;" 631 >>> 633 IETF Response: 635 Everyone is welcome to participate in IETF activities. The policies 636 and procedures are outlined in the documents we named above. In- 637 person attendance is not required for participation, and many people 638 participate in email discussions that have never attended an IETF 639 meeting. An email account is the only requirement to participate. 640 The IETF makes use of both formal and informal lines of communication 641 to collaborate with other organizations within the multistakeholder 642 ecosystem. 644 >>> 645 >>> "Maintain the security, stability, and resiliency of the 646 >>> Internet DNS;" 647 >>> 649 IETF Response: 651 The DNS relies on some of the IETF protocol parameters registries. 652 As the current IANA functions operator, ICANN performs its task very 653 well, usually exceeding the service level agreement metrics.[METRICS] 654 Security, stability, and resiliency of the Internet DNS is best 655 protected by maintaining the current service in its current form. 657 >>> 658 >>> "Meet the needs and expectation of the global customers and 659 >>> partners of the IANA services;" 660 >>> 662 IETF Response: 664 Implementers and their users from around the world make use of the 665 IETF standards and the associated IANA protocol parameters 666 registries. The current IANA protocol parameters registries system 667 is meeting the needs of these global customers. This proposal 668 continues to meet their needs by maintaining the existing processes 669 that have served them well in the past. 671 >>> 673 >>> 674 >>> "Maintain the openness of the Internet." 675 >>> 677 IETF Response: 679 This proposal maintains the existing open framework that allows 680 anyone to participate in the development of IETF standards, including 681 the IANA protocol parameters registries policies. Further, an 682 implementer anywhere in the world has full access to the protocol 683 specification published in the RFC series and the protocol parameters 684 registries published at iana.org. Those who require assignments in 685 the IANA protocol registries will continue to be able to do so, as 686 specified by the existing policies for those registries. 688 >>> 689 >>> VI. Community Process 690 >>> 691 >>> This section should describe the process your community used for 692 >>> developing this proposal, including: 693 >>> 694 >>> o The steps that were taken to develop the proposal and to 695 >>> determine consensus. 696 >>> 698 IETF Response: 700 The IESG established the IANAPLAN working group to develop this 701 response. Anyone was welcome to join the discussion and participate 702 in the development of this response. An open mailing list 703 (ianaplan@ietf.org) was associated with the working group. In 704 addition, IETF's IANA practices have been discussed in the broader 705 community, and all input is welcome. 707 >>> 708 >>> Links to announcements, agendas, mailing lists, consultations and 709 >>> meeting proceedings. 710 >>> 712 IETF Response: [xxx to be completed in more detail] 714 The following list is not exhaustive, as there have been many open 715 discussions about this transition within the IETF community in the 716 past few months. 718 Creation of an open mailing list to discuss the transition: http://w 719 ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html 721 Announcement of a public session on the transition: http:// 722 www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html 724 Announcement by the IESG of the intent to form a working group: 726 http://www.ietf.org/mail-archive/web/ietf-announce/current/ 727 msg13170.html 729 >>> 730 >>> An assessment of the level of consensus behind your community's 731 >>> proposal, including a description of areas of contention or 732 >>> disagreement. 733 >>> 735 IETF Response: To be completed as the process progresses. 737 3. IANA Considerations 739 This memo is a response a request for proposals. No parameter 740 allocations or changes are sought. 742 4. Security Considerations 744 While the IANA framework has shown strong resiliency, the IETF will 745 continue to work with all relevant parties to facilitate improvements 746 in our standards. 748 5. Acknowledgments 750 This document does not define new processes, and so it seems we 751 acknowledge all of the preceding IAB members and members of the 752 community who developed the processes that we describe. The initial 753 version of this document was developed collaboratively through both 754 the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular 755 thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew 756 Sullivan, Leslie Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, 757 Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei 758 Robachevsky, Miles Fidelman, and Richard Hill. 760 6. Informative References 762 [METRICS] , "Performance Standards Metrics Report", , 763 . 765 [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of 766 Understanding between the IETF and ICANN)", , 767 . 769 [NTIA-Contract] 770 , "The NTIA Contract with ICANN", , . 774 [RFC-INDEX] 775 RFC Editor, , "Index of all Requests for Comments", RFC 776 Index, August 2014. 778 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 779 3", BCP 9, RFC 2026, October 1996. 781 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 782 Procedures", BCP 25, RFC 2418, September 1998. 784 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 785 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 786 May 2000. 788 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 789 Understanding Concerning the Technical Work of the 790 Internet Assigned Numbers Authority", RFC 2860, June 2000. 792 [RFC3172] Huston, G., "Management Guidelines & Operational 793 Requirements for the Address and Routing Parameter Area 794 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 796 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 797 Addresses", RFC 3307, August 2002. 799 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC 800 3595, September 2003. 802 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 803 Recall Process: Operation of the Nominating and Recall 804 Committees", BCP 10, RFC 3777, June 2004. 806 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 807 Administrative Support Activity (IASA)", BCP 101, RFC 808 4071, April 2005. 810 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 811 Addresses", RFC 4193, October 2005. 813 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 814 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 815 May 2008. 817 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 818 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 819 March 2010. 821 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., 822 Internet Architecture Board, "Defining the Role and 823 Function of IETF Protocol Parameter Registry Operators", 824 RFC 6220, April 2011. 826 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 827 RFC 6761, February 2013. 829 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 830 Autonomous System (AS) Number Space", RFC 6793, December 831 2012. 833 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. 834 Amour, "Affirmation of the Modern Paradigm for Standards", 835 RFC 6852, January 2013. 837 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 838 "Special-Purpose IP Address Registries", BCP 153, RFC 839 6890, April 2013. 841 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 842 Internet Numbers Registry System", RFC 7020, August 2013. 844 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 845 2014. 847 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 848 7282, June 2014. 850 Appendix A. Changes 852 NOTE: This section to be removed by RFC Editor at publication. 854 A.1. Changes from -01 to -02 856 o A better description special registries and BGP ASNs. 858 o Clarity on how the address space and ASNs are delegated. 860 o Many editorials corrected. 862 o Mention of the annual review as part of the SLAs. 864 o Change about how overlap is presented. 866 o A number of small wording changes based on feedback. 868 A.2. Changes from -00 to -01 870 o Front matter greatly reduced. 872 o Appendices with charter and RFP added. 874 o Jurisdiction text changed. 876 o Proposed changes include supplemental agreement(s) to address 877 jurisdiction, dispute resolution, and IPR, including names and 878 marks. 880 o Transition implications slightly modified to reference 881 supplemental agreement. 883 Appendix B. The Charter of the IANA Stewardship Coordination Group (ICG 885 Charter for the IANA Stewardship Transition Coordination Group V.10 887 (August 27, 2014) 889 The IANA stewardship transition coordination group (ICG) has one 890 deliverable: a proposal to the U.S. Commerce Department National 891 Telecommunications and Information Administration (NTIA) regarding 892 the transition of NTIA's stewardship of the IANA functions to the 893 global multi-stakeholder community. The group will conduct itself 894 transparently, consult with a broad range of stakeholders, and ensure 895 that its proposals support the security and stability of the IANA 896 functions. 898 The group's mission is to coordinate the development of a proposal 899 among the communities affected by the IANA functions. The IANA 900 functions are divided into three main categories: domain names, 901 number resources, and other protocol parameters. The domain names 902 category falls further into the country code and generic domain name 903 sub-categories. While there is some overlap among all of these 904 categories, each poses distinct organizational, operational and 905 technical issues, and each tends to have distinct communities of 906 interest and expertise. For those reasons it is best to have work on 907 the three categories of IANA parameters proceed autonomously in 908 parallel and be based in the respective communities. 910 The IANA stewardship transition process is taking place alongside a 911 parallel and related process on enhancing ICANN accountability. 912 While maintaining the accountability of Internet identifier 913 governance is central to both processes, this group's scope is 914 focused on the arrangements required for the continuance of IANA 915 functions in an accountable and widely accepted manner after the 916 expiry of the NTIA-ICANN contract. Nevertheless, the two processes 917 are interrelated and interdependent and should appropriately 918 coordinate their work. 920 The coordination group has four main tasks: 921 (i) Act as liaison to all interested parties, including the three 922 "operational communities" (i.e., those with direct operational 923 or service relationship with IANA; namely names, numbers, 924 protocol parameters). This task consists of: 925 a. Soliciting proposals from the operational communities 926 b. Soliciting the input of the broad group of communities 927 affected by the IANA functions 928 (ii) Assess the outputs of the three operational communities for 929 compatibility and interoperability 930 (iii) Assemble a complete proposal for the transition 931 (iv) Information sharing and public communication 932 Describing each in more detail: 933 (i) Liaison 934 a. Solicit proposals 936 The ICG expects a plan from the country code and generic name 937 communities (possibly a joint one), a plan from the numbers 938 community, and a plan from the protocol parameters community. 939 Members of the ICG will ensure that the communities from which they 940 are drawn are working on their part of the transition plans. This 941 involves informing them of requirements and schedules, tracking 942 progress, and highlighting the results or remaining issues. The role 943 of a coordination group member during this phase is to provide status 944 updates about the progress of his or her community in developing 945 their component, and to coordinate which community will develop a 946 transition proposal for each area of overlap (e.g., special-use 947 registry). 949 While working on the development of their proposals, the operational 950 communities are expected to address common requirements and issues 951 relating to the transition, in as far as they affect their parts of 952 the stewardship of IANA functions. 954 b. Solicit broader input 956 The ICG is open for input and feedback from all interested parties. 957 While no set of formal requirements related to a transition proposal 958 will be requested outside the operational communities, everyone's 959 input is welcome across all topics. 961 The ICG expects that all interested parties get involved as early as 962 possible in the relevant community processes. Input received 963 directly by the ICG may be referred to the relevant community 964 discussion. 966 The ICG members chosen from a particular community are the official 967 communication channel between the ICG and that community. 969 (ii) Assessment 971 When the group receives output from the communities it will discuss 972 and assess their compatibility and interoperability with the 973 proposals of the other communities. Each proposal should be 974 submitted with a clear record of how consensus has been reached for 975 the proposal in the community, and provide an analysis that shows the 976 proposal is in practice workable. The ICG should also compile the 977 input it has received beyond the operational communities, and review 978 the impacts of this input. 980 The ICG might at some point detect problems with the component 981 proposals. At that point the role of the ICG is to communicate that 982 back to the relevant communities so that they (the relevant 983 communities) can address the issues. It is not in the role of the 984 ICG to develop proposals or to select from among competing proposals. 986 (iii) Assembling and submitting a complete proposal 988 The assembly effort involves taking the proposals for the different 989 components and verifying that the whole fulfills the intended scope, 990 meets the intended criteria, that there are no missing parts, and 991 that the whole fits together. The whole also needs to include 992 sufficient independent accountability mechanisms for running the IANA 993 function. The ICG will then develop a draft final proposal that 994 achieves rough consensus within the ICG itself. The ICG will then 995 put this proposal up for public comment involving a reasonable period 996 of time for reviewing the draft proposal, analyzing and preparing 997 supportive or critical comments. The ICG will then review these 998 comments and determine whether modifications are required. If no 999 modifications are needed, and the coordination group agrees, the 1000 proposal will be submitted to NTIA. 1002 If changes are required to fix problems or to achieve broader 1003 support, the ICG will work with the operational communities in a 1004 manner similar to what was described in task (ii) above. Updates are 1005 subject to the same verification, review, and consensus processes as 1006 the initial proposals. If, in the ICG's opinion, broad public 1007 support for the proposal as articulated by the NTIA is not present, 1008 the parts of the proposal that are not supported return to the 1009 liaison phase. 1011 (iv) Information sharing 1013 The ICG serves as a central clearinghouse for public information 1014 about the IANA stewardship transition process. Its secretariat 1015 maintains an independent, publicly accessible and open website, under 1016 its own domain, where status updates, meetings and notices are 1017 announced, proposals are stored, the ICG members are listed, etc. As 1018 the development of the transition plans will take some time, it is 1019 important that information about ongoing work is distributed early 1020 and continuously. This will enable sharing of ideas and the 1021 detection of potential issues. 1023 Appendix C. IANA Stewardship Transition Coordination Group Request for 1024 Proposals 1026 IANA Stewardship Transition Coordination Group Request for Proposals 1028 8 September 2014 1030 Introduction 1032 Under the IANA1 Stewardship Transition Coordination Group (ICG) 1033 Charter,2 the ICG has four main tasks: 1035 (i) Act as liaison to all interested parties in the IANA 1036 stewardship transition, including the three "operational 1037 communities" (i.e., those with direct operational or service 1038 relationships with the IANA functions operator; namely names, 1039 numbers, protocol parameters). This task consists of: 
 1041 a. Soliciting proposals from the operational communities 1042 b. Soliciting the input of the broad group of communities 1043 affected by the
IANA functions 1045 (ii) Assess the outputs of the three operational communities for 1046 compatibility and interoperability (iii) Assemble a complete 1047 proposal for the transition 1049 (iv) Information sharing and public communication 1051 This Request for Proposals (RFP) addresses task (i) of the ICG 1052 Charter. This RFP does not preclude any form of input from the 1053 non-operational communities. 1055 0. Complete Formal Responses 1057 The IANA Stewardship Transition Coordination Group (ICG) seeks 1058 complete formal responses to this RFP through processes which are to 1059 be convened by each of the "operational communities" of IANA (i.e., 1060 those with direct operational or service relationships with the IANA 1061 functions operator, in connection with names, numbers, or protocol 1062 parameters). 1064 Proposals should be supported by the broad range of stakeholders 1065 participating in the proposal development process. Proposals should 1066 be developed through a transparent process that is open to and 1067 inclusive of all stakeholders interested in participating in the 1068 development of the proposal. In order to help the ICG maintain its 1069 light coordination role, all interested and affected parties are 1070 strongly encouraged to participate directly in these community 1071 processes. 1073 The following link provides information about ongoing community 1074 processes and how to participate in them, and that will continue to 1075 be updated over time: 1077 https://www.icann.org/en/stewardship/community 1079 In this RFP, "IANA" refers to the functions currently specified in 1080 the agreement between NTIA and ICANN 1081 [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 1082 as any other functions traditionally performed by the IANA functions 1083 operator. SAC-067 1085 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] 1086 provides one description of the many different meanings of the term 1087 "IANA" and may be useful reading in addition to the documents 1088 constituting the agreement itself. 1090 Communities are asked to adhere to open and inclusive processes in 1091 developing their responses, so that all community members may fully 1092 participate in and observe those processes. Communities are also 1093 asked to actively seek out and encourage wider participation by any 1094 other parties with interest in their response. 1096 A major challenge of the ICG will be to identify and help to 1097 reconcile differences between submitted proposals, in order to 1098 produce a single plan for the transition of IANA 1099 stewardship. Submitted Proposals should therefore focus on those 1100 elements that are considered to be truly essential to the transition 1101 of their specific IANA functions. The target deadline for all 1102 complete formal responses to this RFP is 15 January 2015. 1104 I. Comments 1106 While the ICG is requesting complete formal proposals through 1107 processes convened by each of the operational communities, and that 1108 all interested parties get involved as early as possible in the 1109 relevant community processes, some parties may choose to provide 1110 comments directly to the ICG about specific aspects of particular 1111 proposals, about the community processes, or about the ICG's own 1112 processes. Comments may be directly submitted to the ICG any time 1113 via email to icg-forum@icann.org. Comments will be publicly archived 1114 at . 1116 Commenters should be aware that ICG will direct comments received to 1117 the relevant operational communities if appropriate. The ICG will 1118 review comments received as time and resources permit and in 1119 accordance with the overall timeline for the transition. That is, 1120 comments received about specific proposals may not be reviewed until 1121 those proposals have been submitted to the ICG. The ICG may 1122 establish defined public comment periods about specific topics in 1123 the future, after the complete formal responses to the RFP have been 1124 received. 1126 Required Proposal Elements 1128 The ICG encourages each community to submit a single proposal that 1129 contains the elements described in this section. 1131 Communities are requested to describe the elements delineated in the 1132 sections below in as much detail possible, and according to the 1133 suggested format/structure, to allow the ICG to more easily 1134 assimilate the results. While each question is narrowly defined to 1135 allow for comparison between answers, respondents are encouraged to 1136 provide further information in explanatory sections, including 1137 descriptive summaries of policies/practices and associated 1138 references to source documents of specific policies/practices. In 1139 this way, the responses to the questionnaire will be useful at the 1140 operational level as well as to the broader stakeholder communities. 1142 In the interest of completeness and consistency, proposals should 1143 cross-reference wherever appropriate the current IANA Functions 1144 Contract[3] when describing existing arrangements and proposing 1145 changes to existing arrangements. 1147 0. Proposal type 1149 Identify which category of the IANA functions this submission 1150 proposes to address: 1151 [ ] Names [ ] Numbers [ ] Protocol Parameters 1153 I. Description of Community's Use of IANA Functions 1154 This section should list the specific, distinct IANA functions your 1155 community relies on. For each IANA function on which your community 1156 relies, please provide the following: 1158 o A description of the function; 1159 o A description of the customer(s) of the function; 1160 o What registries are involved in providing the function; 1161 o A description of any overlaps or interdependencies between your 1162 IANA requirements and the functions required by other customer 1163 communities. 1165 If your community relies on any other IANA service or activity 1166 beyond the scope of the IANA functions contract, you may describe 1167 them here. In this case please also describe how the service or 1168 activity should be addressed by the transition plan. 1170 II. Existing, Pre-Transition Arrangements 1172 This section should describe how existing IANA-related arrangements 1173 work, prior to the transition. 1175 [3] http://www.ntia.doc.gov/files/ntia/ 1176 publications/sf_26_pg_1-2-final_award_and_sacs.pdf 1178 A. Policy Sources 1180 This section should identify the specific source(s) of policy which 1181 must be followed by the IANA functions operator in its conduct of 1182 the services or activities described above. If there are distinct 1183 sources of policy or policy development for different IANA 1184 functions, then please describe these separately. For each source of 1185 policy or policy development, please provide the following: 1187 o Which IANA function (identified in Section I) are affected. 1188 o A description of how policy is developed and established and who 1189 is involved in policy development and establishment. 1190 o A description of how disputes about policy are resolved. 1191 o References to documentation of policy development and dispute 1192 resolution processes. 1194 B. Oversight and Accountability 1196 This section should describe all the ways in which oversight is 1197 conducted over the IANA functions operator's provision of the 1198 services and activities listed in Section I and all the ways in 1199 which the IANA functions operator is currently held accountable for 1200 the provision of those services. For each oversight or 1201 accountability mechanism, please provide as many of the following as 1202 are applicable: 1204 Which IANA functions (identified in Section I) are affected. If the 1205 policy sources identified in Section II.A are affected, identify 1206 which ones are affected and explain in what way. 1208 o A description of the entity or entities that provide oversight or 1209 perform accountability functions, including how individuals are 1210 selected or removed from participation in those entities. 1211 o A description of the mechanism (e.g., contract, reporting scheme, 1212 auditing scheme, etc.). This should include a description of the 1213 consequences of the IANA functions operator not meeting the 1214 standards established by the mechanism, the extent to which the 1215 output of the mechanism is transparent and the terms under which 1216 the mechanism may change. 1217 o Jurisdiction(s) in which the mechanism applies and the legal basis 1218 on which the mechanism rests. 1220 III. Proposed Post-Transition Oversight and Accountability 1221 Arrangements 1223 This section should describe what changes your community is 1224 proposing to the arrangements listed in Section II.B in light of the 1225 transition. If your community is proposing to replace one or more 1226 existing arrangements with new arrangements, that replacement should 1227 be explained and all of the elements listed in Section II.B should 1228 be described for the new arrangements. Your community should provide 1229 its rationale and justification for the new arrangements. 1231 If your community's proposal carries any implications for the 1232 interface between the IANA functions and existing policy arrangements 1233 described in Section II.A, those implications should be described 1234 here. 1236 If your community is not proposing changes to arrangements listed in 1237 Section II.B, the rationale and justification for that choice should 1238 be provided here. 1240 IV. Transition Implications 1242 This section should describe what your community views as the 1243 implications of the changes it proposed in Section III. These 1244 implications may include some or all of the following, or other 1245 implications specific to your community: 1247 Description of operational requirements to achieve continuity of 1248 service and possible new service integration throughout the 1249 transition. 1251 Risks to operational continuity and how they will be addressed. 1252 Description of any legal framework requirements in the absence of the 1253 NTIA contract. Description of how you have tested or evaluated the 1254 workability of any new technical or operational methods proposed in 1255 this document and how they compare to established arrangements. 1256 Description of how long the proposals in Section III are expected to 1257 take to complete, and any intermediate milestones that may occur 1258 before they are completed. 1260 V. NTIA Requirements 1262 Additionally, NTIA has established that the transition proposal must 1263 meet the following five requirements: 1264 o Support and enhance the multistakeholder model; 1265 o Maintain the security, stability, and resiliency of the Internet 1266 DNS; 1267 o Meet the needs and expectation of the global customers and 1268 partners of the IANA functions; 1269 o Maintain the openness of the Internet; 1270 o The proposal must not replace the NTIA role with a government-led 1271 or an inter-governmental organization solution. 1273 This section should explain how your community's proposal meets these 1274 requirements and how it responds to the global interest in the IANA 1275 functions. 1277 VI. Community Process 1278 This section should describe the process your community used for 1279 developing this proposal, including: 1280 o The steps that were taken to develop the proposal and to determine 1281 consensus. 1282 o Links to announcements, agendas, mailing lists, consultations and 1283 meeting proceedings. 1284 o An assessment of the level of consensus behind your community's 1285 proposal, including a description of areas of contention or 1286 disagreement. 1288 Authors' Addresses 1289 Eliot Lear (editor) 1290 Richtistrasse 7 1291 Wallisellen, ZH CH-8304 1292 Switzerland 1294 Phone: +41 44 878 9200 1295 Email: lear@cisco.com 1297 Russ Housley (editor) 1298 918 Spring Noll Drive 1299 Herndon, VA 20170 1300 USA 1302 Email: housley@vigilsec.com