< draft-lear-iana-icg-response-00.txt   draft-lear-iana-icg-response-01.txt >
Network Working Group E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational August 30, 2014 Intended status: Informational September 12, 2014
Expires: March 03, 2015 Expires: March 16, 2015
Draft Response to the Internet Coordination Group Request for Proposals Draft Response to the Internet Coordination Group Request for Proposals
on IANA on IANA
draft-lear-iana-icg-response-00 draft-lear-iana-icg-response-01
Abstract Abstract
This document contains the a draft response to a request for This document contains the a draft response to a request for
proposals from the IANA Stewardship Transition Coordination Group proposals from the IANA Stewardship Transition Coordination Group
regarding the protocol parameters registries. It is meant to be regarding the protocol parameters registries. It is meant to be
included in an aggregate proposal that also includes contributions included in an aggregate proposal that also includes contributions
covering names and addresses that will be submitted from their covering names and addresses that will be submitted from their
respective operational communities. The IETF community is invited to respective operational communities. The IETF community is invited to
comment and propose changes to this document. comment and propose changes to this document.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 03, 2015. This Internet-Draft will expire on March 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 2 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Informative References . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. IETF Introduction 1. IETF Introduction
In March of 2014 the U.S. National Telecommunications & Information In March of 2014 the U.S. National Telecommunications & Information
Administration (NTIA) announced its intent to transition oversight of Administration (NTIA) announced its intent to transition oversight of
IANA functions. In that announcement, NTIA asked the Internet Internet Assigned Numbers Authority (IANA) functions. In that
Corporation for Assigned Names and Numbers (ICANN) to establish a announcement, NTIA asked the Internet Corporation for Assigned Names
process to deliver a proposal for transition. As part of that and Numbers (ICANN) to establish a process to deliver a proposal for
process, the IANA Stewardship Transition Coordination Group (ICG) was transition. As part of that process, the IANA Stewardship Transition
formed. They solicited proposals regarding the respective functions Coordination Group (ICG) was formed. They solicited proposals
that IANA performs, in order that they may put forth a proposal to regarding the respective functions that IANA performs, in order that
the NTIA. they may put forth a proposal to the NTIA.
While there are interactions between all of the IANA functions and While there are interactions between all of the IANA functions and
IETF standards, this document specifically addresses the protocol IETF standards, this document specifically addresses the protocol
registries function. Section 1 (this section) contains an registries function. Section 1 (this section) contains an
introduction that is sourced solely within the IETF. Section 2 introduction that is sourced solely within the IETF. Section 2
contains the questionnaire that was written by the ICG and a formal 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 response by the IETF. Because much of this memo is taken from a
questionnaire we mark answers to questions being asked as "IETF questionnaire we have quoted questions with ">>> " and we have
Response:". There are Small changes to the content of the questions 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. 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.
2. The Formal RFP Response 2. The Formal RFP Response
Introduction Introduction
NOTE: This section is taken in its entirety from the questionnaire, NOTE: This section is taken in its entirety from the questionnaire
version 10 (27 August 2014). dated 8 September 2014.
Under the IANA Stewardship Transition Coordination Group (ICG) Under the IANA Stewardship Transition Coordination Group (ICG)
Charter [1], the ICG has four main tasks: Charter [ICG-CHARTER], the ICG has four main tasks:
(i) Act as liaison to all interested parties in the IANA (i) Act as liaison to all interested parties in the IANA
stewardship transition, including the three "operational stewardship transition, including the three "operational
communities" (i.e., those with direct operational or service communities" (i.e., those with direct operational or service
relationships with the IANA functions operator; namely names, relationships with the IANA functions operator; namely names,
numbers, protocol parameters). This task consists of: numbers, protocol parameters). This task consists of:
a. Soliciting proposals from the operational communities a. Soliciting proposals from the operational communities
b. Soliciting the input of the broad group of communities b. Soliciting the input of the broad group of communities
affected by the IANA functions affected by the IANA functions
skipping to change at page 3, line 36 skipping to change at page 4, line 7
Proposals are expected to enjoy a broad consensus of support from all Proposals are expected to enjoy a broad consensus of support from all
interested parties. During the development of their proposals, the interested parties. During the development of their proposals, the
operational communities are requested to consult and work with other operational communities are requested to consult and work with other
affected parties. Likewise, in order to help the ICG maintain its affected parties. Likewise, in order to help the ICG maintain its
light coordination role, all other affected parties are strongly light coordination role, all other affected parties are strongly
encouraged to participate in community processes. encouraged to participate in community processes.
The following link provides information about ongoing community The following link provides information about ongoing community
processes and how to participate in them, and that will continue to processes and how to participate in them, and that will continue to
be updated over time: [XXX LINK] be updated over time:
https://www.icann.org/en/stewardship/community
Communities are asked to adhere to open and inclusive processes in Communities are asked to adhere to open and inclusive processes in
developing their responses, so that all community members may fully developing their responses, so that all community members may fully
participate in and observe those processes. Communities are also participate in and observe those processes. Communities are also
asked to actively seek out and encourage wider participation by any asked to actively seek out and encourage wider participation by any
other parties with interest in their response. other parties with interest in their response.
A major challenge of the ICG will be to identify and help to A major challenge of the ICG will be to identify and help to
reconcile differences between submitted proposals, in order to reconcile differences between submitted proposals, in order to
produce a single plan for the transition of IANA stewardship. produce a single plan for the transition of IANA stewardship.
Submitted Proposals should therefore focus on those elements that are Submitted Proposals should therefore focus on those elements that are
considered to be truly essential to the transition of their specific considered to be truly essential to the transition of their specific
IANA functions. IANA functions.
The target deadline for all complete formal responses to this RFP is The target deadline for all complete formal responses to this RFP is
31 December 2014. 15 January 2015.
I. Comments I. Comments
While the ICG is requesting complete formal proposals from the While the ICG is requesting complete formal proposals from the
operational communities only, and that all interested parties get operational communities only, and that all interested parties get
involved as early as possible in the relevant community processes, involved as early as possible in the relevant community processes,
some parties may choose to provide comments directly to the ICG about some parties may choose to provide comments directly to the ICG about
specific aspects of particular proposals, about the community specific aspects of particular proposals, about the community
processes, or about the ICG's own processes. Comments may be processes, or about the ICG's own processes. Comments may be
directly submitted to the ICG any time via email to icg- directly submitted to the ICG any time via email to icg-
skipping to change at page 4, line 48 skipping to change at page 5, line 18
assimilate the results. While each question is narrowly defined to assimilate the results. While each question is narrowly defined to
allow for comparison between answers, respondents are encouraged to allow for comparison between answers, respondents are encouraged to
provide further information in explanatory sections, including provide further information in explanatory sections, including
descriptive summaries of policies/practices and associated references descriptive summaries of policies/practices and associated references
to source documents of specific policies/practices. In this way, the to source documents of specific policies/practices. In this way, the
responses to the questionnaire will be useful at the operational responses to the questionnaire will be useful at the operational
level as well as to the broader stakeholder communities. level as well as to the broader stakeholder communities.
In the interest of completeness and consistency, proposals should In the interest of completeness and consistency, proposals should
cross-reference wherever appropriate the current IANA Functions cross-reference wherever appropriate the current IANA Functions
Contract [2] when describing existing arrangements and proposing Contract[NTIA-Contract] when describing existing arrangements and
changes to existing arrangements. proposing changes to existing arrangements.
0. Proposal Type >>>
Identify which category of the IANA functions this submission >>> 0. Proposal Type
proposes to address: >>>
>>> Identify which category of the IANA functions this
>>> submission proposes to address:
>>>
IETF Response: IETF Response:
[XXX] Protocol Parameters [XXX] Protocol Parameters
This response states the existing practice of the IETF, and also This response states the existing practice of the IETF, and also
represents the views of the IAB and the IETF. represents the views of the Internet Architecture Board and the IETF.
I. Description of Community's Use of IANA Functions >>>
>>> I. Description of Community's Use of IANA Functions</t>
>>>
>>> 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.
>>>
This section should list the specific, distinct IANA services or IETF Response:
activities your community relies on. For each IANA service or
activity on which your community relies, please provide the
following:
o A description of the customer(s) of the service or activity. Many IETF protocols make use of commonly defined protocol parameters.
[N.B. the IETF response has swapped this question with the next.] 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: IETF Response:
The customer of the IANA protocol parameters function is the Internet The customer of the IANA protocol parameters function is the Internet
Engineering Task Force (IETF). Engineering Task Force (IETF).
The IETF is a global voluntary standards organization whose goal is The IETF is a global voluntary standards organization whose goal is
to make the Internet work better [RFC3595]. IETF standards are to make the Internet work better [RFC3595]. IETF standards are
published in the RFC series. The IETF is responsible for the key published in the RFC series. The IETF is responsible for the key
standards that are used on the Internet today, including IP, TCP, standards that are used on the Internet today, including IP, TCP,
skipping to change at page 5, line 44 skipping to change at page 6, line 35
The IETF operates an open and transparent manner [RFC6852]. The The IETF operates an open and transparent manner [RFC6852]. The
processes that govern the IETF are also published in the RFC series. processes that govern the IETF are also published in the RFC series.
The Internet Standards Process is documented in [RFC2026]. That The Internet Standards Process is documented in [RFC2026]. That
document explains not only how standards are developed, but also how document explains not only how standards are developed, but also how
disputes about decisions are resolved. RFC 2026 has been amended a disputes about decisions are resolved. RFC 2026 has been amended a
number of times, and those amendments are indicated in [RFC-INDEX]. number of times, and those amendments are indicated in [RFC-INDEX].
The standards process can be amended in the same manner that The standards process can be amended in the same manner that
standards are approved. That is, someone proposes a change by standards are approved. That is, someone proposes a change by
submitting a temporary document known as an Internet-Draft, the submitting a temporary document known as an Internet-Draft, the
community discusses it, and if rough consensus can be found the community discusses it, and if rough consensus can be found the
change is approved by the Internet Engineering Steering Community change is approved by the Internet Engineering Steering Group (IESG),
(IESG). Anyone may propose such a change, and anyone may participate who also have day-to-day responsibility for declaring IETF consensus
in the community discussion. on technical decisions, including those that affect IANA. Anyone may
propose a change during a Last Call, and anyone may participate in
o A description of the service or activity. the community discussion.
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, a globally available registry contains the parameter
values and a pointer to documentation of the associated semantic
intent. The IETF uses the IANA protocol parameter registries for
this purpose.
o What registries are involved in providing the service or >>>
activity. >>> What registries are involved in providing the service or
>>> activity.
>>>
IETF Response: IETF Response:
Administration of the protocol registries are themselves the service The protocol parameter registries are the product of IETF work.
that is provided to the IETF community by ICANN. Administration of the protocol parameter registries is the service
that is provide to the IETF.
o A description of any overlaps or interdependencies between your >>>
IANA requirements and the functions required by other customer >>> A description of any overlaps or interdependencies between your
communities >>> IANA requirements and the functions required by other customer
>>> communities
>>>
IETF Response: IETF Response:
It is important to note that the IETF includes anyone who wishes to It is important to note that the IETF includes anyone who wishes to
participate, including anyone from ICANN or the RIRs, and many people participate, including anyone from ICANN or the regional Internet
from those organizations regularly do. registries (RIRs), and many people from those organizations regularly
do.
o The IETF has specified a number of special use registries. These
registries require coordination with the GNSO. We already perform
this coordination.
o The IETF may, from time to time, define and allocate new ranges of o The IETF has specified a number of special use registries with
IP addresses. If one or more registries are required, the IETF regard to domain names. These registries require coordination
will coordinate with appropriate organizations, such as the RIRs with the Generic Names Support Organization (GNSO). We already
or ICANN. perform this coordination.[RFC6761]
o The IETF specifies the DNS protocol. From time to time there are o The IETF specifies the DNS protocol. From time to time there have
changes. We continue to coordinate with ICANN regarding those been and will be updates to that protocol. We will continue to
changes. coordinate with ICANN regarding those changes.
o The IETF specifies minimum requirements for root servers. Should o The IETF specifies minimum requirements for root servers. Should
those requirements change, we will inform ICANN. those requirements change, we will inform ICANN.
o The routing architecture has evolved over time, and is expected to o The routing architecture has evolved over time, and is expected to
continue to do so. Such evolution may have an impact on continue to do so. Such evolution may have an impact on
appropriate IP address allocation strategies. As and when that appropriate IP address allocation strategies. As and when that
happens, we will consult with the RIR community, as we have done happens, we will consult with the RIR community, as we have done
in the past. in the past.
o The IETF has established registries with IANA for special IPv4 and
IPv6 assignments. These are specified in [RFC6890]. The IETF
coordinates such assignments with the RIRs.
o IETF standards changes may have impact on operations of RIRs and o IETF standards changes may have impact on operations of RIRs and
service providers. A recent example is the expansion of the BGP service providers. A recent example is the expansion of the BGP
community field from 16 to 32 bits.[RFC6793] It is important to community field from 16 to 32 bits.[RFC6793] It is important to
note that this change occurred out of operational necessity, and note that this change occurred out of operational necessity, and
it demonstrated strong alignment between the RIRs and the IETF. it demonstrated strong alignment between the RIRs and the IETF.
[[RH2]I think there are two areas of overlap: >>> III. Existing, Pre-Transition Arrangements
>>>
Addresses: special-purpose addresses, such as anycast. We need >>> This section should describe how existing IANA-related
to set up procedures to coordinate assignments. >>> arrangements work, prior to the transition.
>>>
Names: special-purpose names, such as .local. We need to set >>> A. Policy Sources
up procedures to coordinate such assignments. ]] >>>
>>>
III. Existing, Pre-Transition Arrangements >>> This section should identify the specific source(s) of policy
>>> which must be followed by the IANA functions operator in its
This section should describe how existing IANA-related arrangements >>> conduct of the services or activities described above. If there
work, prior to the transition. >>> are distinct sources of policy or policy development for
>>> different IANA activities, then please describe these
A. Policy Sources >>> separately. For each source of policy or policy development,
>>> please provide the following:
This section should identify the specific source(s) of policy which >>>
must be followed by the IANA functions operator in its conduct of the >>> Which IANA service or activity (identified in Section I) is
services or activities described above. If there are distinct >>> affected.
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:
o Which IANA service or activity (identified in Section I) is
affected.
IETF Respponse: The protocol parameters registry. IETF Response: The protocol parameters registry.
o A description of how policy is developed and established and who >>>
is involved in policy development and establishment. >>> A description of how policy is developed and established and
>>> who is involved in policy development and establishment.
>>>
IETF Response: IETF Response:
Policy for overall management of the registries is stated in RFCs in Policy for overall management of the registries is stated in RFCs in
[RFC6220] and [RFC5226]. The first of these documents explains the [RFC6220] and [RFC5226]. The first of these documents explains the
model for how the registries are to be operated, how policy is set, model for how the registries are to be operated, how policy is set,
and how oversight takes place. RFC 5226 specifies the policies that and how oversight takes place. RFC 5226 specifies the policies that
specification writers may employ when they define new protocol specification writers may employ when they define new protocol
registries in the "IANA Considerations" section of each registries in the "IANA Considerations" section of each
specification. All policies at the IETF begin with a proposal in the specification. All policies at the IETF begin with a proposal in the
form of an Internet-Draft. Anyone may submit such a proposal. If form of an Internet-Draft. Anyone may submit such a proposal. If
there is sufficient interest, the Internet Engineering Steering Group there is sufficient interest, the Internet Engineering Steering Group
may choose to create a working group or an Area Director may choose 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 to sponsor the draft. In either case, anyone may comment on the
proposal as it progresses. A proposal cannot be passed by the IESG proposal as it progresses. A proposal cannot be passed by the IESG
unless it enjoys sufficient community support as to indicate rough unless it enjoys sufficient community support as to indicate rough
consensus [RFC7282] Last calls are made so that there is notice of consensus [RFC7282] In each case, a "Last Call" is made so that
any proposed change to a policy or process. there is notice of any proposed change to a policy or process.
Anyone may comment during a Last Call.
o A description of how disputes about policy are resolved. >>>
>>> A description of how disputes about policy are resolved.
>>>
IETF Response: IETF Response:
Most disputes are handled at the lowest level through the working Most disputes are handled at the lowest level through the working
group and rough consensus processes. Should anyone disagree with any group and rough consensus processes. Should anyone disagree with any
action, Section 6.5 of [RFC2026] specifies a multi-level conflict action, Section 6.5 of [RFC2026] specifies a multi-level conflict
resolution and appeals process that includes the responsible Area resolution and appeals process that includes the responsible Area
Director, the IESG, and the IAB. Should appeals be upheld, an Director, the IESG, and the IAB. Should appeals be upheld, an
appropriate remedy is applied. In the case where an someone claims appropriate remedy is applied. In the case where an someone claims
that the procedures themselves are insufficient or inadequate in some that the procedures themselves are insufficient or inadequate in some
way to address a circumstance, one may appeal an IAB decision to the way to address a circumstance, one may appeal an IAB decision to the
Internet Society Board of Trustees. Internet Society Board of Trustees.
o References to documentation of policy development and dispute >>>
resolution processes. >>> References to documentation of policy development and dispute
>>> resolution processes.
>>>
IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
conflict resolution and appeals process. conflict resolution and appeals process. [RFC2418] specifies working
group procedures. Note that both of these documents have been
B. Oversight and Accountability amended in later RFCs as indicated in the [RFC-INDEX]. Please also
This section should describe all the ways in which oversight is see the references at the bottom of this document.
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:
o Which IANA service or activity (identified in Section I) is >>>
affected. >>> 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. IETF Response: the protocol parameters registries.
o If not all policy sources identified in Section II.A are affected, >>>
identify which ones are affected. >>> 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 IETF Response: all policy sources relating to the protocol parameters
registry have been specified in II.A. registry have been specified in II.A.
o A description of the entity or entities that provide oversight or >>>
perform accountability functions, including how individuals are >>> A description of the entity or entities that provide oversight
selected or removed from participation in those entities. >>> or perform accountability functions, including how individuals
>>> are selected or removed from participation in those entities.
>>>
IETF Response: IETF Response:
The Internet Architecture Board (IAB) is an oversight body of the The Internet Architecture Board (IAB) is an oversight body of the
IETF whose responsibilities include, among other things, confirming IETF whose responsibilities include, among other things, confirming
appointment of IESG members, managing appeals as discussed above, appointment of IESG members, managing appeals as discussed above,
management of certain domains, including .ARPA [RFC3172], and general management of certain domains, including .ARPA [RFC3172], and general
architectural guidance to the broader community. The IAB is also architectural guidance to the broader community. The IAB must
responsible for establishing liaison relationships with other approve the appointment of an organization to act as IANA on behalf
orgnaizations on behalf of the IETF. The IAB's charter is to be of the IETF. The IAB is also responsible for establishing liaison
found in [RFC2860]. 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 The IAB members are selected and may be recalled through a Nominating
Committee (NOMCOM) process, which is described in [RFC3777]. This Committee (NOMCOM) process, which is described in [RFC3777]. This
process provides for selection of active members of the community who process provides for selection of active members of the community who
themselves agree upon a slate of candidates. Those candidates are themselves agree upon a slate of candidates. Those candidates are
sent to the ISOC Board of Trustees for confirmation. In general, sent to the Internet Society Board of Trustees for confirmation. In
members serve for two years. The IAB selects its own chair. general, members serve for two years. The IAB selects its own chair.
The IAB provides oversight of the protocol parameter registries of The IAB provides oversight of the protocol parameter registries of
the IETF, and is responsible for selecting appropriate operator(s) the IETF, and is responsible for selecting appropriate operator(s)
and related per-registry arrangements. Especially when relationships and related per-registry arrangements. Especially when relationships
among protocols call for it, many registries are operated by, or in among protocols call for it, many registries are operated by, or in
conjunction with, other bodies. Unless the IAB or IETF has concluded conjunction with, other bodies. Unless the IAB or IETF has concluded
that special treatment is needed, the operator for registries is that special treatment is needed, the operator for registries is
currently ICANN. currently ICANN.
o A description of the mechanism (e.g., contract, reporting scheme, >>>
auditing scheme, etc.). This should include a description of the >>> A description of the mechanism (e.g., contract, reporting
consequences of the IANA functions operator not meeting the >>> scheme, auditing scheme, etc.). This should include a
standards established by the mechanism, the extent to which the >>> description of the consequences of the IANA functions operator
output of the mechanism is transparent and the terms under which >>> not meeting the standards established by the mechanism, the
the mechanism may change. >>> extent to which the output of the mechanism is transparent and
>>> the terms under which the mechanism may change.
>>>
IETF Response: IETF Response:
A memorandum of understanding (MoU) between ICANN and the IETF A memorandum of understanding (MoU) between ICANN and the IETF
community has been in place since 2000. It can be found in community has been in place since 2000. It can be found in
[RFC2860]. It has been amended several times. The MoU defines the [RFC2860]. The MoU defines the work to be carried out by the IANA
work to be carried out by the IANA staff for the IETF and IRTF. 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 Day-to-day administration and contract management is the
responsibility of the IETF Administrative Director (IAD). The IETF responsibility of the IETF Administrative Director (IAD). The IETF
Administrative Oversight Committee (IAOC) oversees the IAD. IAOC Administrative Oversight Committee (IAOC) oversees the IAD. IAOC
members are appointed by the Internet Society Board of Trustees, the members are appointed by the Internet Society Board of Trustees, the
IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN
to establish annual IANA performance metrics and operational to establish annual IANA performance metrics and operational
procedures, and the resulting document is adopted as an addendum to procedures, and the resulting document is adopted as an supplement to
the MoU each year [3]. the MoU each year [MOUSUP].
To date there have been no unresolvable disputes or issues. In the To date there have been no unresolvable disputes or issues. In the
unlikely event that a more difficult situation should arise, the IAOC unlikely event that a more difficult situation should arise, the IAOC
and the IAB would engage ICANN management to address the matter. The and the IAB would engage ICANN management to address the matter. The
MoU also provides an option for either party to terminate the MoU also provides an option for either party to terminate the
arrangement with six months notice. Obviously such action would only arrangement with six months notice. Obviously such action would only
be undertaken after serious consideration. be undertaken after serious consideration.
o Jurisdiction(s) in which the mechanism applies and the legal basis >>>
on which the mechanism rests. >>> Jurisdiction(s) in which the mechanism applies and the legal
>>> basis on which the mechanism rests.
>>>
IETF Response IETF Response
Because of the nature of the agreement, questions of jurisdiction are Because of the nature of the agreement, questions of jurisdiction are
immaterial. immaterial.
IV. Proposed changes to IANA Activities/Services >>>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 >>> This section should describe what changes your community is
be provided here. >>> 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: IETF Response:
No changes are required, as over the years since the creation of No changes are required, as over the years since the creation of
ICANN, the IETF, ICANN, and IAB have together created a system of ICANN, the IETF, ICANN, and IAB have together created a system of
agreements, policies, and oversight mechanisms that covers what is agreements, policies, and oversight mechanisms that covers what is
needed. needed.
First and foremost, IANA protocol parameter registry updates will First and foremost, IANA protocol parameter registry updates will
continue to function day-to-day, as they have been doing for the last continue to function day-to-day, as they have been doing for the last
skipping to change at page 13, line 17 skipping to change at page 14, line 23
The protocol parameters registries are available to everyone, and The protocol parameters registries are available to everyone, and
they are published in a form that allows their contents to be they are published in a form that allows their contents to be
included in other works without further permission. These works included in other works without further permission. These works
include, but are not limited to, implementations of Internet include, but are not limited to, implementations of Internet
protocols and their associated documentation. protocols and their associated documentation.
These principles will guide the IAB, IAOC, and the rest of the IETF These principles will guide the IAB, IAOC, and the rest of the IETF
community as they work with ICANN to establish future IANA community as they work with ICANN to establish future IANA
performance metrics and operational procedures. performance metrics and operational procedures.
Transition Implications >>> IV Transition Implications
This section should describe what your community views as the
implications of the changes it proposed in Section III. These
implications may include some or all of the following, or other
implications specific to your community:
Description of operational requirements to achieve continuity of
service and possible new service integration throughout the
transition.
Risks to operational continuity
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 >>> This section should describe what your community views as the
and how they compare to established arrangements. >>> 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: IETF Response:
No structural changes are required. The principles listed above will No structural changes are required. The principles listed above will
guide IAB, IAOC, and the rest of the IETF community as they work with guide IAB, IAOC, and the rest of the IETF community as they work with
ICANN to establish future IANA performance metrics and operational ICANN to establish future IANA performance metrics and operational
procedures, as they have in the past. procedures, as they have in the past.
As no services are expected to change, no continuity issuees are As no services are expected to change, no continuity issuees are
anticipated, and there are no new technical or operational methods anticipated, and there are no new technical or operational methods
proposed by the IETF to test. The IETF leadership, ICANN, and the proposed by the IETF to test. The IETF leadership, ICANN, and the
RIRs maintain an ongoing informal dialog to spot any unforeseen RIRs maintain an ongoing informal dialog to spot any unforeseen
issues that might arise as a result of other changes. issues that might arise as a result of other changes.
V. NTIA Requirements >>>
Additionally, NTIA has established that the transition proposal must >>> V. NTIA Requirements
meet the following five requirements: >>>
>>> Additionally, NTIA has established that the transition proposal
"Support and enhance the multistakeholder model;" >>> must meet the following five requirements:
>>>
>>> "Support and enhance the multistakeholder model;"
>>>
IETF Response: IETF Response:
Everyone is welcome to participate in IETF activities. The policies Everyone is welcome to participate in IETF activities. The policies
and procedures are outlined in the documents we named above. In- and procedures are outlined in the documents we named above. In-
person attendance is not required for participation, and many people person attendance is not required for participation, and many people
participate in email discussions that have never attended an IETF participate in email discussions that have never attended an IETF
meeting. An email account is the only requirement to participate. meeting. An email account is the only requirement to participate.
The IETF makes use of both formal and informal lines of communication The IETF makes use of both formal and informal lines of communication
to collaborate with other organizations within the multistakeholder to collaborate with other organizations within the multistakeholder
ecosystem. ecosystem.
"Maintain the security, stability, and resiliency of the Internet >>>
DNS;" >>> "Maintain the security, stability, and resiliency of the
>>> Internet DNS;"
>>>
IETF Response: IETF Response:
The DNS relies on some of the IETF protocol parameters registries. The DNS relies on some of the IETF protocol parameters registries.
As the current IANA functions operator, ICANN performs its task very As the current IANA functions operator, ICANN performs its task very
well, usually exceeding the service level agreement metrics.[Metrics] well, usually exceeding the service level agreement metrics.[METRICS]
Security, stability, and resiliency of the Internet DNS is best Security, stability, and resiliency of the Internet DNS is best
protected by maintaining the current service in its current form. 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;" >>> "Meet the needs and expectation of the global customers and
>>> partners of the IANA services;"
>>>
IETF Response: IETF Response:
Implementers and their users from around the world make use of the Implementers and their users from around the world make use of the
IETF standards and the associated IANA protocol parameter registries. IETF standards and the associated IANA protocol parameter registries.
The current IANA protocol parameter registry system is meeting the The current IANA protocol parameter registry system is meeting the
needs of these global customers. This proposal continues to meet needs of these global customers. This proposal continues to meet
their needs by maintaining the existing processes that have served their needs by maintaining the existing processes that have served
them well in the past. them well in the past.
"Maintain the openness of the Internet." >>>
>>>
>>> "Maintain the openness of the Internet."
>>>
IETF Response: IETF Response:
This proposal maintains the existing open framework that allows This proposal maintains the existing open framework that allows
anyone to participate in the development of IETF standards, including anyone to participate in the development of IETF standards, including
the IANA protocol parameter registry policies. Further, an the IANA protocol parameter registry policies. Further, an
implementer anywhere in the world has full access to the protocol implementer anywhere in the world has full access to the protocol
specification published n the RFC series and the protocol parameter specification published n the RFC series and the protocol parameter
registries published at iana.org. Those who require assignments in registries published at iana.org. Those who require assignments in
the IANA protocol registries will continue to be able to do so, as the IANA protocol registries will continue to be able to do so, as
specified by the existing policies for those registries. specified by the existing policies for those registries.
{We will have an open discussion, make changes based on that {We will have an open discussion, make changes based on that
discussion, and then conduct a Last Call to confirm that there is discussion, and then conduct a Last Call to confirm that there is
rough consensus for the proposal.} rough consensus for the proposal.}
VI. Community Process >>>
>>> VI. Community Process
This section should describe the process your community used for >>>
developing this proposal, including: >>> This section should describe the process your community used for
>>> developing this proposal, including:
The steps that were taken to develop the proposal and to determine >>>
consensus. >>> o The steps that were taken to develop the proposal and to
>>> determine consensus.
>>>
IETF Response: IETF Response:
The IESG established the IANAPLAN working group to develop this The IESG established the IANAPLAN working group to develop this
response. Anyone was welcome to join the discussion and participate response. Anyone was welcome to join the discussion and participate
in the development of this response. An open mailing list in the development of this response. An open mailing list
(ianaplan@ietf.org) was associated with the working group. In (ianaplan@ietf.org) was associated with the working group. In
addition, IETF's IANA practices have been discussed in the broader addition, IETF's IANA practices have been discussed in the broader
community, and all input is welcome. community, and all input is welcome.
o Links to announcements, agendas, mailing lists, consultations and >>>
meeting proceedings. >>> Links to announcements, agendas, mailing lists, consultations and
>>> meeting proceedings.
>>>
IETF Response: [xxx to be completed in more detail] IETF Response: [xxx to be completed in more detail]
The following list is not exhaustive, as there have been many open The following list is not exhaustive, as there have been many open
discussions about this transition within the IETF community in the discussions about this transition within the IETF community in the
past few months. past few months.
Creation of an open mailing list to discuss the transition Creation of an open mailing list to discuss the transition: http://w
http://www.ietf.org/mail-archive/web/ietf-announce/current/ ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
msg12978.html
Announcement of a public session on the transition http:// Announcement of a public session on the transition: http://
www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
Announcement by the IESG of the intent to form a working group Announcement by the IESG of the intent to form a working group:
http://www.ietf.org/mail-archive/web/ietf-announce/current/ http://www.ietf.org/mail-archive/web/ietf-announce/current/
msg13170.html msg13170.html
o An assessment of the level of consensus behind your community's >>>
proposal, including a description of areas of contention or >>> An assessment of the level of consensus behind your community's
disagreement. >>> proposal, including a description of areas of contention or
>>> disagreement.
>>>
IETF Response: To be completed as the process progresses. IETF Response: To be completed as the process progresses.
3. Acknowledgments 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 This document does not define new processes, and so it seems we
acknowledge all of the preceding IAB members and members of the acknowledge all of the preceding IAB members and members of the
community who developed the processes that we describe. The initial community who developed the processes that we describe. The initial
version of this document was developed collaboratively through both version of this document was developed collaboratively through both
the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular
thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew
Sullivan, Leslie Daigle, and Barry Leiba. Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, and Greg Wood.
4. Informative References 6. Informative References
[ICG-CHARTER]
, "The IANA Stewardship Transition Coordination Group
(ICG) Charter", , <https://www.icann.org/en/system/files/
files/charter-icg-27aug14-en.pdf>.
[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>.
[RFC-INDEX] [RFC-INDEX]
RFC Editor, , "Index of all Requests for Comments", RFC RFC Editor, , "Index of all Requests for Comments", RFC
Index, August 2014. Index, August 2014.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 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 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850, the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000. May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3172] Huston, G., "Management Guidelines & Operational [RFC3172] Huston, G., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
skipping to change at page 17, line 10 skipping to change at page 19, line 22
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
Internet Architecture Board, "Defining the Role and Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators", Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011. 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 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793, December
2012. 2012.
[RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
Amour, "Affirmation of the Modern Paradigm for Standards", Amour, "Affirmation of the Modern Paradigm for Standards",
RFC 6852, January 2013. 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.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
7282, June 2014. 7282, June 2014.
Authors' Addresses Authors' Addresses
Eliot Lear (editor) Eliot Lear (editor)
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
 End of changes. 63 change blocks. 
203 lines changed or deleted 311 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/