draft-ietf-lisp-eid-block-mgmnt-07.txt		rfc7955.txt
	Network Working Group L. Iannone		Internet Engineering Task Force (IETF) L. Iannone
	Internet-Draft Telecom ParisTech		Request for Comments: 7955 Telecom ParisTech
	Intended status: Informational R. Jorgensen		Category: Informational R. Jorgensen
	Expires: October 8, 2016 Bredbandsfylket Troms		ISSN: 2070-1721 Bredbandsfylket Troms
	D. Conrad		D. Conrad
	Virtualized, LLC		Virtualized, LLC
	G. Huston		G. Huston
	APNIC - Asia Pacific Network		APNIC
	Information Center		September 2016
	April 6, 2016
	LISP EID Block Management Guidelines		Management Guidelines for the Locator/ID Separation Protocol (LISP)
	draft-ietf-lisp-eid-block-mgmnt-07.txt		Endpoint Identifier (EID) Block
	Abstract		Abstract
	This document proposes a framework for the management of the LISP EID		This document proposes a framework for the management of the Locator/
	Address Block. The framework described relies on hierarchical		ID Separation Protocol (LISP) Endpoint Identifier (EID) address
	distribution of the address space, granting temporary usage of		block. The framework described relies on hierarchical distribution
	prefixes of such space to requesting organizations.		of the address space, granting temporary usage of prefixes of such
			space to requesting organizations.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on October 8, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7955.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	4. EID Prefix Registration Policy . . . . . . . . . . . . . . . . 3		4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3
	5. EID Prefixes Registration Requirements . . . . . . . . . . . . 4		5. EID Prefixes Registration Requirements . . . . . . . . . . . 4
	6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5		6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4
	7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 6		7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Procedures to be followed by RIPE NCC . . . . . . . . . . . . 8		10. Procedures to be Followed by RIPE NCC . . . . . . . . . . . . 7
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	12.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 8
	12.2. Informative References . . . . . . . . . . . . . . . . . 9		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	2. Introduction		1. Introduction
	The Locator/ID Separation Protocol (LISP - [RFC6830]) and related		The Locator/ID Separation Protocol (LISP [RFC6830]) and related
	mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835],		mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835],
	[RFC6836], [RFC6837]) separate the IP addressing space into two		[RFC6836], [RFC6837]) separate the IP addressing space into two
	logical spaces, the End-point IDentifier (EID) space and the Routing		logical spaces, the Endpoint Identifier (EID) space and the Routing
	LOCator (RLOC) space. The first space is used to identify		Locator (RLOC) space. The first space is used to identify
	communication end-points, while the second is used to locate EIDs in		communication endpoints, while the second is used to locate EIDs in
	the Internet routing infrastructure topology.		the Internet routing infrastructure topology.
	The document [I-D.ietf-lisp-eid-block] requested an IPv6 address		[RFC7954] requests an IPv6 address block reservation exclusively for
	block reservation exclusively for use as EID prefixes in the LISP		use as EID prefixes in the LISP experiment. The rationale, intent,
	experiment. The rationale, intent, size, and usage of the EID		size, and usage of the EID address block are described in [RFC7954].
	address block are described in [I-D.ietf-lisp-eid-block].
	This document proposes a management framework for the registration of		This document proposes a management framework for the registration of
	EID prefixes from that block, allowing the requesting organization		EID prefixes from that block, allowing the requesting organization
	exclusive use of those EID prefixes limited to the duration of the		exclusive use of those EID prefixes limited to the duration of the
	LISP experiment.		LISP experiment.
			2. Requirements Notation
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	3. Definition of Terms		3. Definition of Terms
	This document does not introduce any new terms related to the set of		This document does not introduce any new terms related to the set of
	LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833],		LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833],
	[RFC6834], [RFC6835], [RFC6836], [RFC6837]), but assumes that the		[RFC6834], [RFC6835], [RFC6836], [RFC6837]), but assumes that the
	reader is familiar with the LISP terminology.		reader is familiar with the LISP terminology. [INTRO] provides an
	[I-D.ietf-lisp-introduction] provides an introduction to the LISP		introduction to the LISP technology, including its terminology.
	technology, including its terminology. .
	4. EID Prefix Registration Policy		4. EID Prefix Registration Policy
	The request for registration of EID prefixes MUST be done under the		The request for registration of EID prefixes MUST be done under the
	following policies:		following policies:
	1. EID prefixes are made available in the reserved space on a		1. EID prefixes are made available in the reserved space on a
	temporary basis and for experimental uses. The requester of an		temporary basis and for experimental uses. The requester of an
	experimental prefix MUST provide a short description of the		experimental prefix MUST provide a short description of the
	intended use or experiment that will be carried out (see		intended use or experiment that will be carried out (see
	Section 6). If the prefix will be used for activities not		Section 6). If the prefix will be used for activities not
	documented in the original description, the renewal of the		documented in the original description, renewal of the
	registration may be denied.		registration may be denied.
	2. EID prefix registrations MUST be renewed on a regular basis to		2. EID prefix registrations MUST be renewed on a regular basis to
	ensure their use by active participants in the experiment. The		ensure their use by active participants in the experiment. The
	registration period is 12 months. A renewal SHOULD NOT cause a		registration period is 12 months. A renewal SHOULD NOT cause a
	change in the EID prefix registered in the previous request. The		change in the EID prefix registered in the previous request. The
	conditions of registration renewal are the same as the conditions		conditions of registration renewal are to be the same as the
	of first EID prefix registration request.		conditions of the first EID prefix registration request.
	3. It is preferable not to reuse EID prefixes whose registration is		3. It is preferable that EID prefixes whose registrations have
	expired. When an EID prefix registration is removed from the		expired not be reused. When an EID prefix registration is
	registry, then the reuse of the EID prefix in a subsequent		removed from the registry, then the reuse of the EID prefix in a
	registration on behalf of a different end user should be avoided		subsequent registration on behalf of a different end user should
	where possible. If the considerations of overall usage of the		be avoided where possible. If the considerations of overall
	EID block prefix requires reuse of a previously registered EID		usage of the EID block prefix requires reuse of a previously
	prefix, then a minimum delay of at least one week between removal		registered EID prefix, then a minimum delay of at least one week
	and subsequent registration SHOULD be applied by the registry		between removal and subsequent registration SHOULD be applied by
	operator.		the registry operator.
	4. All registrations of EID prefixes cease at the time of the		4. When the reserved experimental LISP EID block expires, all EID
	expiration of the reserved experimental LISP EID Block. The		prefix registrations expire as well. The further disposition of
	further disposition of these prefixes and the associated registry		these prefixes and the associated registry entries are to be
	entries is to be specified in the announcement of the cessation		specified in the announcement of the cessation of this
	of this experiment.		experiment.
	5. EID Prefixes Registration Requirements		5. EID Prefixes Registration Requirements
	All EID prefix registrations MUST respect the following requirements:		All EID prefix registrations MUST satisfy the following requirements:
	1. All EID prefix registrations MUST use a globally unique EID		1. All EID prefix registrations MUST use a globally unique EID
	prefix.		prefix.
	2. The EID Prefix registration information, as specified in		2. The EID prefix registration information, as specified in
	Section 6, MUST be collected upon initial registration and		Section 6, MUST be collected upon initial registration and
	renewal, and made publicly available through interfaces allowing		renewal, and made publicly available through interfaces allowing
	both retrieval of specific registration details (search) and		both the retrieval of specific registration details (search) and
	enumeration of the entire registry contents (e.g., [RFC7481],		the enumeration of the entire registry contents (e.g., RDAP
	WHOIS, HTTP, or similar access methods).		([RFC7481]), WHOIS, HTTP, or similar access methods).
	3. The registry operator MUST permit the delegation of EID prefixes		3. The registry operator MUST permit the delegation of EID prefixes
	in the reverse DNS space to holders of registered EID prefixes.		in the reverse DNS space to holders of registered EID prefixes.
	4. Anyone can obtain an entry in the EID prefix registry, on the		4. Anyone can obtain an entry in the EID prefix registry, on the
	understanding that the prefix so registered is for the exclusive		understanding that the prefix so registered is for the exclusive
	use in the LISP experimental network, and that their registration		use in the LISP experimental network, and that their registration
	details (as specified in Section 6) are openly published in the		details (as specified in Section 6) are openly published in the
	EID prefix registry.		EID prefix registry.
	6. EID Prefix Request Template		6. EID Prefix Request Template
	The following is a basic request template for prefix registration so		The following is a basic request template for prefix registration to
	to ensure a uniform process. Such a template is inspired by the IANA		ensure a uniform process. This template is inspired by IANA's online
	Private Enterprise Number online request form		"Private Enterprise Number (PEN) Request" form
	(http://pen.iana.org/pen/PenApplication.page).		<http://pen.iana.org/pen/PenApplication.page>.
	Note that all details in this registration become part of the		Note that all details in this registration become part of the
	registry and will be published in the LISP EID Prefix Registry.		registry and will be published in the LISP EID Prefix Registry
			managed by RIPE NCC.
	The EID Prefix Request template MUST at minimum contain:		The EID Prefix Request template MUST at a minimum contain:
	1. Organization (In the case of individuals requesting an EID prefix		1. Organization (In the case of individuals requesting an EID
	this section can be left empty)		prefix, this section can be left empty)
	(a) Organization Name		(a) Organization Name
	(b) Organization Address		(b) Organization Address
	(c) Organization Phone		(c) Organization Phone
	(d) Organization WebSite		(d) Organization Website
	2. Contact Person (Mandatory)		2. Contact Person (Mandatory)
	(a) Name		(a) Name
	(b) Address		(b) Address
	(c) Phone		(c) Phone
	(d) Fax (optional)		(d) Fax (optional)
	(e) Email		(e) Email
	3. EID Prefix Request (Mandatory)		3. EID Prefix Request (Mandatory)
	(a) Prefix Size		(a) Prefix Size
	+ Expressed as an address prefix length.		+ Expressed as an address prefix length.
	(b) Prefix Size Rationale		(b) Prefix Size Rationale
	(c) Lease Period		(c) Lease Period
	+ Note Well: All EID Prefix registrations will be valid		+ Note well: All EID Prefix registrations will be valid until
	until the earlier date of 12 months from the date of		the earlier date of 12 months from the date of registration
	registration or MMMM/YYYY3.		or August 2019.
	+ All registrations may be renewed by the applicant for		+ All registrations may be renewed by the applicant for
	further 12 month periods, ending on MMMM/YYYY3.		further 12-month periods, ending on August 2019.
	+ According to the 3+3 year experimentation plan, defined		+ According to the 3+3 year experimentation plan, defined in
	in [I-D.ietf-lisp-eid-block], all registrations MUST end		[RFC7954], all registrations MUST end by August 2019, unless
	by MMMM/YYYY3, unless the IETF community decides to grant		the IETF community decides to grant a permanent LISP EID
	a permanent LISP EID address block. In the latter case,		address block. In the latter case, registrations following
	registrations following the present document policy MUST		the present document policy MUST end by August 2022 and a
	end by MMMM/YYYY6 and a new policy (to be decided - see		new policy (to be decided -- see Section 7) will apply
	Section 7) will apply afterwards.		thereafter.
	4. Experiment Description		4. Experiment Description
	(a) Experiment and Deployment Description		(a) Experiment and Deployment Description
	(b) Interoperability with existing LISP deployments		(b) Interoperability with Existing LISP Deployments
	(c) Interoperability with Legacy Internet		(c) Interoperability with Legacy Internet
	5. Reverse DNS Servers (Optional)		5. Reverse DNS Servers (Optional)
	(a) Name server name:		(a) Name Server Name
	(b) Name server address:		(b) Name Server Address
	(c) Name server name:		(c) Name Server Name
	(d) Name server address:		(d) Name Server Address
	(Repeat if necessary)		(Repeat if necessary)
	7. Policy Validity Period		7. Policy Validity Period
	Policy outlined in the present document is tied to the existence of		The policy outlined in the present document is tied to the existence
	the experimental LISP EID block requested in		of the experimental LISP EID block requested in [RFC7954] and is
	[I-D.ietf-lisp-eid-block] and valid until MMMM/YYYY3.		valid until August 2019.
	If the IETF decides to transform the block in a permanent allocation,
	the LISP EID block reserved usage period will be extended for three
	years (until MMMM/YYYY6) so as to give time to the IETF to define,
	following the policies outlined in [RFC5226], the final size of the
	EID block and create a transition plan, while the policy in the
	present document will still apply.
	Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of
	the EID block into a permanent allocation has the potential to pose
	policy issues (as recognized in [RFC2860], section 4.3) and hence
	discussion with the IANA, the RIR communities, and the IETF community
	will be necessary to determine appropriate policy for permanent EID
	prefix management, which will be effective after MMMM/YYYY6.
	[RFC Editor: please replace MMMM and all its occurrences in the
	document with the month of publication of [I-D.ietf-lisp-eid-block]
	as RFC.]
	[RFC Editor: please replace YYYY0 and all its occurrences in the
	document with the year of publication of [I-D.ietf-lisp-eid-block] as
	RFC.]
	[RFC Editor: please replace YYYY3 and all its occurrences in the		If the IETF decides to transform the block into a permanent
	document with the year of publication of [I-D.ietf-lisp-eid-block] as		allocation, the usage period reserved for the LISP EID block will be
	RFC plus 3 years, e.g., if published in 2016 then put 2019.]		extended for three years (until August 2022) to allow time for the
			IETF to define, following the policies outlined in [RFC5226], the
			final size of the EID block and create a transition plan, while the
			policy in the present document will still apply.
	[RFC Editor: please replace YYYY6 and all its occurrences in the		Note that, as stated in [RFC7954], the transition of the EID block
	document with the year of publication of [I-D.ietf-lisp-eid-block] as		into a permanent allocation has the potential to pose policy issues
	RFC plus 6 years, e.g., if published in 2016 then put 2022.]		(as recognized in [RFC2860], Section 4.3); hence, discussion with the
			IANA, the Regional Internet Registry (RIR) communities, and the IETF
			community will be necessary to determine the appropriate policy for
			permanent EID prefix management, which will be effective after August
			2022.
	8. Security Considerations		8. Security Considerations
	This document does not introduce new security threats in the LISP		This document does not introduce new security threats in the LISP
	architecture nor in the Legacy Internet architecture.		architecture nor in the Legacy Internet architecture.
	For accountability reasons and in line with the security		For accountability reasons and in line with the security
	considerations in [RFC7020], each registration request MUST contain		considerations in [RFC7020], each registration request MUST contain
	accurate information on the requesting entity (company, institution,		accurate information about the requesting entity (company,
	individual, etc.) and valid and accurate contact information of a		institution, individual, etc.) and valid and accurate contact
	referral person (see Section 6).		information of a referral person (see Section 6).
	9. IANA Considerations		9. IANA Considerations
	IANA allocated the following IPv6 address block for experimental use		IANA allocated the following IPv6 address block for experimental use
	as LISP EID prefix [I-D.ietf-lisp-eid-block]:		as the LISP EID prefix [RFC7954]:
	o Address Block: 2001:5::/32		o Address Block: 2001:5::/32
	o Name: EID Space for LISP		o Name: EID Space for LISP
	o RFC: [I-D.ietf-lisp-eid-block]		o RFC: [RFC7954]
	o Further Details at: http://www.iana.org/assignments/		o Further details are at: www.iana.org/assignments/iana-ipv6-
	iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml		special-registry
	In order to grant requesting organisations and individuals exclusive		To grant requesting organizations and individuals exclusive use of
	use of EID prefixes out of such reserved block (limited to the		EID prefixes out of this reserved block (limited to the duration of
	duration of the LISP experiment as outlined in Section 7) there is an		the LISP experiment as outlined in Section 7), there is an
	operational requirement for an EID registration service.		operational requirement for an EID registration service.
	Provided that the policies and requirements outlined in Section 4,		Provided that the policies and requirements outlined in Sections 4,
	Section 5, and Section 6 are respected, EID prefix registration is		5, and 6 are satisfied, EID prefix registration is accorded based on
	accorded based on a "First Come First Served" basis.		a "First Come First Served" basis.
	There is no hard limit in the number of registrations an organization		There is no hard limit to the number of registrations an organization
	or individual can submit as long as information described in		or individual can submit, as long as the information described in
	Section 6 is provided, in particular point 4: "Experiment		Section 6 is provided, in particular point 4: "Experiment
	Description".		Description".
	For the duration defined in [I-D.ietf-lisp-eid-block] RIPE NCC will		For the duration defined in [RFC7954], RIPE NCC will manage the LISP
	manage the the LISP EID prefix as described herein. Therefore, this		EID prefix as described herein. Therefore, this document has no IANA
	document has no IANA actions.		actions.
	10. Procedures to be followed by RIPE NCC		10. Procedures to be Followed by RIPE NCC
	RIPE NCC will provide the registration service following the EID		RIPE NCC will provide the registration service following the EID
	Prefix Registration Policy (Section 4) and the EID Prefix		Prefix Registration Policy (Section 4) and the EID Prefix
	Registration Requirements (Section 5) provided in this document. The		Registration Requirements (Section 5) provided in this document. The
	request form provided by RIPE NCC will include at least the		request form provided by RIPE NCC will include at least the
	information from the template in Section 6. RIPE NCC will make		information from the template in Section 6. RIPE NCC will make all
	publicly available all received requests. While this document does		received requests publicly available. While this document does not
	not suggests any minimum allocation size, RIPE NCC is allowed to		suggest any minimum allocation size; RIPE NCC is allowed to introduce
	introduce such minimum size for management purposes.		such a minimum size for management purposes.
	11. Acknowledgments
	Thanks to A. Retana, J. Arko, P. Yee, A. de la Haye, A. Cima, A
	Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis,
	D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful
	comments.
	The work of Luigi Iannone has been partially supported by the ANR-13-
	INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
	Labs SOFNETS Project.
	12. References
	12.1. Normative References		11. References
	[I-D.ietf-lisp-eid-block]		11.1. Normative References
	Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
	EID Block", draft-ietf-lisp-eid-block-13 (work in
	progress), February 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	12.2. Informative References		[RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller,
			"Locator/ID Separation Protocol (LISP) Endpoint Identifier
			(EID) Block", RFC 7954, DOI 10.17487/RFC7954, September
			2016, <http://www.rfc-editor.org/info/rfc7954>.
	[I-D.ietf-lisp-introduction]		11.2. Informative References
	Cabellos-Aparicio, A. and D. Saucez, "An Architectural
			[INTRO] Cabellos-Aparicio, A. and D. Saucez, "An Architectural
	Introduction to the Locator/ID Separation Protocol		Introduction to the Locator/ID Separation Protocol
	(LISP)", draft-ietf-lisp-introduction-13 (work in		(LISP)", Work in Progress, draft-ietf-lisp-introduction-
	progress), April 2015.		13, April 2015.
	[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,		Internet Assigned Numbers Authority", RFC 2860,
	DOI 10.17487/RFC2860, June 2000,		DOI 10.17487/RFC2860, June 2000,
	<http://www.rfc-editor.org/info/rfc2860>.		<http://www.rfc-editor.org/info/rfc2860>.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The		[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830,		Locator/ID Separation Protocol (LISP)", RFC 6830,
	DOI 10.17487/RFC6830, January 2013,		DOI 10.17487/RFC6830, January 2013,
	<http://www.rfc-editor.org/info/rfc6830>.		<http://www.rfc-editor.org/info/rfc6830>.
	[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The		[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
	Locator/ID Separation Protocol (LISP) for Multicast		Locator/ID Separation Protocol (LISP) for Multicast
	Environments", RFC 6831, DOI 10.17487/RFC6831,		Environments", RFC 6831, DOI 10.17487/RFC6831, January
	January 2013, <http://www.rfc-editor.org/info/rfc6831>.		2013, <http://www.rfc-editor.org/info/rfc6831>.
	[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking between Locator/ID Separation Protocol		"Interworking between Locator/ID Separation Protocol
	(LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/		(LISP) and Non-LISP Sites", RFC 6832,
	RFC6832, January 2013,		DOI 10.17487/RFC6832, January 2013,
	<http://www.rfc-editor.org/info/rfc6832>.		<http://www.rfc-editor.org/info/rfc6832>.
	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation		[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Protocol (LISP) Map-Server Interface", RFC 6833,		Protocol (LISP) Map-Server Interface", RFC 6833,
	DOI 10.17487/RFC6833, January 2013,		DOI 10.17487/RFC6833, January 2013,
	<http://www.rfc-editor.org/info/rfc6833>.		<http://www.rfc-editor.org/info/rfc6833>.
	[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID		[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
	Separation Protocol (LISP) Map-Versioning", RFC 6834,		Separation Protocol (LISP) Map-Versioning", RFC 6834,
	DOI 10.17487/RFC6834, January 2013,		DOI 10.17487/RFC6834, January 2013,
	<http://www.rfc-editor.org/info/rfc6834>.		<http://www.rfc-editor.org/info/rfc6834>.
	[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation		[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
	Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/		Protocol Internet Groper (LIG)", RFC 6835,
	RFC6835, January 2013,		DOI 10.17487/RFC6835, January 2013,
	<http://www.rfc-editor.org/info/rfc6835>.		<http://www.rfc-editor.org/info/rfc6835>.
	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,		[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol Alternative Logical		"Locator/ID Separation Protocol Alternative Logical
	Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,		Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
	January 2013, <http://www.rfc-editor.org/info/rfc6836>.		January 2013, <http://www.rfc-editor.org/info/rfc6836>.
	[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to		[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
	Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/		Routing Locator (RLOC) Database", RFC 6837,
	RFC6837, January 2013,		DOI 10.17487/RFC6837, January 2013,
	<http://www.rfc-editor.org/info/rfc6837>.		<http://www.rfc-editor.org/info/rfc6837>.
	[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, DOI 10.17487/		Internet Numbers Registry System", RFC 7020,
	RFC7020, August 2013,		DOI 10.17487/RFC7020, August 2013,
	<http://www.rfc-editor.org/info/rfc7020>.		<http://www.rfc-editor.org/info/rfc7020>.
	[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the		[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
	Registration Data Access Protocol (RDAP)", RFC 7481,		Registration Data Access Protocol (RDAP)", RFC 7481,
	DOI 10.17487/RFC7481, March 2015,		DOI 10.17487/RFC7481, March 2015,
	<http://www.rfc-editor.org/info/rfc7481>.		<http://www.rfc-editor.org/info/rfc7481>.
	Appendix A. Document Change Log		Acknowledgments
	Version 07 Posted April 2016.
	o Addressed editorial issues raised in Gen-Art review by Peter Yee.
	o Removed "Definition of Terms" section as suggested by Peter Yee in
	the Gen-Art review.
	o Section "IANA Considerations" has been re-written to fix issue
	raised by IESG, IANA, and P. Yee.
	o Deleted bullet allowing multiple operators in the requirements
	section. Due to the limited duration of the experiment one single
	registration operator (RIPE) is sufficient.
	o Modified the dates, introducing variables, so to allow RFC Editor
	to easily update dates by publication as RFC.
	Version 06 Posted August 2015.
	o Fixed Authors addresses and typo in section 10.
	Version 05 Posted July 2015.
	o Added explicit text about RIPE NCC providing the registration
	service during the temporary experiment.
	Version 04 Posted December 2014.
	o Added two clarification sentences to address the comments of E.
	Lear and D. Saucez during WG LC.
	Version 03 Posted October 2014.
	o Re-worded the document so to avoid confusion on "allocation" and
	"assignement". The document now reffers to "registration". As
	for comments by G. Huston and M. Binderberger.
	Version 02 Posted July 2014.
	o Deleted the trailing paragraph of Section 4, as for discussion in
	the mailing list.
	o Deleted the fees policy as of suggestion of G. Huston and
	discussion during 89th IETF.
	o Re-phrased the availability of the registration information
	requirement avoiding putting specific numbers (previously
	requiring 99% up time), as of suggestion of G. Huston and
	discussion during 89th IETF.
	Version 01 Posted February 2014.
	o Dropped the reverse DNS requirement as for discussion during the
	88th IETF meeting.
	o Dropped the minimum allocation requirement as for discussion
	during the 88th IETF meeting.
	o Changed Section 7 from "General Consideration" to "Policy Validity
	Period", according to J. Curran feedback. The purpose of the
	section is just to clearly state the period during which the
	policy applies.
	Version 00 Posted December 2013.		Thanks to A. Retana, J. Arkko, P. Yee, A. de la Haye, A. Cima,
			A. Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson,
			D. Lewis, D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for
			their helpful comments.
	o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.		The work of Luigi Iannone has been partially supported by the
			ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC
			ICT-Labs SOFNETS Project.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	Telecom ParisTech		Telecom ParisTech
	France		France
	Email: ggx@gigix.net		Email: ggx@gigix.net
	Roger Jorgensen		Roger Jorgensen
	Bredbandsfylket Troms		Bredbandsfylket Troms
	Norway		Norway
	Email: rogerj@gmail.com		Email: rogerj@gmail.com
	David Conrad		David Conrad
	Virtualized, LLC		Virtualized, LLC
	USA		United States
	Email: drc@virtualized.org		Email: drc@virtualized.org
	Geoff Huston		Geoff Huston
	APNIC - Asia Pacific Network Information Center		Asia Pacific Network Information Centre (APNIC)
	Australia		Australia
	Email: gih@apnic.net		Email: gih@apnic.net
End of changes. 66 change blocks.
	267 lines changed or deleted		178 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/