< draft-ietf-ianaplan-icg-response-06.txt		draft-ietf-ianaplan-icg-response-09.txt >
	IANAPLAN E. Lear, Ed.		IANAPLAN E. Lear, Ed.
	Internet-Draft R. Housley, Ed.		Internet-Draft
	Intended status: Informational November 26, 2014		Intended status: Informational R. Housley, Ed.
	Expires: May 30, 2015		Expires: July 10, 2015
			January 6, 2015
	Draft Response to the Internet Coordination Group Request for Proposals		Draft Response to the Internet Coordination Group Request for Proposals
	on the IANA protocol parameters registries		on the IANA protocol parameters registries
	draft-ietf-ianaplan-icg-response-06		draft-ietf-ianaplan-icg-response-09
	Abstract		Abstract
	This document contains the IETF response to a request for proposals		The U.S. NTIA has solicited a request from ICANN to propose how the
	from the IANA Stewardship Transition Coordination Group regarding the		NTIA should end its oversight of the IANA functions. After broad
	protocol parameters registries. It is meant to be included in an		consultations, ICANN has in turn created the IANA Stewardship
	aggregate proposal that also includes contributions covering domain		Transition Coordination Group. That group solicited proposals for
	names and numbering resources that will be submitted from their		thre three major IANA functions: names, numbers, and protocol
	respective operational communities. The IETF community is invited to		parameters. This document contains the IETF response to that
	comment and propose changes to this document.		solicitation for protocol parameters. It is meant to be included in
			an aggregate response to the NTIA alongside those for names and
			numbering resources that are being developed by their respective
			operational communities.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 30, 2015.		This Internet-Draft will expire on July 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 19
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	7. Informative References . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20		7.1. Normative References . . . . . . . . . . . . . . . . . . 20
	A.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 20		7.2. Informative References . . . . . . . . . . . . . . . . . 21
	A.2. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 20		Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 22
	A.3. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 20		A.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 22
	A.4. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20		A.2. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 22
	A.5. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 21		A.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 23
	A.6. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 21		A.4. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 23
			A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 23
			A.6. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 23
			A.7. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 23
			A.8. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 24
			A.9. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 24
	Appendix B. The Charter of the IANA Stewardship Coordination		Appendix B. The Charter of the IANA Stewardship Coordination
	Group (ICG . . . . . . . . . . . . . . . . . . . . . 21		Group (ICG . . . . . . . . . . . . . . . . . . . . . 24
	Appendix C. IANA Stewardship Transition Coordination Group		Appendix C. IANA Stewardship Transition Coordination Group
	Request for Proposals . . . . . . . . . . . . . . . 24		Request for Proposals . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Appendix D. Completed ICG response for the NTIA . . . . . . . . 33
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	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 [NTIA-Announce].
	announcement, NTIA asked the Internet Corporation for Assigned Names		In that announcement, NTIA asked the Internet Corporation for
	and Numbers (ICANN) to establish a process to deliver a proposal for		Assigned Names and Numbers (ICANN) to establish a process to deliver
	transition. As part of that process, the IANA Stewardship Transition		a proposal for transition. As part of that process, the IANA
	Coordination Group (ICG) was formed. The charter for the ICG can be		Stewardship Transition Coordination Group (ICG) was formed. The
	found in Appendix B. They solicited proposals regarding post-		charter for the ICG can be found in Appendix B. The ICG in turn
	transition arrangements from the three functional areas in order to		solicited proposals regarding post-transition arrangements from the
	put forth a proposal to the NTIA. The final request for proposal		names, numbers, and protocol parameters communities in order to put
	(RFP) can be found in Appendix C.		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
	parameters registries function. Section 1 (this section) contains an		parameters 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. We have quoted questions from that
	questionnaire we have quoted questions with ">>> " and we have		questionnaire with ">>> ", and we have prefaced answers to questions
	prefaced answers to questions being asked with "IETF Response:".		being asked with "IETF Response:". Note that there are small changes
			to the questions asked in order to match the RFC format.
	Note that there are small changes to the content of the questions
	asked in order to match the RFC format.
	As if to demonstrate the last point, the following text was included		We note that the following text was stated as footnote in the
	in a footnote in the original RFP:		original RFP:
	In this RFP, "IANA" refers to the functions currently specified in		In this RFP, "IANA" refers to the functions currently
	the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/		specified in the agreement between NTIA and ICANN
	iana-functions-purchase-order] as well as any other functions		[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as
	traditionally performed by the IANA functions operator. SAC-067		well as any other functions traditionally performed by the IANA
	[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides		functions operator. SAC-067
	one description of the many different meanings of the term "IANA" and		[https://www.icann.org/en/system/files/files/sac-067-en.pdf]
	may be useful reading in addition to the documents constituting the		provides one description of the many different meanings of the
	agreement itself.		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
	The entire Request for Proposals, including introduction, can be		The entire Request for Proposals, including introduction, can be
	found in Appendix C.		found in Appendix C.
	>>>		>>>
	>>> 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		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 Internet Architecture Board 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
	>>>		>>>
	>>> This section should list the specific, distinct IANA services		>>> This section should list the specific, distinct IANA services
	>>> or activities your community relies on. For each IANA service		>>> or activities your community relies on. For each IANA service
	>>> or activity on which your community relies, please provide the		>>> or activity on which your community relies, please provide the
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 27 ¶
	Many IETF protocols make use of commonly defined protocol parameters.		Many IETF protocols make use of commonly defined protocol parameters.
	These parameters are used by implementers, who are the primary users		These parameters are used by implementers, who are the primary users
	of the IETF standards and other documents. To ensure consistent		of the IETF standards and other documents. To ensure consistent
	interpretation of these parameter values by independent		interpretation of these parameter values by independent
	implementations, and to promote universal interoperability, these		implementations, and to promote universal interoperability, these
	IETF protocol specifications define and require globally available		IETF protocol specifications define and require globally available
	registries containing the parameter values and a pointer to any		registries containing the parameter values and a pointer to any
	associated documentation. The IETF uses the IANA protocol parameters		associated documentation. The IETF uses the IANA protocol parameters
	registries to store this information in a public location. The IETF		registries to store this information in a public location. The IETF
	community presently accesses the protocol parameter registries via		community presently accesses the protocol parameter registries via
	references based on iana.org domain name, and makes use of the term		references based on the iana.org domain name, and makes use of the
	"IANA" in the protocol parameter registry processes [RFC5226].		term "IANA" in the protocol parameter registry processes [RFC5226].
	ICANN currently operates the .ARPA top level domain on behalf of the		ICANN currently operates the .ARPA top level domain on behalf of the
	Internet Architecture Board (IAB). This zone is used for certain		Internet Architecture Board (IAB). This zone is used for certain
	Internet infrastructure services that are delegated beneath it. We		Internet infrastructure services that are delegated beneath it. The
	consider .ARPA part of the protocol parameters registries for		IETF considers .ARPA part of the protocol parameters registries for
	purposes of this response.		purposes of this response.
	>>>		>>>
	>>> 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 IANA protocol parameters registries operator maintains the		The IANA protocol parameters registries operator maintains the
	protocol parameters registries for the IETF in conformance with all		protocol parameters registries for the IETF in conformance with all
	relevant IETF policies, in accordance with the Memorandum of		relevant IETF policies, in accordance with the Memorandum of
	Understanding [RFC2860] and associated supplemental agreements that		Understanding [RFC2860] and associated supplemental agreements that
	include service level agreements (SLAs) established between the IETF		include service level agreements (SLAs) established between the IETF
	and ICANN [MOUSUP].		and ICANN [MOUSUP].
	The IETF is a global organization that produces voluntary standards,		The IETF is a global organization that produces voluntary standards,
	whose goal is to make the Internet work better [RFC3595]. IETF		whose mission is to produce high quality, relevant technical and
	standards are published in the RFC series. The IETF is responsible		engineering documents that influence the way people design, use, and
	for the key standards that are used on the Internet today, including		manage the Internet in such a way as to make the Internet work better
	IP, TCP, DNS, BGP, and HTTP, to name but a few.
			[RFC3935]. IETF standards are published in the RFC series. The IETF
			is responsible for the key standards that are used on the Internet
			today, including IP, TCP, DNS, BGP, and HTTP, to name but a few.
	The IETF operates in an open and transparent manner [RFC6852]. The		The IETF operates in 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 [BCP9info]. The standards process can be amended in
	The standards process can be amended in the same manner that		the same manner that standards are approved. That is, someone
	standards are approved. That is, someone proposes a change by		proposes a change by submitting a temporary document known as an
	submitting a temporary document known as an Internet-Draft, the		Internet-Draft, the community discusses it, and if rough consensus
	community discusses it, and if rough consensus can be found the		can be found the change is approved by the Internet Engineering
	change is approved by the Internet Engineering Steering Group (IESG),		Steering Group (IESG), who also have day-to-day responsibility for
	who also have day-to-day responsibility for declaring IETF consensus		declaring IETF consensus on technical decisions, including those that
	on technical decisions, including those that affect the IANA protocol		affect the IANA protocol parameters registries. Anyone may propose a
	parameters registries. Anyone may propose a change during a Last		change during a Last Call, and anyone may participate in the
	Call, and anyone may participate in the community discussion.		community discussion.
	>>>		>>>
	>>> What registries are involved in providing the service or		>>> What registries are involved in providing the service or
	>>> activity.		>>> activity.
	>>>		>>>
	IETF Response:		IETF Response:
	The protocol parameters registries are the product of IETF work.		The protocol parameters registries are the product of IETF work.
	These also include the top-level registry for the entire IP address		These also include the top-level registry for the entire IP address
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 45 ¶
	and a number of special use registries with regard to domain names.		and a number of special use registries with regard to domain names.
	For more detail please refer to the documentation in the "overlaps or		For more detail please refer to the documentation in the "overlaps or
	interdependencies" section.		interdependencies" section.
	Administration of the protocol parameters registries is the service		Administration of the protocol parameters registries is the service
	that is provided to the IETF.		that is provided 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		In this context, the IETF considers "overlap" to be where there is in
	some way shared responsibility for a single registry across multiple		some way shared responsibility for a single registry across multiple
	organizations. In this sense, there is no overlap between		organizations. In this sense, there is no overlap between
	organizations because responsibility for each registry is carefully		organizations because responsibility for each registry is carefully
	delineated. There are, however, points of interaction between other		delineated. There are, however, points of interaction between other
	organizations, and a few cases where we may further define the scope		organizations, and a few cases where the IETF may further define the
	of a registry for technical purposes. This is the case with both		scope of a registry for technical purposes. This is the case with
	names and numbers, as described in the paragraphs below. In all		both names and numbers, as described in the paragraphs below. In all
	cases, the IETF coordinates with the appropriate organizations.		cases, the IETF coordinates with the appropriate organizations.
	It is important to note that the IETF includes anyone who wishes to		It is important to note that the IETF does not have formal
	participate. Staff and participants from ICANN or the Regional		membership. The term "the IETF" includes anyone who wishes to
	Internet Registries (RIRs) regularly participate in IETF activities.		participate in the IETF, and IETF participants may also be members of
			other communities. Staff and participants from ICANN and the
			Regional Internet Registries (RIRs) regularly participate in IETF
			activities.
	o The IETF has specified a number of special use registries with		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 ICANN as the policy authority for the DNS root, including		with ICANN as the policy authority for the DNS root, including
	community groups that are responsible for ICANN policy on domain		community groups that are responsible for ICANN policy on domain
	names such as the Generic Names Supporting Organization (GNSO) and		names such as the Generic Names Supporting Organization (GNSO) and
	the Country Code Names Supporting Organization (ccNSO). There are		the Country Code Names Supporting Organization (ccNSO). There are
	already mechanisms in place to perform this coordination, and the		already mechanisms in place to perform this coordination, and the
	capacity to modify them to meet new conditions as they might		capacity to modify those mechanisms to meet new conditions as they
	arise. [RFC6761]		might arise. [RFC6761]
	o The IETF specifies the DNS protocol. From time to time there have		o The IETF specifies the DNS protocol. From time to time there have
	been and will be updates to that protocol. As we make changes we		been and will be updates to that protocol. As we make changes we
	will broadly consult the operational community about the impact of		will broadly consult the operational community about the impact of
	those changes, as we have done in the past.		those changes, as we have done in the past.
	o The IETF specifies minimum requirements for root servers.		o The IETF specifies minimum requirements for root servers.
	[RFC2870] Those requirements are currently under review, in		[RFC2870] Those requirements are currently under review, in
	consultations with the root server community.		consultations with the root server community.
	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. If and when that
	happens, we will consult with the RIR community, as we have done		happens, the IETF will consult and coordinate with the RIR
	in the past.		community, as we have done in the past.
	o The IETF is responsible for policy relating to the entire IP		o The IETF is responsible for policy relating to the entire IP
	address space and AS number space. Through the IANA protocol		address space and AS number space. Through the IANA protocol
	parameters registries, the IETF delegates unicast IP address and		parameters registries, the IETF delegates unicast IP address and
	AS number ranges to the RIR system [RFC7020],[RFC7249]. Special		AS number ranges to the RIRs [RFC7020],[RFC7249]. Special address
	address allocation, such as multicast and anycast addresses, often		allocation, such as multicast and anycast addresses, often require
	require coordination. Another example of IP addresses that are		coordination. Another example of IP addresses that are not
	not administered by the RIR system is Unique Local Addresses		administered by the RIR system is Unique Local Addresses (ULAs)
	(ULAs) [RFC4193], where local networks employ a prefix that is not		[RFC4193], where local networks employ a prefix that is not
	intended to be routed on the public Internet. New special address		intended to be routed on the public Internet. New special address
	allocations are added, from time to time, related to the evolution		allocations are added, from time to time, related to the evolution
	of the standards. In all cases, these special assignments are		of the standards. In all cases, these special assignments are
	listed in the IANA protocol paramters registries.		listed in the IANA protocol paramters registries.
	o The IETF maintains sub-registries for special IPv4 and IPv6		o The IETF maintains sub-registries for special IPv4 and IPv6
	assignments. These are specified in [RFC3307], [RFC5771], and		assignments. These are specified in [RFC3307], [RFC5771], and
	[RFC6890]. The IETF coordinates such assignments with the RIRs.		[RFC6890]. The IETF coordinates such assignments with the RIRs.
	o IETF standards changes may have impact on operations of RIRs and		o Changes to IETF standards may have impact on operations of RIRs
	service providers. A recent example is the extensions to BGP to		and service providers. A recent example is the extensions to BGP
	carry the Autonomous System numbers as four-octet entities		to carry the Autonomous System numbers as four-octet entities
	[RFC6793]. It is important to note that this change occurred out		[RFC6793]. It is important to note that this change occurred out
	of operational necessity, and it demonstrated strong alignment		of operational necessity, and it demonstrated strong alignment
	between the RIRs and the IETF.		between the RIRs and the IETF.
	>>> II. 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.
	>>>		>>>
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 44 ¶
	Internet Society Board of Trustees.		Internet Society Board of Trustees.
	>>>		>>>
	>>> References to documentation of policy development and dispute		>>> References to documentation of policy development and dispute
	>>> resolution processes.		>>> 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. [RFC2418] specifies working		conflict resolution and appeals process. [RFC2418] specifies working
	group procedures. Note that both of these documents have been		group procedures. Note that both of these documents have been
	amended in later RFCs as indicated in the [RFC-INDEX]. Please also		amended in later RFCs as indicated in the [RFC-INDEX].
	see the references at the bottom of this document.
	>>>		>>>
	>>> B. Oversight and Accountability		>>> B. Oversight and Accountability
	>>>		>>>
	>>> This section should describe all the ways in which oversight is		>>> This section should describe all the ways in which oversight is
	>>> conducted over IANA functions operator's provision of the		>>> conducted over IANA functions operator's provision of the
	>>> services and activities listed in Section I and all the ways in		>>> services and activities listed in Section I and all the ways in
	>>> which IANA functions operator is currently held accountab le for		>>> which IANA functions operator is currently held accountab le for
	>>> the provision of those services. For each oversight or		>>> the provision of those services. For each oversight or
	>>> accountability mechanism, please provide as many of the		>>> accountability mechanism, please provide as many of the
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 19 ¶
	>>> conducted over IANA functions operator's provision of the		>>> conducted over IANA functions operator's provision of the
	>>> services and activities listed in Section I and all the ways in		>>> services and activities listed in Section I and all the ways in
	>>> which IANA functions operator is currently held accountab le for		>>> which IANA functions operator is currently held accountab le for
	>>> the provision of those services. For each oversight or		>>> the provision of those services. For each oversight or
	>>> accountability mechanism, please provide as many of the		>>> accountability mechanism, please provide as many of the
	>>> following as are applicable:		>>> following as are applicable:
	>>>		>>>
	>>> Which IANA service or activity (identified in Section I) is		>>> Which IANA service or activity (identified in Section I) is
	>>> affected.		>>> affected.
	>>>		>>>
	IETF Response: the protocol parameters registries.		IETF Response: the protocol parameters registries.
	>>>		>>>
	>>> If not all policy sources identified in Section II.A are		>>> If not all policy sources identified in Section II.A are
	>>> affected, identify which ones are affected.		>>> 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 are affected.		registry are affected.
	>>>		>>>
	>>> A description of the entity or entities that provide oversight		>>> A description of the entity or entities that provide oversight
	>>> or perform accountability functions, including how individuals		>>> or perform accountability functions, including how individuals
	>>> are selected or removed from participation in those entities.		>>> are selected or removed from participation in those entities.
	>>>		>>>
	IETF Response:		IETF Response:
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 49 ¶
	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 must		architectural guidance to the broader community. The IAB must
	approve the appointment of an organization to act as IANA operator on		approve the appointment of an organization to act as IANA operator on
	behalf of the IETF. The IAB is also responsible for establishing		behalf of the IETF. The IAB is also responsible for establishing
	liaison relationships with other organizations on behalf of the IETF.		liaison relationships with other organizations on behalf of the IETF.
	The IAB's charter is to be found in [RFC2850].		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] and its
	process provides for selection of active members of the community who		updates. This process provides for selection of active members of
	themselves agree upon a slate of candidates. The active members are		the community who themselves agree upon a slate of candidates. The
	chosen randomly from volunteers with a history of participation in		active members are chosen randomly from volunteers with a history of
	the IETF, with limits regarding having too many active members with		participation in the IETF, with limits regarding having too many
	the same affiliation. The selection of the active members is		active members with the same affiliation. The selection of the
	performed in a manner that makes it possible for anyone to verify		active members is performed in a manner that makes it possible for
	that the correct procedure was followed. The slate of candidates		anyone to verify that the correct procedure was followed. The slate
	selected by the active members are sent to the Internet Society Board		of candidates selected by the active members are sent to the Internet
	of Trustees for confirmation. In general, members are appointed for		Society Board of Trustees for confirmation. In general, members are
	terms of two years. The IAB selects its own chair.		appointed for terms of two years. The IAB selects its own chair.
	The IAB provides oversight of the protocol parameters registries of		The IAB provides oversight of the protocol parameters 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, registries are at times operated by, or
	conjunction with, other bodies. Unless the IAB or IETF has concluded		in conjunction with, other bodies. Unless the IAB or IETF has
	that special treatment is needed, the operator for registries is		concluded that special treatment is needed, the operator for
	currently ICANN.		registries is currently ICANN.
	>>>		>>>
	>>> A description of the mechanism (e.g., contract, reporting		>>> A description of the mechanism (e.g., contract, reporting
	>>> scheme, auditing scheme, etc.). This should include a		>>> scheme, auditing scheme, etc.). This should include a
	>>> description of the consequences of the IANA functions operator		>>> description of the consequences of the IANA functions operator
	>>> not meeting the standards established by the mechanism, the		>>> not meeting the standards established by the mechanism, the
	>>> extent to which the output of the mechanism is transparent and		>>> extent to which the output of the mechanism is transparent and
	>>> the terms under which the mechanism may change.		>>> 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]. The MoU defines the work to be carried out by the IANA		[RFC2860]. The MoU defines the work to be carried out by the IANA
	functions operator for the IETF and the Internet Research Task Force		functions operator for the IETF and the Internet Research Task Force
	(IRTF), a peer organization to the IETF that focuses on research.		(IRTF), a peer organization to the IETF that focuses on
	Each year a service level agreement is negotiated that supplements		research.[RFC2014] Each year a service level agreement is negotiated
	the MoU.		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. The		Administrative Oversight Committee (IAOC) oversees the IAD. The
	members of the IAOC are also the trustees of the IETF Trust, whose		members of the IAOC are also the trustees of the IETF Trust, whose
	main purpose is to hold certain intellectual property for the benefit		main purpose is to hold certain intellectual property for the benefit
	of the IETF as a whole. IAOC members are appointed by the Internet		of the IETF as a whole. IAOC members are appointed by the Internet
	Society Board of Trustees, the IAB, the IESG, and the NOMCOM		Society Board of Trustees, the IAB, the IESG, and the NOMCOM
	[RFC4071]. The IAOC works with the IANA functions operator to		[RFC4071]. The IAOC works with the IANA functions operator to
	establish annual IANA performance metrics [METRICS] and operational		establish annual IANA performance metrics [METRICS] and operational
	procedures, and the resulting document is adopted as an supplement to		procedures, and the resulting document is adopted as an supplement to
	the MoU each year [MOUSUP]. Starting from 2014, in accordance with		the MoU each year [MOUSUP]. Starting from 2014, in accordance with
	these supplements, an annual audit is performed to ensure that		these supplements, an annual audit is performed to ensure that
	protocol parameter requests are being processed according to the		protocol parameter requests are being processed according to the
	established policies. The conclusions of this audit will be		established policies. The conclusions of this audit will be
	available for anyone in the world to review.		available for anyone in the world to review.
	To date there have been no unresolvable disputes or issues. In the		To date there have been no unresolvable disputes or issues between
			the IETF and the current IANA functions operator. [RFC2860]
			specifies that should a technical dispute arise, "the IANA shall seek
			and follow technical guidance exclusively from the IESG." In the
	unlikely event that a more difficult situation should arise, the IAOC		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. In that case a new IANA
			functions operator would be selected, and a new agreement with that
			operator would be established.
	>>>		>>>
	>>> Jurisdiction(s) in which the mechanism applies and the legal		>>> 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
	This mechanism is global in nature. The current agreement does not		This mechanism is global in nature. The current agreement does not
	specify a jurisdiction.		specify a jurisdiction.
	skipping to change at page 11, line 36 ¶		skipping to change at page 12, line 5 ¶
	>>> existing policy arrangements described in Section II.A, those		>>> existing policy arrangements described in Section II.A, those
	>>> implications should be described here.		>>> implications should be described here.
	>>>		>>>
	>>> If your community is not proposing changes to arrangements		>>> If your community is not proposing changes to arrangements
	>>> listed in Section II.B, the rationale and justification for that		>>> listed in Section II.B, the rationale and justification for that
	>>> choice should be provided here.		>>> choice should be provided here.
	>>>		>>>
	IETF Response:		IETF Response:
	No major changes are required. Over the years since the creation of		No new organizations or structures are required. Over the years
	ICANN, the IETF, ICANN, and IAB have together created a system of		since the creation of ICANN, the IETF, ICANN, and IAB have together
	agreements, policies, and oversight mechanisms that already cover		created a system of agreements, policies, and oversight mechanisms
	what is needed. This system has worked well without any operational		that already cover what is needed. This system has worked well
	involvement from the NTIA. Therefore, no new organizaitons or		without any operational involvement from the NTIA.
	structures are needed.
	IANA protocol parameters registry updates will continue to function		IANA protocol parameters registry updates will continue to function
	day-to-day, as they have been doing for the last decade or more. The		day-to-day, as they have been doing for the last decade or more. The
	IETF community is quite satisfied with the current arrangement with		IETF community is very satisfied with the current arrangement with
	ICANN. RFC 2860 remains in force and has served the IETF community		ICANN. RFC 2860 remains in force and has served the IETF community
	very well. RFC 6220 has laid out an appropriate service description		very well. RFC 6220 has laid out an appropriate service description
	and requirements.		and requirements.
	However in the absence of the NTIA contract a few new arrangements		However in the absence of the NTIA contract a few new arrangements
	may be needed in order to ensure the IETF community's expectations		may be needed in order to ensure the IETF community's expectations
	are met. Those expectations are the following:		are met. Those expectations are the following:
	o The protocol parameters registries are in the public domain. It		o The protocol parameters registries are in the public domain. It
	is the preference of the IETF community that all relevant parties		is the preference of the IETF community that all relevant parties
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 39 ¶
	part of the NTIA transition, ICANN acknowledge that it will carry		part of the NTIA transition, ICANN acknowledge that it will carry
	out the obligations established under C.7.3 and I.61 of the		out the obligations established under C.7.3 and I.61 of the
	current IANA functions contract between ICANN and the NTIA		current IANA functions contract between ICANN and the NTIA
	[NTIA-Contract] to achieve a smooth transition to subsequent		[NTIA-Contract] to achieve a smooth transition to subsequent
	operator(s), should the need arise. Furthermore, in the event of		operator(s), should the need arise. Furthermore, in the event of
	a transition it is the expectation of the IETF community that		a transition it is the expectation of the IETF community that
	ICANN, the IETF, and subsequent operator(s) will work together to		ICANN, the IETF, and subsequent operator(s) will work together to
	minimize disruption in the use the protocol parameters registries		minimize disruption in the use the protocol parameters registries
	or other resources currently located at iana.org.		or other resources currently located at iana.org.
	Discussions during the IETF 89 meeting in London led to the following		In developing our response we have been mindful of the following
	guiding principles for IAB efforts that impact IANA protocol		points that the IETF community has discussed over the last year
	parameter registries. These principles must be taken together; their		[ProtoParamEvo14] that have led to the following guiding principles
	order is not significant.		for IAB efforts that impact IANA protocol parameter registries.
			These principles must be taken together; their order is not
			significant.
	1. The IETF protocol parameters registries function has been and		1. The IETF protocol parameters registries 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
	critical protocol parameters are to the proper functioning of IETF		critical protocol parameters are to the proper functioning of IETF
	protocols.		protocols.
	We think the structures that sustain the protocol parameters		We think the structures that sustain the protocol parameters
	skipping to change at page 14, line 36 ¶		skipping to change at page 15, line 4 ¶
	>>> of service and possible new service integration throughout		>>> of service and possible new service integration throughout
	>>> the transition.		>>> the transition.
	>>> o Risks to operational continuity		>>> o Risks to operational continuity
	>>> o Description of any legal framework requirements in the		>>> o Description of any legal framework requirements in the
	>>> absence of the NTIA contract		>>> absence of the NTIA contract
	>>> o Description of how you have tested or evaluated the		>>> o Description of how you have tested or evaluated the
	>>> workability of any new technical or operational methods		>>> workability of any new technical or operational methods
	>>> proposed in this document and how they compare to established		>>> proposed in this document and how they compare to established
	>>> arrangements.		>>> arrangements.
	>>>		>>>
	IETF Response:		IETF Response:
	No structural changes are required. The principles listed above will		No structural changes are required for the handling of protocol
	guide IAB, IAOC, and the rest of the IETF community as they work with		parameters. The principles listed above will guide IAB, IAOC, and
	ICANN to establish future IANA performance metrics and operational		the rest of the IETF community as they work with ICANN to establish
	procedures, as they have in the past.		future IANA performance metrics and operational procedures, as they
			have in the past.
	As no services are expected to change, no continuity issues are		As no services are expected to change, no continuity issues 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 any		What is necessary as part of transition is the completion of any
	supplemental agreement(s) necessary to achieve the requirements		supplemental agreement(s) necessary to achieve the requirements
	outlined in our response in Section III of this RFP.		outlined in our response in Section III of this RFP.
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 33 ¶
	>>> 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		Because the IETF is open to everyone, participation is open to all
	and procedures are outlined in the documents we named above. In-		stakeholders. IETF processes outlined in Section I were used to
	person attendance is not required for participation, and many people		develop this proposal. Those same processes have been and shall be
	participate in email discussions that have never attended an IETF		used to amend governance of the protocol parameters function. As
	meeting. An email account is the only requirement to participate.		mentioned previously, anyone may propose amendments to those
	The IETF makes use of both formal and informal lines of communication		processes, and anyone may take part in the decision process.
	to collaborate with other organizations within the multistakeholder
	ecosystem.
	>>>		>>>
	>>> "Maintain the security, stability, and resiliency of the		>>> "Maintain the security, stability, and resiliency of the
	>>> Internet DNS;"		>>> Internet DNS;"
	>>>		>>>
	IETF Response:		IETF Response:
	No changes are proposed in this document that affect the security,		No changes are proposed in this document that affect the security,
	stability, and resiliency of the DNS.		stability, and resiliency of the DNS.
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 33 ¶
	>>>		>>>
	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 parameters registries policies. Further, an		the IANA protocol parameters registries 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 in the RFC series and the protocol parameters		specification published in the RFC series and the protocol parameters
	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 have their requests
	specified by the existing policies for those registries.		satisfied, as specified by the existing policies for those
			registries.
			>>>
			>>> "The proposal must not replace the NTIA role with a
			>>> government-led or an inter-governmental organization solution."
			>>>
			Policy oversight is performed by the IAB, which is neither a
			government-led or an intergovernmental organization.
	>>>		>>>
	>>> VI. Community Process		>>> VI. Community Process
	>>>		>>>
	>>> This section should describe the process your community used for		>>> This section should describe the process your community used for
	>>> developing this proposal, including:		>>> developing this proposal, including:
	>>>		>>>
	>>> o The steps that were taken to develop the proposal and to		>>> o The steps that were taken to develop the proposal and to
	>>> determine consensus.		>>> 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) has been 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 has been welcome. Normal IETF procedures
			[RFC2026] [RFC2418] were used to determine rough consensus. The
			chairs of the working group reviewed open issues and, after an
			internal working group last call, determined that all had been
			satisfactorily addressed, and subsequently the IESG did a formal
			IETF-wide Last Call followed by a formal review and determined that
			the document had rough consensus.
	>>>		>>>
	>>> Links to announcements, agendas, mailing lists, consultations and		>>> Links to announcements, agendas, mailing lists, consultations and
	>>> meeting proceedings.		>>> meeting proceedings.
	>>>		>>>
	IETF Response:		IETF Response:
	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: http://w		Creation of an open mailing list to discuss the transition:
	ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html		http://mailarchive.ietf.org/arch/msg/ietf-announce/Ztd2ed9U04qSxI-
			k9-Oj80jJLXc
	Announcement of a public session on the transition: http://		Announcement of a public session on the transition:
	www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html		http://mailarchive.ietf.org/arch/msg/ietf-announce/
			M5zVmFFvTbtgVyMB_fjUSW4rJ0c
	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://mailarchive.ietf.org/arch/msg/ietf-announce/
	msg13170.html		QsvU9qX98G2KqB18jy6UfhwKjXk
	The working group discussion http://www.ietf.org/mail-archive/web/		The working group discussion: http://www.ietf.org/mail-
	ianaplan/current/maillist.html		archive/web/ianaplan/current/maillist.html
	Working group last call http://www.ietf.org/mail-archive/web/		2014-10-06 Interim Meeting Agenda, Minutes, and presentations:
	ianaplan/current/msg00760.html		http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/
			proceedings.html
			Working group last call: http://mailarchive.ietf.org/arch/msg/ianapl
			an/EGF9rfJxn5QpQnRXmS2QxYKYR8k
			Agenda from IETF 91 IANAPLAN WG meeting:
			http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan
			Minutes of IETF 91 IANAPLAN WG meeting:
			http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan
			Shepherd write-up: http://datatracker.ietf.org/doc/draft-ietf-
			ianaplan-icg-response/shepherdwriteup/
			IETF last call: http://mailarchive.ietf.org/arch/msg/ietf-announce/
			i5rx6PfjJCRax3Lu4qZ_38P8wBg
	>>>		>>>
	>>> An assessment of the level of consensus behind your community's		>>> An assessment of the level of consensus behind your community's
	>>> proposal, including a description of areas of contention or		>>> proposal, including a description of areas of contention or
	>>> disagreement.		>>> disagreement.
	>>>		>>>
	IETF Response: To be completed as the process progresses.		IETF Response:
			This document has attained rough consensus of the IETF Working Group
			and of the IETF community as a whole, as judged first by the working
			group chairs and then by the sponsoring Area Director, and then by
			the IESG in accordance with [RFC2026] during the 18 December 2014
			IESG telechat. The IESG has approved the draft, pending insertion of
			this answer in this section and the IAB approval note. The IAB
			approved a statement for inclusion in the document on 19 December
			2014.
			Over the course of the development of the document, several
			suggestions were raised that did not enjoy sufficient support to be
			included. Two general areas of suggestion that generated much
			discussion were
			o A suggestion for a stronger statement over what terms the IAOC
			should negotiate.
			o A suggestion that "iana.org" and other associated marks be
			transferred to the IETF trust.
			At the end of the working group process, although there was not
			unanimous support for the results, the working group chairs concluded
			that rough consensus existed in the working group. The document
			shepherd's summary of the WG consensus for this document can be found
			here:
			https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
			shepherdwriteup/
			During IETF last call, additional people voiced support for the
			document. There were several editorial comments that resulted in
			changes, as well as some discussion of more substantial comments some
			of which resulted in text changes. There was some discussion of
			comments already discussed earlier in the process, and but no new
			objections were raised during the IETF last call. A summary of the
			last call comments can be found from here:
			http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html
			New draft versions were prepared that took into account all the
			agreed changes from the last call. The final version was then
			approved by the IESG.
	3. IANA Considerations		3. IANA Considerations
	This memo is a response a request for proposals. No parameter		This memo is a response to a request for proposals. No parameter
	allocations or changes are sought.		allocations or changes are sought.
	4. Security Considerations		4. Security Considerations
	While the agreement, supplements, policies, and procedures around the		While the agreement, supplements, policies, and procedures around the
	IANA function have shown strong resiliency, the IETF will continue to		IANA function have shown strong resiliency, the IETF will continue to
	work with all relevant parties to facilitate improvements while		work with all relevant parties to facilitate improvements while
	maintaining availability of the IANA registries.		maintaining availability of the IANA registries.
	5. IAB Note		5. IAB Note
	This section to be filled in by the IAB.		The IAB supports the response in this document.
	6. Acknowledgments		6. Acknowledgments
	This document describes processes that have been developed by many		This document describes processes that have been developed by many
	members of the community over many years. The initial version of		members of the community over many years. The initial version of
	this document was developed collaboratively through both the IAB IANA		this document was developed collaboratively through both the IAB IANA
	Strategy Program and the IETF IANAPLAN WG. Particular thanks go to		Strategy Program and the IETF IANAPLAN WG. Particular thanks go to
	Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie		Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John
	Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John		Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John
	Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and		Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew
	Suzanne Woolf.		Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf.
	7. Informative References		7. References
	[I-D.leiba-cotton-iana-5226bis]		7.1. Normative References
	Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", draft-
	leiba-cotton-iana-5226bis-11 (work in progress), November
	2014.
	[METRICS] , "Performance Standards Metrics Report", ,		[BCP9info]
			"Information on "The Internet Standards Process --
			Revision 3"", <http://www.rfc-editor.org/info/rfc2026>.
			[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
	Understanding between the IETF and ICANN)", ,		between the IETF and ICANN)",
	<http://iaoc.ietf.org/contracts.html>.		<http://iaoc.ietf.org/contracts.html>.
			[NTIA-Announce]
			"NTIA Announcement of Intent to Transition Key Internet
			Domain Name Functions", March 2014,
			<http://www.ntia.doc.gov/press-release/2014/ntia-
			announces-intent-transition-key-internet-domain-name-
			functions>.
	[NTIA-Contract]		[NTIA-Contract]
	, "The NTIA Contract with ICANN", , <http://		"The NTIA Contract with ICANN",
	www.ntia.doc.gov/files/ntia/publications/		<http://www.ntia.doc.gov/files/ntia/publications/
	sf_26_pg_1-2-final_award_and_sacs.pdf>.		sf_26_pg_1-2-final_award_and_sacs.pdf>.
	[RFC-INDEX]
	RFC Editor, , "Index of all Requests for Comments", RFC
	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		[RFC2418] Bradner, S., "IETF Working Group Guidelines and
	Procedures", BCP 25, RFC 2418, September 1998.		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.
	[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
	Name Server Operational Requirements", BCP 40, RFC 2870,
	June 2000.
	[RFC3172] Huston, G., "Management Guidelines & Operational
	Requirements for the Address and Routing Parameter Area
	Domain ("arpa")", BCP 52, RFC 3172, September 2001.
	[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast		[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
	Addresses", RFC 3307, August 2002.		Addresses", RFC 3307, August 2002.
	[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC
	3595, September 2003.
	[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and		[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
	Recall Process: Operation of the Nominating and Recall		Recall Process: Operation of the Nominating and Recall
	Committees", BCP 10, RFC 3777, June 2004.		Committees", BCP 10, RFC 3777, June 2004.
			[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP
			95, RFC 3935, October 2004.
	[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF		[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
	Administrative Support Activity (IASA)", BCP 101, RFC		Administrative Support Activity (IASA)", BCP 101, RFC
	4071, April 2005.		4071, April 2005.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[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.
	[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for		[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
	IPv4 Multicast Address Assignments", BCP 51, RFC 5771,		IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
	March 2010.		March 2010.
	[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,		[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., and
	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",		[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
	RFC 6761, February 2013.		RFC 6761, February 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
			7282, June 2014.
			7.2. Informative References
			[I-D.leiba-cotton-iana-5226bis]
			Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", draft-
			leiba-cotton-iana-5226bis-11 (work in progress), November
			2014.
			[ProtoParamEvo14]
			"IAB statement on Guiding the Evolution of the IANA
			Protocol Parameter Registries", March 2014,
			<http://mailarchive.ietf.org/arch/msg/
			internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>.
			[RFC-INDEX]
			RFC Editor, , "Index of all Requests for Comments", RFC
			Index, August 2014.
			[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
			and Procedures", BCP 8, RFC 2014, October 1996.
			[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
			Name Server Operational Requirements", BCP 40, RFC 2870,
			June 2000.
			[RFC3172] Huston, G., "Management Guidelines & Operational
			Requirements for the Address and Routing Parameter Area
			Domain ("arpa")", BCP 52, RFC 3172, September 2001.
			[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
			Addresses", RFC 4193, October 2005.
	[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.
	[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The		[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
	Internet Numbers Registry System", RFC 7020, August 2013.		Internet Numbers Registry System", RFC 7020, August 2013.
	[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May		[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
	2014.		2014.
	[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
	7282, June 2014.
	Appendix A. Changes		Appendix A. Changes
	NOTE: This section to be removed by RFC Editor at publication.		NOTE: This section to be removed by RFC Editor at publication.
	A.1. Changes from -05 to -06		A.1. Changes from -08 to -09
			o Update URL for summary of the IETF Last Call.
			o Two minor editorial improvements.
			A.2. Changes from -07 to -08
			o Update text describing the consensus process.
			o Insert IAB approval text.
			o Point to the proceedings of IETF 91 for IANAPLAN WG agenda and
			minutes.
			A.3. Changes from -06 to -07
			o Merge "No new changes are needed" with "No new organizations or
			structures are required". Fewer words to say the same thing.
			o consult to consult and coordinate.
			o RFC Editor comments.
			o Edits resulting from Security Area review by Sean Turner.
			o Edits resulting from AD comments.
			A.4. Changes from -05 to -06
	o Inclusion of agreed substantial comments from the AD.		o Inclusion of agreed substantial comments from the AD.
	o Editorial changes.		o Editorial changes.
	A.2. Changes from -04 to -05		A.5. Changes from -04 to -05
	o Change to simpler text for answer about stability and security.		o Change to simpler text for answer about stability and security.
	o Mention of RFC 5226bis.		o Mention of RFC 5226bis.
	A.3. Changes from -03 to -04		A.6. Changes from -03 to -04
	o Additional text regarding what is needed in Section III.		o Additional text regarding what is needed in Section III.
	o Appropriate language modifications in section IV to match the		o Appropriate language modifications in section IV to match the
	above changes in III.		above changes in III.
	o Acknowledgments edits.		o Acknowledgments edits.
	A.4. Changes from -02 to -03		A.7. Changes from -02 to -03
	o Terminology consistency.		o Terminology consistency.
	o Add IAB section.		o Add IAB section.
	o Changes based on WG discussion on what we prefer as part of the		o Changes based on WG discussion on what we prefer as part of the
	transition regarding IPR.		transition regarding IPR.
	o Add discussion about .ARPA domain.		o Add discussion about .ARPA domain.
	skipping to change at page 21, line 17 ¶		skipping to change at page 24, line 17 ¶
	o Additional text around coordination with ICANN.		o Additional text around coordination with ICANN.
	o Working groups can adopt items within their charters.		o Working groups can adopt items within their charters.
	o IAB appointments generally last two years.		o IAB appointments generally last two years.
	o Add mention of the Trust.		o Add mention of the Trust.
	o Security Considerations update.		o Security Considerations update.
	A.5. Changes from -01 to -02		A.8. Changes from -01 to -02
	o A better description special registries and BGP ASNs.		o A better description special registries and BGP ASNs.
	o Clarity on how the address space and ASNs are delegated.		o Clarity on how the address space and ASNs are delegated.
	o Many editorials corrected.		o Many editorials corrected.
	o Mention of the annual review as part of the SLAs.		o Mention of the annual review as part of the SLAs.
	o Change about how overlap is presented.		o Change about how overlap is presented.
	o A number of small wording changes based on feedback.		o A number of small wording changes based on feedback.
	A.6. Changes from -00 to -01		A.9. Changes from -00 to -01
	o Front matter greatly reduced.		o Front matter greatly reduced.
	o Appendices with charter and RFP added.		o Appendices with charter and RFP added.
	o Jurisdiction text changed.		o Jurisdiction text changed.
	o Proposed changes include supplemental agreement(s) to address		o Proposed changes include supplemental agreement(s) to address
	jurisdiction, dispute resolution, and IPR, including names and		jurisdiction, dispute resolution, and IPR, including names and
	marks.		marks.
	skipping to change at page 25, line 4 ¶		skipping to change at page 27, line 48 ¶
	announced, proposals are stored, the ICG members are listed, etc. As		announced, proposals are stored, the ICG members are listed, etc. As
	the development of the transition plans will take some time, it is		the development of the transition plans will take some time, it is
	important that information about ongoing work is distributed early		important that information about ongoing work is distributed early
	and continuously. This will enable sharing of ideas and the		and continuously. This will enable sharing of ideas and the
	detection of potential issues.		detection of potential issues.
	Appendix C. IANA Stewardship Transition Coordination Group Request for		Appendix C. IANA Stewardship Transition Coordination Group Request for
	Proposals		Proposals
	IANA Stewardship Transition Coordination Group Request for Proposals		IANA Stewardship Transition Coordination Group Request for Proposals
	8 September 2014		8 September 2014
	Introduction		Introduction
			Under the IANA Stewardship Transition Coordination Group (ICG)
	Under the IANA1 Stewardship Transition Coordination Group (ICG)		Charter, the ICG has four main tasks:
	Charter,2 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: &#8232;		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&#8232;IANA functions		affected by the IANA functions
	(ii) Assess the outputs of the three operational communities for		(ii) Assess the outputs of the three operational communities for
	compatibility and interoperability (iii) Assemble a complete		compatibility and interoperability
			(iii) Assemble a complete
	proposal for the transition		proposal for the transition
	(iv) Information sharing and public communication		(iv) Information sharing and public communication
	This Request for Proposals (RFP) addresses task (i) of the ICG		This Request for Proposals (RFP) addresses task (i) of the ICG
	Charter. This RFP does not preclude any form of input from the		Charter. This RFP does not preclude any form of input from the
	non-operational communities.		non-operational communities.
	0. Complete Formal Responses		0. Complete Formal Responses
	skipping to change at page 30, line 24 ¶		skipping to change at page 33, line 21 ¶
	This section should describe the process your community used for		This section should describe the process your community used for
	developing this proposal, including:		developing this proposal, including:
	o The steps that were taken to develop the proposal and to determine		o The steps that were taken to develop the proposal and to determine
	consensus.		consensus.
	o Links to announcements, agendas, mailing lists, consultations and		o Links to announcements, agendas, mailing lists, consultations and
	meeting proceedings.		meeting proceedings.
	o An assessment of the level of consensus behind your community's		o An assessment of the level of consensus behind your community's
	proposal, including a description of areas of contention or		proposal, including a description of areas of contention or
	disagreement.		disagreement.
			Appendix D. Completed ICG response for the NTIA
			To be filled in with completed response.
	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 Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 79 change blocks.
	211 lines changed or deleted		366 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/