< draft-ietf-ianaplan-icg-response-00.txt   draft-ietf-ianaplan-icg-response-01.txt >
IANAPLAN E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational October 06, 2014 Intended status: Informational October 16, 2014
Expires: April 09, 2015 Expires: April 19, 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-ietf-ianaplan-icg-response-00 draft-ietf-ianaplan-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 April 09, 2015. This Internet-Draft will expire on April 19, 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 . . . . . . . . . . . . . . . . . . . 3 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. Informative References . . . . . . . . . . . . . . . . . . . 18 6. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Changes since -00 . . . . . . . . . . . . . . . . . 18
Appendix B. The Charter of the IANA Stewardship Coordination
Group (ICG . . . . . . . . . . . . . . . . . . . . . 18
Appendix C. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
Internet Assigned Numbers Authority (IANA) functions. In that Internet Assigned Numbers Authority (IANA) functions. In that
announcement, NTIA asked the Internet Corporation for Assigned Names announcement, NTIA asked the Internet Corporation for Assigned Names
and Numbers (ICANN) to establish a process to deliver a proposal for and Numbers (ICANN) to establish a process to deliver a proposal for
transition. As part of that process, the IANA Stewardship Transition transition. As part of that process, the IANA Stewardship Transition
Coordination Group (ICG) was formed. They solicited proposals Coordination Group (ICG) was formed. The charter for the ICG can be
regarding the respective functions that IANA performs, in order that found in Appendix B. They solicited proposals regarding the
they may put forth a proposal to the NTIA. 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 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 have quoted questions with ">>> " and we have questionnaire we have quoted questions with ">>> " and we have
prefaced answers to questions being asked with "IETF Response:". prefaced answers to questions being asked with "IETF Response:".
Note that there are small changes to the content of the questions Note that there are small changes to the content of the questions
skipping to change at page 3, line 7 skipping to change at page 3, line 16
the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/
iana-functions-purchase-order] as well as any other functions iana-functions-purchase-order] as well as any other functions
traditionally performed by the IANA functions operator. SAC-067 traditionally performed by the IANA functions operator. SAC-067
[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides [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 one description of the many different meanings of the term "IANA" and
may be useful reading in addition to the documents constituting the may be useful reading in addition to the documents constituting the
agreement itself. agreement itself.
2. The Formal RFP Response 2. The Formal RFP Response
Introduction The entire Request for Comments, including introduction, can be found
in Appendix C.
NOTE: This section is taken in its entirety from the questionnaire
dated 8 September 2014.
Under the IANA Stewardship Transition Coordination Group (ICG)
Charter [ICG-CHARTER], the ICG has four main tasks:
(i) Act as liaison to all interested parties in the IANA
stewardship transition, including the three "operational
communities" (i.e., those with direct operational or service
relationships with the IANA functions operator; namely names,
numbers, protocol parameters). This task consists of:
a. Soliciting proposals from the operational communities
b. Soliciting the input of the broad group of communities
affected by the IANA functions
(ii) Assess the outputs of the three operational communities
for compatibility and interoperability
(iii) Assemble a complete proposal for the transition
(iv) Information sharing and public communication
This Request for Proposals (RFP) addresses task (i) of the ICG
Charter. This RFP does not preclude any form of input from the non-
operational communities.
0. Complete Formal Responses
The IANA Stewardship Transition Coordination Group (ICG) seeks
complete formal responses to this RFP from the "operational
communities" of IANA (i.e., those with direct operational or service
relationships with the IANA functions operator, in connection with
names, numbers, or protocol parameters).
Proposals are expected to enjoy a broad consensus of support from all
interested parties. During the development of their proposals, the
operational communities are requested to consult and work with other
affected parties. Likewise, in order to help the ICG maintain its
light coordination role, all other affected parties are strongly
encouraged to participate in community processes.
The following link provides information about ongoing community
processes and how to participate in them, and that will continue to
be updated over time:
https://www.icann.org/en/stewardship/community
Communities are asked to adhere to open and inclusive processes in
developing their responses, so that all community members may fully
participate in and observe those processes. Communities are also
asked to actively seek out and encourage wider participation by any
other parties with interest in their response.
A major challenge of the ICG will be to identify and help to
reconcile differences between submitted proposals, in order to
produce a single plan for the transition of IANA stewardship.
Submitted Proposals should therefore focus on those elements that are
considered to be truly essential to the transition of their specific
IANA functions.
The target deadline for all complete formal responses to this RFP is
15 January 2015.
I. Comments
While the ICG is requesting complete formal proposals from the
operational communities only, and that all interested parties get
involved as early as possible in the relevant community processes,
some parties may choose to provide comments directly to the ICG about
specific aspects of particular proposals, about the community
processes, or about the ICG's own processes. Comments may be
directly submitted to the ICG any time via email to icg-
forum@icann.org. Comments will be publicly archived at <http://
forum.icann.org/lists/icg-forum/>.
Commenters should be aware that ICG will direct comments received to
the relevant operational communities if appropriate. The ICG will
review comments received as time and resources permit and in
accordance with the overall timeline for the transition. That is,
comments received about specific proposals may not be reviewed until
those proposals have been submitted to the ICG. The ICG may
establish defined public comment periods about specific topics in the
future, after the complete formal responses to the RFP have been
received.
Required Proposal Elements
The ICG encourages each community to submit a single proposal that
contains the elements described in this section.
Communities are requested to describe the elements delineated in the
sections below in as much detail possible, and according to the
suggested format/structure, to allow the ICG to more easily
assimilate the results. While each question is narrowly defined to
allow for comparison between answers, respondents are encouraged to
provide further information in explanatory sections, including
descriptive summaries of policies/practices and associated references
to source documents of specific policies/practices. In this way, the
responses to the questionnaire will be useful at the operational
level as well as to the broader stakeholder communities.
In the interest of completeness and consistency, proposals should
cross-reference wherever appropriate the current IANA Functions
Contract[NTIA-Contract] when describing existing arrangements and
proposing changes to existing arrangements.
>>> >>>
>>> 0. Proposal Type >>> 0. Proposal Type
>>> >>>
>>> Identify which category of the IANA functions this >>> Identify which category of the IANA functions this
>>> submission proposes to address: >>> submission proposes to address:
>>> >>>
IETF Response: IETF Response:
[XXX] Protocol Parameters [XXX] Protocol Parameters
skipping to change at page 6, line 16 skipping to change at page 4, line 14
registry containing the parameter values and a pointer to registry containing the parameter values and a pointer to
documentation of the associated semantic intent. The IETF uses the documentation of the associated semantic intent. The IETF uses the
IANA protocol parameter registries to implement such registries. IANA protocol parameter registries to implement such registries.
>>> >>>
>>> A description of the customer(s) of the service or activity. >>> 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 IANA protocol parameter registry operator maintains the protocol
Engineering Task Force (IETF). parameters registry for the IETF in accordance with all relevant IETF
policies, in accordance with the Memorandum of Understanding and
assoicated supplemental agreements that include service level
agreements (SLAs).
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,
DNS, BGP, and HTTP, to name but a few. DNS, BGP, and HTTP, to name but a few.
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
skipping to change at page 7, line 17 skipping to change at page 5, line 17
that is provide to the IETF. that is provide to the IETF.
>>> >>>
>>> A description of any overlaps or interdependencies between your >>> A description of any overlaps or interdependencies between your
>>> IANA requirements and the functions required by other customer >>> IANA requirements and the functions required by other customer
>>> communities >>> communities
>>> >>>
IETF Response: 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. 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 It is important to note that the IETF includes anyone who wishes to
participate, including anyone from ICANN or the regional Internet participate, including anyone from ICANN or the regional Internet
registries (RIRs), and many people from those organizations regularly registries (RIRs), and many people from those organizations regularly
do. do.
o The IETF has specified a number of special use registries with o The IETF has specified a number of special use registries with
regard to domain names. These registries require coordination regard to domain names. These registries require coordination
with the Generic Names Support Organization (GNSO). We already with the Generic Names Support Organization (GNSO). We already
perform this coordination.[RFC6761] perform this coordination.[RFC6761]
skipping to change at page 7, line 50 skipping to change at page 6, line 11
o The IETF has established registries with IANA for special IPv4 and o The IETF has established registries with IANA for special IPv4 and
IPv6 assignments. These are specified in [RFC6890]. The IETF IPv6 assignments. These are specified in [RFC6890]. The IETF
coordinates such assignments with the RIRs. 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.
>>> III. Existing, Pre-Transition Arrangements >>> II. Existing, Pre-Transition Arrangements
>>> >>>
>>> This section should describe how existing IANA-related >>> This section should describe how existing IANA-related
>>> arrangements work, prior to the transition. >>> arrangements work, prior to the transition.
>>> >>>
>>> A. Policy Sources >>> A. Policy Sources
>>> >>>
>>> >>>
>>> This section should identify the specific source(s) of policy >>> This section should identify the specific source(s) of policy
>>> which must be followed by the IANA functions operator in its >>> which must be followed by the IANA functions operator in its
>>> conduct of the services or activities described above. If there >>> conduct of the services or activities described above. If there
skipping to change at page 11, line 40 skipping to change at page 9, line 46
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.
>>> >>>
>>> Jurisdiction(s) in which the mechanism applies and the legal >>> Jurisdiction(s) in which the mechanism applies and the legal
>>> basis on which the mechanism rests. >>> basis on which the mechanism rests.
>>> >>>
IETF Response IETF Response
Because of the nature of the agreement, questions of jurisdiction are This mechanism is global in nature. The current agreement does not
immaterial. specify a jurisdiction.
>>>IV. Proposed changes to IANA Activities/Services
>>>III. Proposed Post-Transition Oversight and Accountability
Arrangements
>>> >>>
>>> This section should describe what changes your community is >>> This section should describe what changes your community is
>>> proposing to the arrangements listed in Section II.B in light of >>> proposing to the arrangements listed in Section II.B in light of
>>> the transition. If your community is proposing to replace one or >>> the transition. If your community is proposing to replace one or
>>> more existing arrangements with new arrangements, that >>> more existing arrangements with new arrangements, that
>>> replacement should be explained and all of the elements listed >>> replacement should be explained and all of the elements listed
>>> in Section II.B should be described for the new >>> in Section II.B should be described for the new
>>> arrangements. Your community should provide its rationale and >>> arrangements. Your community should provide its rationale and
>>> justification for the new arrangements. >>> justification for the new arrangements.
>>> >>>
skipping to change at page 12, line 32 skipping to change at page 10, line 37
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
decade or more. The IETF community is quite satisfied with the decade or more. The IETF community is quite satisfied with the
current arrangement with ICANN. RFC 2860 remains in force and has current arrangement with ICANN. RFC 2860 remains in force and has
served the IETF community very well. RFC 6220 has laid out an served the IETF community very well. RFC 6220 has laid out an
appropriate service description and requirements. 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 some members of 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, IAOC is asked to conclude a supplemental
agreement that-
1. captures provisions 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
a subsequent operator.
Discussions during IETF 89 in London led to the following guiding Discussions during IETF 89 in London led to the following guiding
principles for IAB efforts that impact IANA protocol parameter principles for IAB efforts that impact IANA protocol parameter
registries. These principles must be taken together; their order is registries. These principles must be taken together; their order is
not significant. not significant.
1. The IETF protocol parameter registry function has been and 1. The IETF protocol parameter registry function has been and
continues to be capably provided by the Internet technical community. continues to be capably provided by the Internet technical community.
The strength and stability of the function and its foundation within The strength and stability of the function and its foundation within
the Internet technical community are both important given how the Internet technical community are both important given how
skipping to change at page 15, line 11 skipping to change at page 13, line 38
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.
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 >>> V. NTIA Requirements
>>> >>>
>>> Additionally, NTIA has established that the transition proposal >>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements: >>> must meet the following five requirements:
>>> >>>
>>> "Support and enhance the multistakeholder model;" >>> "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.
skipping to change at page 16, line 24 skipping to change at page 15, line 9
>>> >>>
>>> "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 in 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
skipping to change at page 18, line 6 skipping to change at page 16, line 39
in our standards. in our standards.
5. Acknowledgments 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, Barry Leiba, Brian Carpenter, and Greg Wood. Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, Greg Wood,
John Curran, and Milton Mueller.
6. 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", , [METRICS] , "Performance Standards Metrics Report", ,
<http://www.iana.org/performance/metrics>. <http://www.iana.org/performance/metrics>.
[MOUSUP] , "Supplements to RFC 2860 (the Memorandum of [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
Understanding between the IETF and ICANN)", , Understanding between the IETF and ICANN)", ,
<http://iaoc.ietf.org/contracts.html>. <http://iaoc.ietf.org/contracts.html>.
[NTIA-Contract] [NTIA-Contract]
, "The NTIA Contract with ICANN", , <http:// , "The NTIA Contract with ICANN", , <http://
www.ntia.doc.gov/files/ntia/publications/ www.ntia.doc.gov/files/ntia/publications/
skipping to change at page 19, line 40 skipping to change at page 18, line 20
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, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013. 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.
Appendix A. Changes since -00
NOTE: This section to be removed by RFC Editor at publication.
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
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
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.
(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: &#8232;
a. Soliciting proposals from the operational communities
b. Soliciting the input of the broad group of communities
affected by the&#8232;IANA functions
(ii) Assess the outputs of the three operational communities for
compatibility and interoperability (iii) Assemble a complete
proposal for the transition
(iv) Information sharing and public communication
This Request for Proposals (RFP) addresses task (i) of the ICG
Charter. This RFP does not preclude any form of input from the
non-operational communities.
0. Complete Formal Responses
The IANA Stewardship Transition Coordination Group (ICG) seeks
complete formal responses to this RFP through processes which are to
be convened by each of the "operational communities" of IANA (i.e.,
those with direct operational or service relationships with the IANA
functions operator, in connection with names, numbers, or protocol
parameters).
Proposals should be supported by the broad range of stakeholders
participating in the proposal development process. Proposals should
be developed through a transparent process that is open to and
inclusive of all stakeholders interested in participating in the
development of the proposal. In order to help the ICG maintain its
light coordination role, all interested and affected parties are
strongly encouraged to participate directly in these community
processes.
The following link provides information about ongoing community
processes and how to participate in them, and that will continue to
be updated over time:
https://www.icann.org/en/stewardship/community
In this RFP, "IANA" refers to the functions currently specified in
the agreement between NTIA and ICANN
[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well
as any other functions traditionally performed by the IANA functions
operator. SAC-067
[https://www.icann.org/en/system/files/files/sac-067-en.pdf]
provides one description of the many different meanings of the term
"IANA" and may be useful reading in addition to the documents
constituting the agreement itself.
Communities are asked to adhere to open and inclusive processes in
developing their responses, so that all community members may fully
participate in and observe those processes. Communities are also
asked to actively seek out and encourage wider participation by any
other parties with interest in their response.
A major challenge of the ICG will be to identify and help to
reconcile differences between submitted proposals, in order to
produce a single plan for the transition of IANA
stewardship. Submitted Proposals should therefore focus on those
elements that are considered to be truly essential to the transition
of their specific IANA functions. The target deadline for all
complete formal responses to this RFP is 15 January 2015.
I. Comments
While the ICG is requesting complete formal proposals through
processes convened by each of the operational communities, and that
all interested parties get involved as early as possible in the
relevant community processes, some parties may choose to provide
comments directly to the ICG about specific aspects of particular
proposals, about the community processes, or about the ICG's own
processes. Comments may be directly submitted to the ICG any time
via email to icg-forum@icann.org. Comments will be publicly archived
at <http://forum.icann.org/lists/icg-forum/>.
Commenters should be aware that ICG will direct comments received to
the relevant operational communities if appropriate. The ICG will
review comments received as time and resources permit and in
accordance with the overall timeline for the transition. That is,
comments received about specific proposals may not be reviewed until
those proposals have been submitted to the ICG. The ICG may
establish defined public comment periods about specific topics in
the future, after the complete formal responses to the RFP have been
received.
Required Proposal Elements
The ICG encourages each community to submit a single proposal that
contains the elements described in this section.
Communities are requested to describe the elements delineated in the
sections below in as much detail possible, and according to the
suggested format/structure, to allow the ICG to more easily
assimilate the results. While each question is narrowly defined to
allow for comparison between answers, respondents are encouraged to
provide further information in explanatory sections, including
descriptive summaries of policies/practices and associated
references to source documents of specific policies/practices. In
this way, the responses to the questionnaire will be useful at the
operational level as well as to the broader stakeholder communities.
In the interest of completeness and consistency, proposals should
cross-reference wherever appropriate the current IANA Functions
Contract[3] when describing existing arrangements and proposing
changes to existing arrangements.
0. Proposal type
Identify which category of the IANA functions this submission
proposes to address:
[ ] Names [ ] Numbers [ ] Protocol Parameters
I. Description of Community's Use of IANA Functions
This section should list the specific, distinct IANA functions your
community relies on. For each IANA function on which your community
relies, please provide the following:
o A description of the function;
o A description of the customer(s) of the function;
o What registries are involved in providing the function;
o A description of any overlaps or interdependencies between your
IANA requirements and the functions required by other customer
communities.
If your community relies on any other IANA service or activity
beyond the scope of the IANA functions contract, you may describe
them here. In this case please also describe how the service or
activity should be addressed by the transition plan.
II. Existing, Pre-Transition Arrangements
This section should describe how existing IANA-related arrangements
work, prior to the transition.
[3] http://www.ntia.doc.gov/files/ntia/
publications/sf_26_pg_1-2-final_award_and_sacs.pdf
A. Policy Sources
This section should identify the specific source(s) of policy which
must be followed by the IANA functions operator in its conduct of
the services or activities described above. If there are distinct
sources of policy or policy development for different IANA
functions, then please describe these separately. For each source of
policy or policy development, please provide the following:
o Which IANA function (identified in Section I) are affected.
o A description of how policy is developed and established and who
is involved in policy development and establishment.
o A description of how disputes about policy are resolved.
o References to documentation of policy development and dispute
resolution processes.
B. Oversight and Accountability
This section should describe all the ways in which oversight is
conducted over the IANA functions operator's provision of the
services and activities listed in Section I and all the ways in
which the IANA functions operator is currently held accountable for
the provision of those services. For each oversight or
accountability mechanism, please provide as many of the following as
are applicable:
Which IANA functions (identified in Section I) are affected. If the
policy sources identified in Section II.A are affected, identify
which ones are affected and explain in what way.
o A description of the entity or entities that provide oversight or
perform accountability functions, including how individuals are
selected or removed from participation in those entities.
o A description of the mechanism (e.g., contract, reporting scheme,
auditing scheme, etc.). This should include a description of the
consequences of the IANA functions operator not meeting the
standards established by the mechanism, the extent to which the
output of the mechanism is transparent and the terms under which
the mechanism may change.
o Jurisdiction(s) in which the mechanism applies and the legal basis
on which the mechanism rests.
III. Proposed Post-Transition Oversight and Accountability
Arrangements
This section should describe what changes your community is
proposing to the arrangements listed in Section II.B in light of the
transition. If your community is proposing to replace one or more
existing arrangements with new arrangements, that replacement should
be explained and all of the elements listed in Section II.B should
be described for the new arrangements. Your community should provide
its rationale and justification for the new arrangements.
If your community's proposal carries any implications for the
interface between the IANA functions and existing policy arrangements
described in Section II.A, those implications should be described
here.
If your community is not proposing changes to arrangements listed in
Section II.B, the rationale and justification for that choice should
be provided here.
IV. Transition Implications
This section should describe what your community views as the
implications of the changes it proposed in Section III. These
implications may include some or all of the following, or other
implications specific to your community:
Description of operational requirements to achieve continuity of
service and possible new service integration throughout the
transition.
Risks to operational continuity and how they will be addressed.
Description of any legal framework requirements in the absence of the
NTIA contract. Description of how you have tested or evaluated the
workability of any new technical or operational methods proposed in
this document and how they compare to established arrangements.
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 Authors' Addresses
Eliot Lear (editor) Eliot Lear (editor)
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Russ Housley (editor) Russ Housley (editor)
918 Spring Noll Drive 918 Spring Noll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 19 change blocks. 
132 lines changed or deleted 493 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/