diff options
Diffstat (limited to 'doc/rfc/rfc7979.txt')
| -rw-r--r-- | doc/rfc/rfc7979.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc7979.txt b/doc/rfc/rfc7979.txt new file mode 100644 index 0000000..06b916c --- /dev/null +++ b/doc/rfc/rfc7979.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Lear, Ed. +Request for Comments: 7979 R. Housley, Ed. +Category: Informational August 2016 +ISSN: 2070-1721 + + + Response to the IANA Stewardship Transition Coordination Group (ICG) + Request for Proposals on the IANA Protocol Parameters Registries + +Abstract + + The U.S. National Telecommunications and Information Administration + (NTIA) solicited a request from the Internet Corporation for Assigned + Names and Numbers (ICANN) to propose how the NTIA should end its + oversight of the Internet Assigned Numbers Authority (IANA) + functions. After broad consultations, ICANN in turn created the IANA + Stewardship Transition Coordination Group. That group solicited + proposals for the three major IANA functions: names, numbers, and + protocol parameters. This document contains the IETF response to + that solicitation for protocol parameters. It was included in an + aggregate response to the NTIA alongside those for names and + numbering resources that are being developed by their respective + operational communities. A reference to that response may be found + in the introduction, and additional correspondence is included in the + Appendix. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7979. + + + + + + + + + + +Lear & Housley Informational [Page 1] + +RFC 7979 IANA ICG Response August 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 4 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 7.2. Informative References . . . . . . . . . . . . . . . . . 22 + Appendix A. The Charter of the IANA Stewardship Coordination + Group (ICG) . . . . . . . . . . . . . . . . . . . . 25 + Appendix B. IANA Stewardship Transition Coordination Group + Request for Proposals . . . . . . . . . . . . . . . 28 + Appendix C. Correspondence of the IETF to the ICG . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + + + + + + + + + + + + + + + + + + + +Lear & Housley Informational [Page 2] + +RFC 7979 IANA ICG Response August 2016 + + +1. IETF Introduction + + In March of 2014, the U.S. National Telecommunications and + Information Administration (NTIA) announced its intent to transition + oversight of Internet Assigned Numbers Authority (IANA) functions + [NTIA-Announce]. In that announcement, NTIA asked the Internet + Corporation for Assigned Names and Numbers (ICANN) to establish a + process to deliver a proposal for transition. As part of that + process, the IANA Stewardship Transition Coordination Group (ICG) was + formed. The charter for the ICG can be found in Appendix A. The ICG + in turn solicited proposals regarding post-transition arrangements + from the names, numbers, and protocol parameters communities in order + to put forth a proposal to the NTIA. The final request for proposal + (RFP) can be found in Appendix B. The response from the ICG to the + NTIA may be found at [ICG-Response]. + + While there are interactions between all of the IANA functions and + IETF standards, this document specifically addresses the protocol + parameters registries function. Section 1 (this section) contains an + introduction that is sourced solely within the IETF. Section 2 + contains the questionnaire that was written by the ICG and a formal + response by the IETF. We have quoted questions from that + questionnaire with ">>> ", and we have prefaced answers to questions + being asked with "IETF Response:". Note that there are small changes + to the questions asked in order to match the RFC format. + + We note that the following text was stated as a footnote in the + original RFP: + + In this RFP, "IANA" refers to the functions currently + specified in the agreement between NTIA and ICANN + [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as + well as any other functions traditionally performed by the IANA + functions operator. SAC-067 + [https://www.icann.org/en/system/files/files/sac-067-en.pdf] + provides one description of the many different meanings of the + term "IANA" and may be useful reading in addition to the + documents constituting the agreement itself. + + + + + + + + + + + + + +Lear & Housley Informational [Page 3] + +RFC 7979 IANA ICG Response August 2016 + + +2. The Formal RFP Response + + The entire Request for Proposals, including introduction, can be + found in Appendix B. + + >>> + >>> 0. Proposal Type + >>> + >>> Identify which category of the IANA functions this + >>> submission proposes to address: + >>> + + IETF Response: + Protocol Parameters + + This response states the existing practice of the IETF, and also + represents the views of the Internet Architecture Board and the IETF. + + >>> + >>> I. Description of Community's Use of IANA Functions + >>> + >>> This section should list the specific, distinct IANA services + >>> or activities your community relies on. For each IANA service + >>> or activity on which your community relies, please provide the + >>> following: + >>> A description of the service or activity. + >>> + + IETF Response: + + Many IETF protocols make use of commonly defined protocol parameters. + These parameters are used by implementers, who are the primary users + of the IETF standards and other documents. To ensure consistent + interpretation of these parameter values by independent + implementations, and to promote universal interoperability, these + IETF protocol specifications define and require globally available + registries containing the parameter values and a pointer to any + associated documentation. The IETF uses the IANA protocol parameters + registries to store this information in a public location. The IETF + community presently accesses the protocol parameter registries via + references based on the iana.org domain name, and makes use of the + term "IANA" in the protocol parameter registry processes [RFC5226]. + + ICANN currently operates the .ARPA top level domain on behalf of the + Internet Architecture Board (IAB). This zone is used for certain + Internet infrastructure services that are delegated beneath it. The + IETF considers .ARPA part of the protocol parameters registries for + purposes of this response. + + + +Lear & Housley Informational [Page 4] + +RFC 7979 IANA ICG Response August 2016 + + + >>> + >>> A description of the customer(s) of the service or activity. + >>> + + IETF Response: + + The IANA protocol parameters registries operator maintains the + protocol parameters registries for the IETF in conformance with all + relevant IETF policies, in accordance with the Memorandum of + Understanding [RFC2860] and associated supplemental agreements that + include service level agreements (SLAs) established between the IETF + and ICANN [MOUSUP]. + + The IETF is a global organization that produces voluntary standards, + whose mission is to produce high quality, relevant technical and + engineering documents that influence the way people design, use, and + manage the Internet in such a way as to make the Internet work better + [RFC3935]. IETF standards are published in the RFC series. The IETF + is responsible for the key standards that are used on the Internet + today, including IP, TCP, DNS, BGP, and HTTP, to name but a few. + + The IETF operates in an open and transparent manner [RFC6852]. The + processes that govern the IETF are also published in the RFC series. + The Internet Standards Process is documented in [RFC2026]. That + document explains not only how standards are developed, but also how + disputes about decisions are resolved. RFC 2026 has been amended a + number of times [BCP9info]. The standards process can be amended in + the same manner that standards are approved. That is, someone + proposes a change by submitting a temporary document known as an + Internet-Draft, the community discusses it, and if rough consensus + can be found the change is approved by the Internet Engineering + Steering Group (IESG), who also have day-to-day responsibility for + declaring IETF consensus on technical decisions, including those that + affect the IANA protocol parameters registries. Anyone may propose a + change during a Last Call, and anyone may participate in the + community discussion. + + + + + + + + + + + + + + + +Lear & Housley Informational [Page 5] + +RFC 7979 IANA ICG Response August 2016 + + + >>> + >>> What registries are involved in providing the service or + >>> activity. + >>> + + IETF Response: + + The protocol parameters registries are the product of IETF work. + These also include the top-level registry for the entire IP address + space and some of its sub-registries, autonomous system number space, + and a number of special use registries with regard to domain names. + For more detail please refer to the documentation in the "overlaps or + interdependencies" section. + + Administration of the protocol parameters registries is the service + that is provided to the IETF. + + >>> + >>> A description of any overlaps or interdependencies between your + >>> IANA requirements and the functions required by other customer + >>> communities. + >>> + + IETF Response: + + In this context, the IETF considers "overlap" to be where there is in + some way shared responsibility for a single registry across multiple + organizations. In this sense, there is no overlap between + organizations because responsibility for each registry is carefully + delineated. There are, however, points of interaction between other + organizations, and a few cases where the IETF may further define the + scope of a registry for technical purposes. This is the case with + both names and numbers, as described in the paragraphs below. In all + cases, the IETF coordinates with the appropriate organizations. + + It is important to note that the IETF does not have formal + membership. The term "the IETF" includes anyone who wishes to + participate in the IETF, and IETF participants may also be members of + other communities. Staff and participants from ICANN and the + Regional Internet Registries (RIRs) regularly participate in IETF + activities. + + o The IETF has specified a number of special use registries with + regard to domain names. These registries require coordination + with ICANN as the policy authority for the DNS root, including + community groups that are responsible for ICANN policy on domain + names such as the Generic Names Supporting Organization (GNSO) and + the Country Code Names Supporting Organization (ccNSO). There are + + + +Lear & Housley Informational [Page 6] + +RFC 7979 IANA ICG Response August 2016 + + + already mechanisms in place to perform this coordination, and the + capacity to modify those mechanisms to meet new conditions as they + might arise. [RFC6761] + + o The IETF specifies the DNS protocol. From time to time there have + been and will be updates to that protocol. As we make changes we + will broadly consult the operational community about the impact of + those changes, as we have done in the past. + + o The IETF specifies minimum requirements for root servers. + [RFC2870] Those requirements are currently under review, in + consultations with the root server community. + + o The routing architecture has evolved over time, and is expected to + continue to do so. Such evolution may have an impact on + appropriate IP address allocation strategies. If and when that + happens, the IETF will consult and coordinate with the RIR + community, as we have done in the past. + + o The IETF is responsible for policy relating to the entire IP + address space and AS number space. Through the IANA protocol + parameters registries, the IETF delegates unicast IP address and + AS number ranges to the RIRs [RFC7020],[RFC7249]. Special address + allocation, such as multicast and anycast addresses, often require + coordination. Another example of IP addresses that are not + administered by the RIR system is Unique Local Addresses (ULAs) + [RFC4193], where local networks employ a prefix that is not + intended to be routed on the public Internet. New special address + allocations are added, from time to time, related to the evolution + of the standards. In all cases, these special assignments are + listed in the IANA protocol paramters registries. + + o The IETF maintains sub-registries for special IPv4 and IPv6 + assignments. These are specified in [RFC3307], [RFC5771], and + [RFC6890]. The IETF coordinates such assignments with the RIRs. + + o Changes to IETF standards may have impact on operations of RIRs + and service providers. A recent example is the extensions to BGP + to carry the Autonomous System numbers as four-octet entities + [RFC6793]. It is important to note that this change occurred out + of operational necessity, and it demonstrated strong alignment + between the RIRs and the IETF. + + + + + + + + + +Lear & Housley Informational [Page 7] + +RFC 7979 IANA ICG Response August 2016 + + + >>> II. Existing, Pre-Transition Arrangements + + >>> + >>> This section should describe how existing IANA-related + >>> arrangements work, prior to the transition. + >>> + >>> A. Policy Sources + >>> + >>> + >>> This section should identify the specific source(s) of policy + >>> which must be followed by the IANA functions operator in its + >>> conduct of the services or activities described above. If there + >>> are distinct sources of policy or policy development for + >>> different IANA activities, then please describe these + >>> separately. For each source of policy or policy development, + >>> please provide the following: + >>> + >>> Which IANA service or activity (identified in Section I) is + >>> affected. + >>> + + IETF Response: + + The protocol parameters registries. + + >>> + >>> A description of how policy is developed and established and + >>> who is involved in policy development and establishment. + >>> + + IETF Response: + + Policy for overall management of the protocol parameters registries + is stated in [RFC6220] and [RFC5226]. The first of these documents + explains the model for how the registries are to be operated, how + policy is set, and how oversight takes place. RFC 5226 specifies the + policies that specification writers may employ when they define new + protocol registries in the "IANA Considerations" section of each + specification. All policies at the IETF begin with a proposal in the + form of an Internet-Draft. Anyone may submit such a proposal. If + there is sufficient interest, a working group whose scope includes + the proposed work may choose to adopt it, the IESG may choose to + create a working group, or an Area Director may choose to sponsor the + draft. In any case, anyone may comment on the proposal as it + progresses. A proposal cannot be passed by the IESG unless it enjoys + sufficient community support as to indicate rough consensus + [RFC7282]. In each case, a "Last Call" is made so that there is + notice of any proposed change to a policy or process. Anyone may + + + +Lear & Housley Informational [Page 8] + +RFC 7979 IANA ICG Response August 2016 + + + comment during a Last Call. For example, this process is currently + being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis]. + + >>> + >>> A description of how disputes about policy are resolved. + >>> + + IETF Response: + + Most disputes are handled at the lowest level through the working + group and rough consensus processes. Should anyone disagree with any + action, Section 6.5 of [RFC2026] specifies a multi-level conflict + resolution and appeals process that includes the responsible Area + Director, the IESG, and the IAB. Should appeals be upheld, an + appropriate remedy is applied. In the case where someone claims that + the procedures themselves are insufficient or inadequate in some way + to address a circumstance, one may appeal an IAB decision to the + Internet Society Board of Trustees. + + >>> + >>> References to documentation of policy development and dispute + >>> resolution processes. + >>> + + IETF Response: + + As mentioned above, [RFC2026] Section 6.5 specifies a conflict + resolution and appeals process. [RFC2418] specifies working group + procedures. Note that both of these documents have been amended in + later RFCs as indicated in the [RFC-INDEX]. + + >>> + >>> B. Oversight and Accountability + >>> + >>> This section should describe all the ways in which oversight is + >>> conducted over IANA functions operator's provision of the + >>> services and activities listed in Section I and all the ways in + >>> which IANA functions operator is currently held accountable for + >>> the provision of those services. For each oversight or + >>> accountability mechanism, please provide as many of the + >>> following as are applicable: + >>> + >>> Which IANA service or activity (identified in Section I) is + >>> affected. + >>> + + + + + + +Lear & Housley Informational [Page 9] + +RFC 7979 IANA ICG Response August 2016 + + + IETF Response: + + The protocol parameters registries. + + >>> + >>> If not all policy sources identified in Section II.A are + >>> affected, identify which ones are affected. + >>> + + IETF Response: + + All policy sources relating to the protocol parameters registry are + affected. + + >>> + >>> A description of the entity or entities that provide oversight + >>> or perform accountability functions, including how individuals + >>> are selected or removed from participation in those entities. + >>> + + IETF Response: + + The Internet Architecture Board (IAB) is an oversight body of the + IETF whose responsibilities include, among other things, confirming + appointment of IESG members, managing appeals as discussed above, + management of certain domains, including .ARPA [RFC3172], and general + architectural guidance to the broader community. The IAB must + approve the appointment of an organization to act as IANA operator on + behalf of the IETF. The IAB is also responsible for establishing + liaison relationships with other organizations on behalf of the IETF. + The IAB's charter is to be found in [RFC2850]. + + The IAB members are selected and may be recalled through a Nominating + Committee (NOMCOM) process, which is described in [RFC3777] and its + updates. This process provides for selection of active members of + the community who themselves agree upon a slate of candidates. The + active members are chosen randomly from volunteers with a history of + participation in the IETF, with limits regarding having too many + active members with the same affiliation. The selection of the + active members is performed in a manner that makes it possible for + anyone to verify that the correct procedure was followed. The slate + of candidates selected by the active members are sent to the Internet + Society Board of Trustees for confirmation. In general, members are + appointed for terms of two years. The IAB selects its own chair. + + The IAB provides oversight of the protocol parameters registries of + the IETF, and is responsible for selecting appropriate operator(s) + and related per-registry arrangements. Especially when relationships + + + +Lear & Housley Informational [Page 10] + +RFC 7979 IANA ICG Response August 2016 + + + among protocols call for it, registries are at times operated by, or + in conjunction with, other bodies. Unless the IAB or IETF has + concluded that special treatment is needed, the operator for + registries is currently ICANN. + + >>> + >>> A description of the mechanism (e.g., contract, reporting + >>> scheme, auditing scheme, etc.). This should include a + >>> description of the consequences of the IANA functions operator + >>> not meeting the standards established by the mechanism, the + >>> extent to which the output of the mechanism is transparent and + >>> the terms under which the mechanism may change. + >>> + + IETF Response: + + A memorandum of understanding (MoU) between ICANN and the IETF + community has been in place since 2000. It can be found in + [RFC2860]. The MoU defines the work to be carried out by the IANA + functions operator for the IETF and the Internet Research Task Force + (IRTF), a peer organization to the IETF that focuses on + research.[RFC2014] Each year a service level agreement is negotiated + that supplements the MoU. + + Day-to-day administration and contract management is the + responsibility of the IETF Administrative Director (IAD). The IETF + Administrative Oversight Committee (IAOC) oversees the IAD. The + members of the IAOC are also the trustees of the IETF Trust, whose + main purpose is to hold certain intellectual property for the benefit + of the IETF as a whole. IAOC members are appointed by the Internet + Society Board of Trustees, the IAB, the IESG, and the NOMCOM + [RFC4071]. The IAOC works with the IANA functions operator to + establish annual IANA performance metrics [METRICS] and operational + procedures, and the resulting document is adopted as an supplement to + the MoU each year [MOUSUP]. Starting from 2014, in accordance with + these supplements, an annual audit is performed to ensure that + protocol parameter requests are being processed according to the + established policies. The conclusions of this audit will be + available for anyone in the world to review. + + To date there have been no unresolvable disputes or issues between + the IETF and the current IANA functions operator. [RFC2860] + specifies that should a technical dispute arise, "the IANA shall seek + and follow technical guidance exclusively from the IESG." In the + unlikely event that a more difficult situation should arise, the IAOC + and the IAB would engage ICANN management to address the matter. The + MoU also provides an option for either party to terminate the + arrangement with six months notice. Obviously such action would only + + + +Lear & Housley Informational [Page 11] + +RFC 7979 IANA ICG Response August 2016 + + + be undertaken after serious consideration. In that case a new IANA + functions operator would be selected, and a new agreement with that + operator would be established. + + >>> + >>> Jurisdiction(s) in which the mechanism applies and the legal + >>> basis on which the mechanism rests. + >>> + + IETF Response + + This mechanism is global in nature. The current agreement does not + specify a jurisdiction. + + >>>III. Proposed Post-Transition Oversight and Accountability + >>>Arrangements + + >>> + >>> This section should describe what changes your community is + >>> proposing to the arrangements listed in Section II.B in light of + >>> the transition. If your community is proposing to replace one or + >>> more existing arrangements with new arrangements, that + >>> replacement should be explained and all of the elements listed + >>> in Section II.B should be described for the new + >>> arrangements. Your community should provide its rationale and + >>> justification for the new arrangements. + >>> + >>> If your community's proposal carries any implications for + >>> existing policy arrangements described in Section II.A, those + >>> implications should be described here. + >>> + >>> If your community is not proposing changes to arrangements + >>> listed in Section II.B, the rationale and justification for that + >>> choice should be provided here. + >>> + + IETF Response: + + No new organizations or structures are required. Over the years + since the creation of ICANN, the IETF, ICANN, and IAB have together + created a system of agreements, policies, and oversight mechanisms + that already cover what is needed. This system has worked well + without any operational involvement from the NTIA. + + IANA protocol parameters registry updates will continue to function + day-to-day, as they have been doing for the last decade or more. The + IETF community is very satisfied with the current arrangement with + + + + +Lear & Housley Informational [Page 12] + +RFC 7979 IANA ICG Response August 2016 + + + ICANN. RFC 2860 remains in force and has served the IETF community + very well. RFC 6220 has laid out an appropriate service description + and requirements. + + However in the absence of the NTIA contract a few new arrangements + may be needed in order to ensure the IETF community's expectations + are met. Those expectations are the following: + + o The protocol parameters registries are in the public domain. It + is the preference of the IETF community that all relevant parties + acknowledge that fact as part of the transition. + + o It is possible in the future that the operation of the protocol + parameters registries may be transitioned from ICANN to subsequent + operator(s). It is the preference of the IETF community that, as + part of the NTIA transition, ICANN acknowledge that it will carry + out the obligations established under C.7.3 and I.61 of the + current IANA functions contract between ICANN and the NTIA + [NTIA-Contract] to achieve a smooth transition to subsequent + operator(s), should the need arise. Furthermore, in the event of + a transition it is the expectation of the IETF community that + ICANN, the IETF, and subsequent operator(s) will work together to + minimize disruption in the use the protocol parameters registries + or other resources currently located at iana.org. + + In developing our response we have been mindful of the following + points that the IETF community has discussed over the last year + [ProtoParamEvo14] that have led to the following guiding principles + for IAB efforts that impact IANA protocol parameter registries. + These principles must be taken together; their order is not + significant. + + 1. The IETF protocol parameters registries function has been and + continues to be capably provided by the Internet technical community. + + The strength and stability of the function and its foundation within + the Internet technical community are both important given how + critical protocol parameters are to the proper functioning of IETF + protocols. + + We think the structures that sustain the protocol parameters + registries function need to be strong enough that they can be offered + independently by the Internet technical community, without the need + for backing from external parties. And we believe we largely are + there already, although the system can be strengthened further, and + continuous improvements are being made. + + + + + +Lear & Housley Informational [Page 13] + +RFC 7979 IANA ICG Response August 2016 + + + 2. The protocol parameters registries function requires openness, + transparency, and accountability. + + Existing documentation of how the function is administered and + overseen is good [RFC2860], [RFC6220]. Further articulation and + clarity may be beneficial. It is important that the whole Internet + community can understand how the function works, and that the + processes for registering parameters and holding those who oversee + the protocol parameters function accountable for following those + processes are understood by all interested parties. We are committed + to making improvements here if necessary. + + 3. Any contemplated changes to the protocol parameters registries + function should respect existing Internet community agreements. + + The protocol parameters registries function is working well. The + existing Memorandum of Understanding in RFC 2860 defines "the + technical work to be carried out by the Internet Assigned Numbers + Authority on behalf of the Internet Engineering Task Force and the + Internet Research Task Force." Any modifications to the protocol + parameters registries function should be made using the IETF process + to update RFC 6220 and other relevant RFCs. Put quite simply: + evolution, not revolution. + + 4. The Internet architecture requires and receives capable service + by Internet registries. + + The stability of the Internet depends on capable provision of not + just IETF protocol parameters, but IP numbers, domain names, and + other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined + protocols. Thus we expect the role of the IETF in standards + development, architectural guidance, and allocation of certain name/ + number parameters to continue. IP multicast addresses and special- + use DNS names are two examples where close coordination is needed. + The IETF will continue to coordinate with ICANN, the RIRs, and other + parties that are mutually invested in the continued smooth operation + of the Internet registries. We fully understand the need to work + together. + + 5. The IETF will continue management of the protocol parameter + registry function as an integral component of the IETF standards + process and the use of resulting protocols. + + RFC 6220 specifies the role and function of the protocol parameters + registry, which is critical to IETF standards processes and IETF + protocols. The IAB, on behalf of the IETF, has the responsibility to + define and manage the relationship with the protocol registry + operator role. This responsibility includes the selection and + + + +Lear & Housley Informational [Page 14] + +RFC 7979 IANA ICG Response August 2016 + + + management of the protocol parameter registry operator, as well as + management of the parameter registration process and the guidelines + for parameter allocation. + + 6. The protocol parameters registries are provided as a public + service. + + Directions for the creation of protocol parameters registries and the + policies for subsequent additions and updates are specified in RFCs. + The protocol parameters registries are available to everyone, and + they are published in a form that allows their contents to be + included in other works without further permission. These works + include, but are not limited to, implementations of Internet + protocols and their associated documentation. + + These principles will guide the IAB, IAOC, and the rest of the IETF + community as they work with ICANN to establish future IANA + performance metrics and operational procedures. + + >>> IV Transition Implications + + >>> + >>> This section should describe what your community views as the + >>> implications of the changes it proposed in Section III. These + >>> implications may include some or all of the following, or other + >>> implications specific to your community: + >>> + >>> o Description of operational requirements to achieve continuity + >>> of service and possible new service integration throughout + >>> the transition. + >>> o Risks to operational continuity + >>> o Description of any legal framework requirements in the + >>> absence of the NTIA contract + >>> o Description of how you have tested or evaluated the + >>> workability of any new technical or operational methods + >>> proposed in this document and how they compare to established + >>> arrangements. + >>> + + IETF Response: + + No structural changes are required for the handling of protocol + parameters. The principles listed above will guide IAB, IAOC, and + the rest of the IETF community as they work with ICANN to establish + future IANA performance metrics and operational procedures, as they + have in the past. + + + + + +Lear & Housley Informational [Page 15] + +RFC 7979 IANA ICG Response August 2016 + + + As no services are expected to change, no continuity issues are + anticipated, and there are no new technical or operational methods + proposed by the IETF to test. The IETF leadership, ICANN, and the + RIRs maintain an ongoing informal dialog to spot any unforeseen + issues that might arise as a result of other changes. + + What is necessary as part of transition is the completion of any + supplemental agreement(s) necessary to achieve the requirements + outlined in our response in Section III of this RFP. + + >>> + >>> V. NTIA Requirements + >>> + >>> Additionally, NTIA has established that the transition proposal + >>> must meet the following five requirements: + >>> + >>> "Support and enhance the multistakeholder model;" + >>> + + IETF Response: + + Because the IETF is open to everyone, participation is open to all + stakeholders. IETF processes outlined in Section I were used to + develop this proposal. Those same processes have been and shall be + used to amend governance of the protocol parameters function. As + mentioned previously, anyone may propose amendments to those + processes, and anyone may take part in the decision process. + + >>> + >>> "Maintain the security, stability, and resiliency of the + >>> Internet DNS;" + >>> + + IETF Response: + + No changes are proposed in this document that affect the security, + stability, and resiliency of the DNS. + + >>> + >>> "Meet the needs and expectation of the global customers and + >>> partners of the IANA services;" + >>> + + IETF Response: + + Implementers and their users from around the world make use of the + IETF standards and the associated IANA protocol parameters + registries. The current IANA protocol parameters registries system + + + +Lear & Housley Informational [Page 16] + +RFC 7979 IANA ICG Response August 2016 + + + is meeting the needs of these global customers. This proposal + continues to meet their needs by maintaining the existing processes + that have served them well in the past. + + >>> + + >>> + >>> "Maintain the openness of the Internet." + >>> + + IETF Response: + + This proposal maintains the existing open framework that allows + anyone to participate in the development of IETF standards, including + the IANA protocol parameters registries policies. Further, an + implementer anywhere in the world has full access to the protocol + specification published in the RFC series and the protocol parameters + registries published at iana.org. Those who require assignments in + the IANA protocol registries will continue to have their requests + satisfied, as specified by the existing policies for those + registries. + + >>> + >>> "The proposal must not replace the NTIA role with a + >>> government-led or an inter-governmental organization solution." + >>> + + Policy oversight is performed by the IAB, which is neither a + government-led or an intergovernmental organization. + + >>> + >>> VI. Community Process + >>> + >>> This section should describe the process your community used for + >>> developing this proposal, including: + >>> + >>> o The steps that were taken to develop the proposal and to + >>> determine consensus. + >>> + + IETF Response: + + The IESG established the IANAPLAN working group to develop this + response. Anyone was welcome to join the discussion and participate + in the development of this response. An open mailing list + (ianaplan@ietf.org) has been associated with the working group. In + addition, IETF's IANA practices have been discussed in the broader + community, and all input has been welcome. Normal IETF procedures + + + +Lear & Housley Informational [Page 17] + +RFC 7979 IANA ICG Response August 2016 + + + [RFC2026] [RFC2418] were used to determine rough consensus. The + chairs of the working group reviewed open issues and, after an + internal working group last call, determined that all had been + satisfactorily addressed, and subsequently the IESG did a formal + IETF-wide Last Call followed by a formal review and determined that + the document had rough consensus. + + >>> + >>> Links to announcements, agendas, mailing lists, consultations and + >>> meeting proceedings. + >>> + + IETF Response: + + The following list is not exhaustive, as there have been many open + discussions about this transition within the IETF community in the + past few months. + + Creation of an open mailing list to discuss the transition: + http://mailarchive.ietf.org/arch/msg/ietf-announce/ + Ztd2ed9U04qSxI-k9-Oj80jJLXc + + Announcement of a public session on the transition: + http://mailarchive.ietf.org/arch/msg/ietf-announce/ + M5zVmFFvTbtgVyMB_fjUSW4rJ0c + + Announcement by the IESG of the intent to form a working group: + http://mailarchive.ietf.org/arch/msg/ietf-announce/ + QsvU9qX98G2KqB18jy6UfhwKjXk + + The working group discussion: + http://www.ietf.org/mail-archive/web/ianaplan/current/ + maillist.html + + 2014-10-06 Interim Meeting Agenda, Minutes, and presentations: + http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/ + proceedings.html + + Working group last call: + http://mailarchive.ietf.org/arch/msg/ianaplan/ + EGF9rfJxn5QpQnRXmS2QxYKYR8k + + Agenda from IETF 91 IANAPLAN WG meeting: + http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan + + Minutes of IETF 91 IANAPLAN WG meeting: + http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan + + + + +Lear & Housley Informational [Page 18] + +RFC 7979 IANA ICG Response August 2016 + + + Shepherd write-up: + http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ + shepherdwriteup/ + + IETF last call: + http://mailarchive.ietf.org/arch/msg/ietf-announce/ + i5rx6PfjJCRax3Lu4qZ_38P8wBg + + >>> + >>> An assessment of the level of consensus behind your community's + >>> proposal, including a description of areas of contention or + >>> disagreement. + >>> + + IETF Response: + + This document has attained rough consensus of the IETF Working Group + and of the IETF community as a whole, as judged first by the working + group chairs and then by the sponsoring Area Director, and then by + the IESG in accordance with [RFC2026] during the 18 December 2014 + IESG telechat. The IESG has approved the draft, pending insertion of + this answer in this section and the IAB approval note. The IAB + approved a statement for inclusion in the document on 19 December + 2014. + + Over the course of the development of the document, several + suggestions were raised that did not enjoy sufficient support to be + included. Two general areas of suggestion that generated much + discussion were + + o A suggestion for a stronger statement over what terms the IAOC + should negotiate. + + o A suggestion that "iana.org" and other associated marks be + transferred to the IETF trust. + + At the end of the working group process, although there was not + unanimous support for the results, the working group chairs concluded + that rough consensus existed in the working group. The document + shepherd's summary of the WG consensus for this document can be found + here: + + https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ + shepherdwriteup/ + + During IETF last call, additional people voiced support for the + document. There were several editorial comments that resulted in + changes, as well as some discussion of more substantial comments some + + + +Lear & Housley Informational [Page 19] + +RFC 7979 IANA ICG Response August 2016 + + + of which resulted in text changes. There was some discussion of + comments already discussed earlier in the process, and but no new + objections were raised during the IETF last call. A summary of the + last call comments can be found from here: + + http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html + + New draft versions were prepared that took into account all the + agreed changes from the last call. The final version was then + approved by the IESG. + +3. IANA Considerations + + This memo is a response to a request for proposals. No parameter + allocations or changes are sought. + +4. Security Considerations + + While the agreement, supplements, policies, and procedures around the + IANA function have shown strong resiliency, the IETF will continue to + work with all relevant parties to facilitate improvements while + maintaining availability of the IANA registries. + +5. IAB Note + + The IAB supports the response in this document. + +6. Acknowledgments + + This document describes processes that have been developed by many + members of the community over many years. The initial version of + this document was developed collaboratively through both the IAB IANA + Strategy Program and the IETF IANAPLAN WG. Particular thanks go to + Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John + Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John + Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew + Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf. + +7. References + +7.1. Normative References + + [BCP9info] "Information on "The Internet Standards Process -- + Revision 3"", <http://www.rfc-editor.org/info/rfc2026>. + + [METRICS] IANA, "Performance Standards Metrics Report", + <http://www.iana.org/performance/metrics>. + + + + +Lear & Housley Informational [Page 20] + +RFC 7979 IANA ICG Response August 2016 + + + [MOUSUP] IAOC, "Supplements to RFC 2860 (the Memorandum of + Understanding between the IETF and ICANN)", + <http://iaoc.ietf.org/contracts.html>. + + [NTIA-Announce] + NTIA, "NTIA Announces Intent to Transition Key Internet + Domain Name Functions", March 2014, + <http://www.ntia.doc.gov/press-release/2014/ntia- + announces-intent-transition-key-internet-domain-name- + functions>. + + [NTIA-Contract] + NTIA, "The NTIA Contract with ICANN", + <http://www.ntia.doc.gov/files/ntia/publications/ + sf_26_pg_1-2-final_award_and_sacs.pdf>. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, + <http://www.rfc-editor.org/info/rfc2026>. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, + September 1998, <http://www.rfc-editor.org/info/rfc2418>. + + [RFC2850] Internet Architecture Board and B. Carpenter, Ed., + "Charter of the Internet Architecture Board (IAB)", + BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, + <http://www.rfc-editor.org/info/rfc2850>. + + [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of + Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority", RFC 2860, + DOI 10.17487/RFC2860, June 2000, + <http://www.rfc-editor.org/info/rfc2860>. + + [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast + Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, + <http://www.rfc-editor.org/info/rfc3307>. + + [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, + and Recall Process: Operation of the Nominating and Recall + Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, + <http://www.rfc-editor.org/info/rfc3777>. + + [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", + BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, + <http://www.rfc-editor.org/info/rfc3935>. + + + + +Lear & Housley Informational [Page 21] + +RFC 7979 IANA ICG Response August 2016 + + + [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the + IETF Administrative Support Activity (IASA)", BCP 101, + RFC 4071, DOI 10.17487/RFC4071, April 2005, + <http://www.rfc-editor.org/info/rfc4071>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for + IPv4 Multicast Address Assignments", BCP 51, RFC 5771, + DOI 10.17487/RFC5771, March 2010, + <http://www.rfc-editor.org/info/rfc5771>. + + [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., + Huston, G., Ed., and Internet Architecture Board, + "Defining the Role and Function of IETF Protocol Parameter + Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April + 2011, <http://www.rfc-editor.org/info/rfc6220>. + + [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", + RFC 6761, DOI 10.17487/RFC6761, February 2013, + <http://www.rfc-editor.org/info/rfc6761>. + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, + RFC 6890, DOI 10.17487/RFC6890, April 2013, + <http://www.rfc-editor.org/info/rfc6890>. + + [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", + RFC 7282, DOI 10.17487/RFC7282, June 2014, + <http://www.rfc-editor.org/info/rfc7282>. + +7.2. Informative References + + [I-D.leiba-cotton-iana-5226bis] + Cotton, M., Leiba, B., and D. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", Work in + Progress, draft-leiba-cotton-iana-5226bis-17, July 2016. + + + + + + + + + + + +Lear & Housley Informational [Page 22] + +RFC 7979 IANA ICG Response August 2016 + + + [ICG-Response] + IANA Stewardship Transition Coordination Group, "Proposal + to Transition the Stewardship of the Internet Assigned + Numbers Authority (IANA) Functions from the U.S. Commerce + Department's National Telecommunications and Information + Administration (NTIA) to the Global Multistakeholder + Community", 11 March 2016, + <https://www.icann.org/en/system/files/files/ + iana-stewardship-transition-proposal-10mar16-en.pdf>. + + [ProtoParamEvo14] + IAB Chair, "Subject: Re: [Internetgovtech] Guiding the + Evolution of the IANA Protocol Parameter Registries", + March 2014, <http://mailarchive.ietf.org/arch/msg/ + internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>. + + [RFC-INDEX] + RFC Editor, "RFC Index", + <http://www.rfc-editor.org/rfc/rfc-index.txt>. + + [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines + and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, + October 1996, <http://www.rfc-editor.org/info/rfc2014>. + + [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root + Name Server Operational Requirements", RFC 2870, + DOI 10.17487/RFC2870, June 2000, + <http://www.rfc-editor.org/info/rfc2870>. + + [RFC3172] Huston, G., Ed., "Management Guidelines & Operational + Requirements for the Address and Routing Parameter Area + Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, + September 2001, <http://www.rfc-editor.org/info/rfc3172>. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + <http://www.rfc-editor.org/info/rfc4193>. + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + <http://www.rfc-editor.org/info/rfc6793>. + + [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. + St.Amour, "Affirmation of the Modern Paradigm for + Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013, + <http://www.rfc-editor.org/info/rfc6852>. + + + + +Lear & Housley Informational [Page 23] + +RFC 7979 IANA ICG Response August 2016 + + + [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The + Internet Numbers Registry System", RFC 7020, + DOI 10.17487/RFC7020, August 2013, + <http://www.rfc-editor.org/info/rfc7020>. + + [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, + DOI 10.17487/RFC7249, May 2014, + <http://www.rfc-editor.org/info/rfc7249>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lear & Housley Informational [Page 24] + +RFC 7979 IANA ICG Response August 2016 + + +Appendix A. The Charter of the IANA Stewardship Coordination Group + (ICG) + + Charter for the IANA Stewardship Transition Coordination Group V.10 + + (August 27, 2014) + + The IANA stewardship transition coordination group (ICG) has one + deliverable: a proposal to the U.S. Commerce Department National + Telecommunications and Information Administration (NTIA) regarding + the transition of NTIA's stewardship of the IANA functions to the + global multi-stakeholder community. The group will conduct itself + transparently, consult with a broad range of stakeholders, and ensure + that its proposals support the security and stability of the IANA + functions. + + The group's mission is to coordinate the development of a proposal + among the communities affected by the IANA functions. The IANA + functions are divided into three main categories: domain names, + number resources, and other protocol parameters. The domain names + category falls further into the country code and generic domain name + sub-categories. While there is some overlap among all of these + categories, each poses distinct organizational, operational and + technical issues, and each tends to have distinct communities of + interest and expertise. For those reasons it is best to have work on + the three categories of IANA parameters proceed autonomously in + parallel and be based in the respective communities. + + The IANA stewardship transition process is taking place alongside a + parallel and related process on enhancing ICANN accountability. + While maintaining the accountability of Internet identifier + governance is central to both processes, this group's scope is + focused on the arrangements required for the continuance of IANA + functions in an accountable and widely accepted manner after the + expiry of the NTIA-ICANN contract. Nevertheless, the two processes + are interrelated and interdependent and should appropriately + coordinate their work. + + The coordination group has four main tasks: + (i) Act as liaison to all interested parties, including the three + "operational communities" (i.e., those with direct operational + or service relationship with IANA; namely names, numbers, + protocol parameters). This task consists of: + a. Soliciting proposals from the operational communities + b. Soliciting the input of the broad group of communities + affected by the IANA functions + (ii) Assess the outputs of the three operational communities for + compatibility and interoperability + + + +Lear & Housley Informational [Page 25] + +RFC 7979 IANA ICG Response August 2016 + + + (iii) Assemble a complete proposal for the transition + (iv) Information sharing and public communication + Describing each in more detail: + (i) Liaison + a. Solicit proposals + + The ICG expects a plan from the country code and generic name + communities (possibly a joint one), a plan from the numbers + community, and a plan from the protocol parameters community. + Members of the ICG will ensure that the communities from which they + are drawn are working on their part of the transition plans. This + involves informing them of requirements and schedules, tracking + progress, and highlighting the results or remaining issues. The role + of a coordination group member during this phase is to provide status + updates about the progress of his or her community in developing + their component, and to coordinate which community will develop a + transition proposal for each area of overlap (e.g., special-use + registry). + + While working on the development of their proposals, the operational + communities are expected to address common requirements and issues + relating to the transition, in as far as they affect their parts of + the stewardship of IANA functions. + + b. Solicit broader input + + The ICG is open for input and feedback from all interested parties. + While no set of formal requirements related to a transition proposal + will be requested outside the operational communities, everyone's + input is welcome across all topics. + + The ICG expects that all interested parties get involved as early as + possible in the relevant community processes. Input received + directly by the ICG may be referred to the relevant community + discussion. + + The ICG members chosen from a particular community are the official + communication channel between the ICG and that community. + + (ii) Assessment + + When the group receives output from the communities it will discuss + and assess their compatibility and interoperability with the + proposals of the other communities. Each proposal should be + submitted with a clear record of how consensus has been reached for + the proposal in the community, and provide an analysis that shows the + + + + + +Lear & Housley Informational [Page 26] + +RFC 7979 IANA ICG Response August 2016 + + + proposal is in practice workable. The ICG should also compile the + input it has received beyond the operational communities, and review + the impacts of this input. + + The ICG might at some point detect problems with the component + proposals. At that point the role of the ICG is to communicate that + back to the relevant communities so that they (the relevant + communities) can address the issues. It is not in the role of the + ICG to develop proposals or to select from among competing proposals. + + (iii) Assembling and submitting a complete proposal + + The assembly effort involves taking the proposals for the different + components and verifying that the whole fulfills the intended scope, + meets the intended criteria, that there are no missing parts, and + that the whole fits together. The whole also needs to include + sufficient independent accountability mechanisms for running the IANA + function. The ICG will then develop a draft final proposal that + achieves rough consensus within the ICG itself. The ICG will then + put this proposal up for public comment involving a reasonable period + of time for reviewing the draft proposal, analyzing and preparing + supportive or critical comments. The ICG will then review these + comments and determine whether modifications are required. If no + modifications are needed, and the coordination group agrees, the + proposal will be submitted to NTIA. + + If changes are required to fix problems or to achieve broader + support, the ICG will work with the operational communities in a + manner similar to what was described in task (ii) above. Updates are + subject to the same verification, review, and consensus processes as + the initial proposals. If, in the ICG's opinion, broad public + support for the proposal as articulated by the NTIA is not present, + the parts of the proposal that are not supported return to the + liaison phase. + + (iv) Information sharing + + The ICG serves as a central clearinghouse for public information + about the IANA stewardship transition process. Its secretariat + maintains an independent, publicly accessible and open website, under + its own domain, where status updates, meetings and notices are + announced, proposals are stored, the ICG members are listed, etc. As + the development of the transition plans will take some time, it is + important that information about ongoing work is distributed early + and continuously. This will enable sharing of ideas and the + detection of potential issues. + + + + + +Lear & Housley Informational [Page 27] + +RFC 7979 IANA ICG Response August 2016 + + +Appendix B. IANA Stewardship Transition Coordination Group Request for + Proposals + + IANA Stewardship Transition Coordination Group Request for Proposals + + 8 September 2014 + + Introduction + + Under the IANA Stewardship Transition Coordination Group (ICG) + Charter, the ICG has four main tasks: + + (i) Act as liaison to all interested parties in the IANA + stewardship transition, including the three "operational + communities" (i.e., those with direct operational or service + relationships with the IANA functions operator; namely names, + numbers, protocol parameters). This task consists of: + + a. Soliciting proposals from the operational communities + b. Soliciting the input of the broad group of communities + affected by the IANA functions + + (ii) Assess the outputs of the three operational communities for + compatibility and interoperability + + (iii) Assemble a complete proposal for the transition + + (iv) Information sharing and public communication + + This Request for Proposals (RFP) addresses task (i) of the ICG + Charter. This RFP does not preclude any form of input from the + non-operational communities. + + 0. Complete Formal Responses + + The IANA Stewardship Transition Coordination Group (ICG) seeks + complete formal responses to this RFP through processes which are to + be convened by each of the "operational communities" of IANA (i.e., + those with direct operational or service relationships with the IANA + functions operator, in connection with names, numbers, or protocol + parameters). + + Proposals should be supported by the broad range of stakeholders + participating in the proposal development process. Proposals should + be developed through a transparent process that is open to and + inclusive of all stakeholders interested in participating in the + development of the proposal. In order to help the ICG maintain its + light coordination role, all interested and affected parties are + + + +Lear & Housley Informational [Page 28] + +RFC 7979 IANA ICG Response August 2016 + + + strongly encouraged to participate directly in these community + processes. + + The following link provides information about ongoing community + processes and how to participate in them, and that will continue to + be updated over time: + + https://www.icann.org/en/stewardship/community + + In this RFP, "IANA" refers to the functions currently specified in + the agreement between NTIA and ICANN + [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well + as any other functions traditionally performed by the IANA functions + operator. SAC-067 + + [https://www.icann.org/en/system/files/files/sac-067-en.pdf] + provides one description of the many different meanings of the term + "IANA" and may be useful reading in addition to the documents + constituting the agreement itself. + + Communities are asked to adhere to open and inclusive processes in + developing their responses, so that all community members may fully + participate in and observe those processes. Communities are also + asked to actively seek out and encourage wider participation by any + other parties with interest in their response. + + A major challenge of the ICG will be to identify and help to + reconcile differences between submitted proposals, in order to + produce a single plan for the transition of IANA + stewardship. Submitted Proposals should therefore focus on those + elements that are considered to be truly essential to the transition + of their specific IANA functions. The target deadline for all + complete formal responses to this RFP is 15 January 2015. + + I. Comments + + While the ICG is requesting complete formal proposals through + processes convened by each of the operational communities, and that + all interested parties get involved as early as possible in the + relevant community processes, some parties may choose to provide + comments directly to the ICG about specific aspects of particular + proposals, about the community processes, or about the ICG's own + processes. Comments may be directly submitted to the ICG any time + via email to icg-forum@icann.org. Comments will be publicly archived + at <http://forum.icann.org/lists/icg-forum/>. + + + + + + +Lear & Housley Informational [Page 29] + +RFC 7979 IANA ICG Response August 2016 + + + Commenters should be aware that ICG will direct comments received to + the relevant operational communities if appropriate. The ICG will + review comments received as time and resources permit and in + accordance with the overall timeline for the transition. That is, + comments received about specific proposals may not be reviewed until + those proposals have been submitted to the ICG. The ICG may + establish defined public comment periods about specific topics in + the future, after the complete formal responses to the RFP have been + received. + + Required Proposal Elements + + The ICG encourages each community to submit a single proposal that + contains the elements described in this section. + + Communities are requested to describe the elements delineated in the + sections below in as much detail possible, and according to the + suggested format/structure, to allow the ICG to more easily + assimilate the results. While each question is narrowly defined to + allow for comparison between answers, respondents are encouraged to + provide further information in explanatory sections, including + descriptive summaries of policies/practices and associated + references to source documents of specific policies/practices. In + this way, the responses to the questionnaire will be useful at the + operational level as well as to the broader stakeholder communities. + + In the interest of completeness and consistency, proposals should + cross-reference wherever appropriate the current IANA Functions + Contract[3] when describing existing arrangements and proposing + changes to existing arrangements. + + 0. Proposal type + + Identify which category of the IANA functions this submission + proposes to address: + [ ] Names [ ] Numbers [ ] Protocol Parameters + + I. Description of Community's Use of IANA Functions + + This section should list the specific, distinct IANA functions your + community relies on. For each IANA function on which your community + relies, please provide the following: + + o A description of the function; + o A description of the customer(s) of the function; + o What registries are involved in providing the function; + + + + + +Lear & Housley Informational [Page 30] + +RFC 7979 IANA ICG Response August 2016 + + + o A description of any overlaps or interdependencies between your + IANA requirements and the functions required by other customer + communities. + + If your community relies on any other IANA service or activity + beyond the scope of the IANA functions contract, you may describe + them here. In this case please also describe how the service or + activity should be addressed by the transition plan. + + II. Existing, Pre-Transition Arrangements + + This section should describe how existing IANA-related arrangements + work, prior to the transition. + + + [3] http://www.ntia.doc.gov/files/ntia/ + publications/sf_26_pg_1-2-final_award_and_sacs.pdf + + A. Policy Sources + + This section should identify the specific source(s) of policy which + must be followed by the IANA functions operator in its conduct of + the services or activities described above. If there are distinct + sources of policy or policy development for different IANA + functions, then please describe these separately. For each source of + policy or policy development, please provide the following: + + o Which IANA function (identified in Section I) are affected. + o A description of how policy is developed and established and who + is involved in policy development and establishment. + o A description of how disputes about policy are resolved. + o References to documentation of policy development and dispute + resolution processes. + + B. Oversight and Accountability + + This section should describe all the ways in which oversight is + conducted over the IANA functions operator's provision of the + services and activities listed in Section I and all the ways in + which the IANA functions operator is currently held accountable for + the provision of those services. For each oversight or + accountability mechanism, please provide as many of the following as + are applicable: + + Which IANA functions (identified in Section I) are affected. If the + policy sources identified in Section II.A are affected, identify + which ones are affected and explain in what way. + + + + +Lear & Housley Informational [Page 31] + +RFC 7979 IANA ICG Response August 2016 + + + o A description of the entity or entities that provide oversight or + perform accountability functions, including how individuals are + selected or removed from participation in those entities. + o A description of the mechanism (e.g., contract, reporting scheme, + auditing scheme, etc.). This should include a description of the + consequences of the IANA functions operator not meeting the + standards established by the mechanism, the extent to which the + output of the mechanism is transparent and the terms under which + the mechanism may change. + o Jurisdiction(s) in which the mechanism applies and the legal basis + on which the mechanism rests. + + III. Proposed Post-Transition Oversight and Accountability + Arrangements + + This section should describe what changes your community is + proposing to the arrangements listed in Section II.B in light of the + transition. If your community is proposing to replace one or more + existing arrangements with new arrangements, that replacement should + be explained and all of the elements listed in Section II.B should + be described for the new arrangements. Your community should provide + its rationale and justification for the new arrangements. + + If your community's proposal carries any implications for the + interface between the IANA functions and existing policy arrangements + described in Section II.A, those implications should be described + here. + + If your community is not proposing changes to arrangements listed in + Section II.B, the rationale and justification for that choice should + be provided here. + + IV. Transition Implications + + This section should describe what your community views as the + implications of the changes it proposed in Section III. These + implications may include some or all of the following, or other + implications specific to your community: + + Description of operational requirements to achieve continuity of + service and possible new service integration throughout the + transition. + + Risks to operational continuity and how they will be addressed. + Description of any legal framework requirements in the absence of the + NTIA contract. Description of how you have tested or evaluated the + workability of any new technical or operational methods proposed in + this document and how they compare to established arrangements. + + + +Lear & Housley Informational [Page 32] + +RFC 7979 IANA ICG Response August 2016 + + + Description of how long the proposals in Section III are expected to + take to complete, and any intermediate milestones that may occur + before they are completed. + + V. NTIA Requirements + + Additionally, NTIA has established that the transition proposal must + meet the following five requirements: + o Support and enhance the multistakeholder model; + o Maintain the security, stability, and resiliency of the Internet + DNS; + o Meet the needs and expectation of the global customers and + partners of the IANA functions; + o Maintain the openness of the Internet; + o The proposal must not replace the NTIA role with a government-led + or an inter-governmental organization solution. + + This section should explain how your community's proposal meets these + requirements and how it responds to the global interest in the IANA + functions. + + VI. Community Process + + This section should describe the process your community used for + developing this proposal, including: + o The steps that were taken to develop the proposal and to determine + consensus. + o Links to announcements, agendas, mailing lists, consultations and + meeting proceedings. + o An assessment of the level of consensus behind your community's + proposal, including a description of areas of contention or + disagreement. + + + + + + + + + + + + + + + + + + + +Lear & Housley Informational [Page 33] + +RFC 7979 IANA ICG Response August 2016 + + +Appendix C. Correspondence of the IETF to the ICG + + The following messages were sent to the ICG: + + + From: Jari Arkko <jari.arkko@piuha.net> + Subject: Re: [Internal-cg] Question from the ICG + Date: 20 Feb 2015 23:46:20 GMT+2 + To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org> + Cc: Izumi Okutani <izumi@nic.ad.jp> + + Dear Alissa and the ICG, + + We refer to the question that the ICG asked the IETF community + on 9 Feb 2015 + + http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html + + > The numbers proposal sees these changes as a requirement of the + > transition and the protocols parameters proposal does not. If + > these aspects of the proposals are perceived as incompatible would + > the numbers and protocol parameters communities be willing to + > modify their proposals to reconcile them? + + We do not observe incompatibilities between the proposals from the + numbers and protocol parameters communities. The numbers + community expresses a preference to transfer the trademark and + domain, while the IETF proposal does not oppose such transfer. + This is not an incompatibility, it is something that can be + satisfied by implementation of both number and protocol + parameters community's proposals, as already specified. + + To confirm this, and to determine whether the transfer + of the trademark and domain would be acceptable, + we consulted the community. It is the opinion of the + IANAPLAN working group that they would support a + decision by the IETF Trust to hold the trademark and domain + on behalf of the Internet community. For details, see + http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html + + The IETF Trust also looked at this issue. The trustees decided that + the IETF Trust would be willing to hold intellectual property rights + relating to the IANA function, including the IANA trademark and the + IANA.ORG domain name. For details, see + http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html + + In short, we find no incompatibility between the proposals and no + need to modify the protocol parameters proposal. + + + +Lear & Housley Informational [Page 34] + +RFC 7979 IANA ICG Response August 2016 + + + Best Regards, + Jari Arkko and Russ Housley on behalf of the IETF community and + the IETF Trust + + From: Jari Arkko <jari.arkko@piuha.net> + Subject: [Internal-cg] IETF response to the time frame inquiry + Date: 5 Jun 2015 13:39:50 GMT+3 + To: Alissa Cooper <alissa@cooperw.in> + Cc: ICG <internal-cg@ianacg.org> + + This is a response to a query regarding transition finalisation and + implementation time frames, sent to the IANAPLAN working + group list by the chairs of the IANA Transition Coordination + Group (ICG) on May 27th. + + While I am carrying this response back to the ICG, the substance + of this response has been discussed in the IANAPLAN working + group and the relevant parts of IETF leadership. I believe this + response represents the (rough) consensus opinion that + emerged in the discussion, as well as the current state + of IANA arrangement updates that our leadership bodies + have been working on. + + The IETF is ready today to take the next steps in the + implementation of the transition of the stewardship. + In our case, most of the necessary framework is already + in place and implemented in preceding years. + + The remaining step is an updated agreement with + ICANN which addresses two issues. These issues are + outlined in Section 2.III in the Internet Draft + draft-ietf-ianaplan-icg-response-09.txt: + + o The protocol parameters registries are in the public domain. It + is the preference of the IETF community that all relevant parties + acknowledge that fact as part of the transition. + + o It is possible in the future that the operation of the protocol + parameters registries may be transitioned from ICANN to subsequent + operator(s). It is the preference of the IETF community that, as + part of the NTIA transition, ICANN acknowledge that it will carry + out the obligations established under C.7.3 and I.61 of the + current IANA functions contract between ICANN and the NTIA + [NTIA-Contract] to achieve a smooth transition to subsequent + operator(s), should the need arise. Furthermore, in the event of + a transition it is the expectation of the IETF community that + + + + + +Lear & Housley Informational [Page 35] + +RFC 7979 IANA ICG Response August 2016 + + + ICANN, the IETF, and subsequent operator(s) will work together to + minimize disruption in the use of the protocol parameters registries + or other resources currently located at iana.org. + + The IETF Administrative Oversight Committee (IAOC) has + decided to use an update of our yearly IETF-ICANN Service Level + Agreement (SLA) as the mechanism for this updated + agreement. They have drafted the update and from our + perspective it could be immediately executed. Once the updated + agreement is in place, the transition would be substantially + complete, with only the NTIA contract lapse or termination + as a final step. + + Of course, we are not alone in this process. Interactions + with other parts of the process may bring additional + tasks that need to be executed either before or + after the transition. First, the ICG, the RIRs, + and IETF have discussed the possibility of aligning + the treatment of IANA trademarks and domains. The + IETF Trust has signalled that it would be willing to do this, + if asked. We are awaiting coordination on this + to complete, but see no problem in speedy + execution once the decision is made. From our + perspective this is not a prerequisite for the transition, + however. + + In addition, the names community has proposed the + creation of a 'Post Transition IANA' (PTI). If the existing + agreements between the IETF and ICANN remain in place + and the SLAs discussed above are not affected, the IETF + transition would take place as described above. That is + our preference. If the final details of the PTI plan require + further action from the IETF, more work and community + agreement would be required. The timeline for that work + cannot be set until the scope is known. + + Jari Arkko, IETF Chair + (reporting his summary of the situation) + + From: Jari Arkko <jari.arkko@piuha.net> + Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the + ICG question on coordination + Date: 8 Oct 2015 10:13:07 GMT+3 + To: IANA etc etc Coordination Group <internal-cg@ianacg.org> + + + The IANAPLAN working group has discussed the coordination + question from the ICG. In the working group's opinion, + + + +Lear & Housley Informational [Page 36] + +RFC 7979 IANA ICG Response August 2016 + + + informal coordination exists today and will continue, which + is consistent with the commitment requested by the ICG. + + This is also consistent with an overall coordination commitment + already indicated in the IANAPLAN proposal. The proposal + is a consensus document of the IETF. From the proposal: + + The IETF will continue to coordinate with ICANN, the RIRs, and other + parties that are mutually invested in the continued smooth operation + of the Internet registries. + + The coordination approach is also consistent with the + comments that were sent by the IAB to the ICG during the + public comment period. See + https://www.iab.org/documents/correspondence-reports-documents/2015- + 2/iab-comments-on-icg-proposal/. + + Jari Arkko, + IETF Chair and the Area Director for the IANAPLAN WG + +Authors' Addresses + + Eliot Lear (editor) + Richtistrasse 7 + Wallisellen, ZH CH-8304 + Switzerland + + Phone: +41 44 878 9200 + Email: lear@cisco.com + + + Russ Housley (editor) + 918 Spring Knoll Drive + Herndon, VA 20170 + United States of America + + Email: housley@vigilsec.com + + + + + + + + + + + + + + +Lear & Housley Informational [Page 37] + |