| IANAPLAN | E. Lear, Ed. |
| Internet-Draft | |
| Intended status: Informational | R. Housley, Ed. |
| Expires: April 11, 2015 | |
| October 8, 2014 |
Draft Response to the Internet Coordination Group Request for Proposals on IANA
draft-ietf-ianaplan-icg-response-00
This document contains the a draft response to a request for proposals from the IANA Stewardship Transition Coordination Group regarding the protocol parameters registries. It is meant to be included in an aggregate proposal that also includes contributions covering names and addresses that will be submitted from their respective operational communities. The IETF community is invited to comment and propose changes to this document.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2015.
Copyright (c) 2014 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.
In March of 2014 the U.S. National Telecommunications & Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions. 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. They solicited proposals regarding the respective functions that IANA performs, in order that they may put forth a proposal to the NTIA.
While there are interactions between all of the IANA functions and IETF standards, this document specifically addresses the protocol 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. Because much of this memo is taken from a questionnaire we have quoted questions with ">>> " and we have prefaced answers to questions being asked with "IETF Response:". Note that there are small changes to the content of the questions asked in order to match the RFC format.
As if to demonstrate the last point, the following text was included in a footnote in the original propsoal.
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.
Introduction
NOTE: This section is taken in its entirety from the questionnaire dated 8 September 2014.
Under the IANA Stewardship Transition Coordination Group (ICG) Charter [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 from 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 are expected to enjoy a broad consensus of support from all interested parties. During the development of their proposals, the operational communities are requested to consult and work with other affected parties. Likewise, in order to help the ICG maintain its light coordination role, all other affected parties are strongly encouraged to participate in 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
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 from the operational communities only, 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/>.
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[NTIA-Contract] 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:
>>>
IETF Response:
[XXX] 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 IETF's 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 registry containing the parameter values and a pointer to documentation of the associated semantic intent. The IETF uses the IANA protocol parameter registries to implement such registries.
>>> >>> A description of the customer(s) of the service or activity. >>>
IETF Response:
The customer of the IANA protocol parameters function is the Internet Engineering Task Force (IETF).
The IETF is a global voluntary standards organization whose goal is to make the Internet work better [RFC3595]. 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 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, and those amendments are indicated in [RFC-INDEX]. 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 IANA. 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 parameter registries are the product of IETF work. Administration of the protocol parameter registries is the service that is provide to the IETF.
>>> >>> A description of any overlaps or interdependencies between your >>> IANA requirements and the functions required by other customer >>> communities >>>
IETF Response:
It is important to note that the IETF includes anyone who wishes to participate, including anyone from ICANN or the regional Internet registries (RIRs), and many people from those organizations regularly do.
>>> III. 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 registry.
>>> >>> 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 registries is stated in RFCs 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, the Internet Engineering Steering Group may choose to create a working group or an Area Director may choose to sponsor the draft. In either 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.
>>> >>> 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 an 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]. Please also see the references at the bottom of this document.
>>> >>> 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 accountab le 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 have been specified in II.A.
>>> >>> 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 on behalf of the IETF. The IAB is also responsible for establishing liaison relationships with other orgnaizations 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]. This process provides for selection of active members of the community who themselves agree upon a slate of candidates. Those candidates are sent to the Internet Society Board of Trustees for confirmation. In general, members serve for two years. The IAB selects its own chair.
The IAB provides oversight of the protocol parameter 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, many registries are 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 staff for the IETF and the Internet Research Task Force (IRTF), a peer organization to the IETF that focuses on research. 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. IAOC members are appointed by the Internet Society Board of Trustees, the IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN to establish annual IANA performance metrics and operational procedures, and the resulting document is adopted as an supplement to the MoU each year [MOUSUP].
To date there have been no unresolvable disputes or issues. 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.
>>> >>> Jurisdiction(s) in which the mechanism applies and the legal >>> basis on which the mechanism rests. >>>
IETF Response
Because of the nature of the agreement, questions of jurisdiction are immaterial.
>>>IV. Proposed changes to IANA Activities/Services
>>> >>> 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 changes are required, as 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 covers what is needed.
First and foremost, IANA protocol parameter registry updates will continue to function day-to-day, as they have been doing for the last decade or more. The IETF community is quite 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.
Discussions during IETF 89 in London 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 parameter registry 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 parameter registry function needs 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 parameter registry 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 parameter 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 parameter registry function should respect existing Internet community agreements.
The protocol parameter registry 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 parameter registry 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 parameter 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. 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 issuees 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.
>>> >>> 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:
Everyone is welcome to participate in IETF activities. The policies and procedures are outlined in the documents we named above. In-person attendance is not required for participation, and many people participate in email discussions that have never attended an IETF meeting. An email account is the only requirement to participate. The IETF makes use of both formal and informal lines of communication to collaborate with other organizations within the multistakeholder ecosystem.
>>> >>> "Maintain the security, stability, and resiliency of the >>> Internet DNS;" >>>
IETF Response:
The DNS relies on some of the IETF protocol parameters registries. As the current IANA functions operator, ICANN performs its task very well, usually exceeding the service level agreement metrics.[METRICS] Security, stability, and resiliency of the Internet DNS is best protected by maintaining the current service in its current form.
>>> >>> "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 parameter registries. The current IANA protocol parameter registry 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 parameter registry policies. Further, an implementer anywhere in the world has full access to the protocol specification published n the RFC series and the protocol parameter registries published at iana.org. Those who require assignments in the IANA protocol registries will continue to be able to do so, as specified by the existing policies for those registries.
{We will have an open discussion, make changes based on that discussion, and then conduct a Last Call to confirm that there is rough consensus for the proposal.}
>>> >>> 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) was associated with the working group. In addition, IETF’s IANA practices have been discussed in the broader community, and all input is welcome.
>>> >>> Links to announcements, agendas, mailing lists, consultations and >>> meeting proceedings. >>>
IETF Response: [xxx to be completed in more detail]
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.
>>> >>> An assessment of the level of consensus behind your community’s >>> proposal, including a description of areas of contention or >>> disagreement. >>>
IETF Response: To be completed as the process progresses.
This memo is a response a request for proposals. No parameter allocations or changes are sought.
While the IANA framework has shown strong resiliency, the IETF will continue to work with all relevant parties to facilitate improvements in our standards.
This document does not define new processes, and so it seems we acknowledge all of the preceding IAB members and members of the community who developed the processes that we describe. 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, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, and Greg Wood.