RFC 7979
Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
Pages: 37
Informational
Informational
Part 1 of 2 – Pages 1 to 20
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 RegistriesAbstract
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.
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
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.
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.
>>> >>> 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.
>>>
>>> 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
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.
>>> 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
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. >>>
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
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
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
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.
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
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.
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
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
[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
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
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.
(page 20 continued on part 2)