IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed.
Intended status: Informational October 27, 2014
Expires: April 30, 2015
Draft Response to the Internet Coordination Group Request for Proposals
on IANA
draft-ietf-ianaplan-icg-response-02
Abstract
This document contains the a 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 domain
names and numbering resources that will be submitted from their
respective operational communities. The IETF community is invited to
comment and propose changes to this document.
Status of This Memo
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 30, 2015.
Copyright Notice
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
Lear & Housley Expires April 30, 2015 [Page 1]
Internet-Draft IANA ICG Response October 2014
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 . . . . . . . . . . . . . . . . . . . . . . 2
2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 19
A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20
Appendix B. The Charter of the IANA Stewardship Coordination
Group (ICG . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. IETF Introduction
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. The charter for the ICG can be
found in Appendix B. They solicited proposals regarding the
respective functions that IANA performs, in order that they may put
forth a proposal to the NTIA. The final request for proposal (RFP)
can be found in Appendix C.
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. 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.
Lear & Housley Expires April 30, 2015 [Page 2]
Internet-Draft IANA ICG Response October 2014
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 Comments, including introduction, can be found
in Appendix C.
>>>
>>> 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
Lear & Housley Expires April 30, 2015 [Page 3]
Internet-Draft IANA ICG Response October 2014
registries containing the parameter values and a pointer to
documentation of the associated semantic intent. The IETF uses the
IANA protocol parameters registries to store this information in a
public location.
>>>
>>> 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 accordance 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 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 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, 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:
Lear & Housley Expires April 30, 2015 [Page 4]
Internet-Draft IANA ICG Response October 2014
The protocol parameters registries are the product of IETF work.
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 we 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 engages directly with the appropriate organizations
to ensure that each organization's policies are followed.
It is important to note that the IETF includes anyone who wishes to
participate. Staff and participants from ICANN or 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 the Generic Names Support Organization (GNSO). We already
perform this coordination.[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. Should
those requirements change, we will inform ICANN.
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. As and when that
happens, we will consult with the RIR community, as we have done
in the past.
Lear & Housley Expires April 30, 2015 [Page 5]
Internet-Draft IANA ICG Response October 2014
o The IETF is responsible for policy relating to the entire IP
address space and AS number space. Through IANA, the IETF
delegates unicast IP address and AS number ranges to the RIR
system [RFC7020],[RFC7249]. Special address allocation, such a
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
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 IETF standards changes 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.
Lear & Housley Expires April 30, 2015 [Page 6]
Internet-Draft IANA ICG Response October 2014
>>>
>>> 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
[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 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.
>>>
Lear & Housley Expires April 30, 2015 [Page 7]
Internet-Draft IANA ICG Response October 2014
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 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 on behalf
Lear & Housley Expires April 30, 2015 [Page 8]
Internet-Draft IANA ICG Response October 2014
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 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, 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.
Lear & Housley Expires April 30, 2015 [Page 9]
Internet-Draft IANA ICG Response October 2014
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 the
IANA functions operator to establish annual IANA performance metrics
and operational procedures, and the resulting document is adopted as
an supplement to the MoU each year [MOUSUP]. In accordance with
these supplements, an annual review is performed to ensure that
protocol parameter requests are being processed according to the
established policies.
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
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
Lear & Housley Expires April 30, 2015 [Page 10]
Internet-Draft IANA ICG Response October 2014
>>> listed in Section II.B, the rationale and justification for that
>>> choice should be provided here.
>>>
IETF Response:
No major changes are required, however, the IETF community has
expressed a desire for several points to be addressed by supplemental
agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA
regime. 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 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 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.
To address issues raised by the IETF community relating to
intellectual property rights, the IAOC is asked to engage the
appropriate parties, both inside and outside the IETF, to make clear
that data in the protocol parameters registries is in the public
domain.
To address a desire by the IETF community to have mechanisms that
allow for additional dispute resolution between the IETF and the
current IANA protocol registries operator, the IAOC is asked to
conclude a supplemental agreement regarding jurisdiction and any
necessary dispute resolution mechanisms that are mutually acceptable
to the parties.
To address concerns regarding appropriate contingencies to transition
to another operator, the IAOC is asked to conclude a supplemental
agreement that-
1. maintains the IANA functions operator's obligations established
under C.7.3 and I.61 of the current IANA functions contract
between ICANN and the NTIA [NTIA-Contract]; and
2. requires the transfer of any associated marks and identifiers to
subsequent operators.
Lear & Housley Expires April 30, 2015 [Page 11]
Internet-Draft IANA ICG Response October 2014
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 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 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 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.
Lear & Housley Expires April 30, 2015 [Page 12]
Internet-Draft IANA ICG Response October 2014
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:
>>>
Lear & Housley Expires April 30, 2015 [Page 13]
Internet-Draft IANA ICG Response October 2014
>>> 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 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
supplemental agreement(s) discussed in the previous section 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:
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
Lear & Housley Expires April 30, 2015 [Page 14]
Internet-Draft IANA ICG Response October 2014
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 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:
Lear & Housley Expires April 30, 2015 [Page 15]
Internet-Draft IANA ICG Response October 2014
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 be able to do so, as
specified by the existing policies for those registries.
>>>
>>> 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.
Creation of an open mailing list to discuss the transition: http://w
ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
Announcement of a public session on the transition: http://
www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
Announcement by the IESG of the intent to form a working group:
Lear & Housley Expires April 30, 2015 [Page 16]
Internet-Draft IANA ICG Response October 2014
http://www.ietf.org/mail-archive/web/ietf-announce/current/
msg13170.html
>>>
>>> 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.
3. IANA Considerations
This memo is a response a request for proposals. No parameter
allocations or changes are sought.
4. Security Considerations
While the IANA framework has shown strong resiliency, the IETF will
continue to work with all relevant parties to facilitate improvements
in our standards.
5. Acknowledgments
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, Marc Blanchet, Barry Leiba, Brian Carpenter,
Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei
Robachevsky, Miles Fidelman, and Richard Hill.
6. Informative References
[METRICS] , "Performance Standards Metrics Report", ,
<http://www.iana.org/performance/metrics>.
[MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
Understanding between the IETF and ICANN)", ,
<http://iaoc.ietf.org/contracts.html>.
[NTIA-Contract]
, "The NTIA Contract with ICANN", , <http://
www.ntia.doc.gov/files/ntia/publications/
sf_26_pg_1-2-final_award_and_sacs.pdf>.
Lear & Housley Expires April 30, 2015 [Page 17]
Internet-Draft IANA ICG Response October 2014
[RFC-INDEX]
RFC Editor, , "Index of all Requests for Comments", RFC
Index, August 2014.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3172] Huston, G., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, September 2001.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC
3595, September 2003.
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010.
Lear & Housley Expires April 30, 2015 [Page 18]
Internet-Draft IANA ICG Response October 2014
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December
2012.
[RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
Amour, "Affirmation of the Modern Paradigm for Standards",
RFC 6852, January 2013.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013.
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
2014.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
7282, June 2014.
Appendix A. Changes
NOTE: This section to be removed by RFC Editor at publication.
A.1. Changes from -01 to -02
o A better description special registries and BGP ASNs.
o Clarity on how the address space and ASNs are delegated.
o Many editorials corrected.
o Mention of the annual review as part of the SLAs.
o Change about how overlap is presented.
o A number of small wording changes based on feedback.
Lear & Housley Expires April 30, 2015 [Page 19]
Internet-Draft IANA ICG Response October 2014
A.2. Changes from -00 to -01
o Front matter greatly reduced.
o Appendices with charter and RFP added.
o Jurisdiction text changed.
o Proposed changes include supplemental agreement(s) to address
jurisdiction, dispute resolution, and IPR, including names and
marks.
o Transition implications slightly modified to reference
supplemental agreement.
Appendix B. 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
Lear & Housley Expires April 30, 2015 [Page 20]
Internet-Draft IANA ICG Response October 2014
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
(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
Lear & Housley Expires April 30, 2015 [Page 21]
Internet-Draft IANA ICG Response October 2014
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
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.
Lear & Housley Expires April 30, 2015 [Page 22]
Internet-Draft IANA ICG Response October 2014
(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.
Appendix C. IANA Stewardship Transition Coordination Group Request for
Proposals
IANA Stewardship Transition Coordination Group Request for Proposals
8 September 2014
Introduction
Under the IANA1 Stewardship Transition Coordination Group (ICG)
Charter,2 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
Lear & Housley Expires April 30, 2015 [Page 23]
Internet-Draft IANA ICG Response October 2014
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
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
Lear & Housley Expires April 30, 2015 [Page 24]
Internet-Draft IANA ICG Response October 2014
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/>.
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
Lear & Housley Expires April 30, 2015 [Page 25]
Internet-Draft IANA ICG Response October 2014
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;
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
Lear & Housley Expires April 30, 2015 [Page 26]
Internet-Draft IANA ICG Response October 2014
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.
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
Lear & Housley Expires April 30, 2015 [Page 27]
Internet-Draft IANA ICG Response October 2014
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.
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.
Authors' Addresses
Lear & Housley Expires April 30, 2015 [Page 28]
Internet-Draft IANA ICG Response October 2014
Eliot Lear (editor)
Richtistrasse 7
Wallisellen, ZH CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Russ Housley (editor)
918 Spring Noll Drive
Herndon, VA 20170
USA
Email: housley@vigilsec.com
Lear & Housley Expires April 30, 2015 [Page 29]