draft-ietf-lisp-eid-block-mgmnt-00.txt		draft-ietf-lisp-eid-block-mgmnt-01.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft Telecom ParisTech		Internet-Draft Telecom ParisTech
	Intended status: Informational R. Jorgensen		Intended status: Informational R. Jorgensen
	Expires: June 12, 2014 Bredbandsfylket Troms		Expires: August 18, 2014 Bredbandsfylket Troms
	D. Conrad		D. Conrad
	Virtualized, LLC		Virtualized, LLC
	December 9, 2013		February 14, 2014
	LISP EID Block Management Guidelines		LISP EID Block Management Guidelines
	draft-ietf-lisp-eid-block-mgmnt-00.txt		draft-ietf-lisp-eid-block-mgmnt-01.txt
	Abstract		Abstract
	This document proposes an allocation framework for the management of		This document proposes an allocation framework for the management of
	the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]).		the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]).
	The framework described relies on hierarchical distribution of the		The framework described relies on hierarchical distribution of the
	address space with sub-prefixes allocated on a temporary basis to		address space with sub-prefixes allocated on a temporary basis to
	requesting organizations.		requesting organizations.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 12, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3		4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3
	5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5		5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5
	6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 6		6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 6
	7. General Considerations . . . . . . . . . . . . . . . . . . . . 6		7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 7		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 7		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 11		Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Requirements Notation		1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. 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]) separates the IP addressing space into two		[RFC6836], [RFC6837]) separates the IP addressing space into two
	logical spaces, the End-point IDentifier (EID) space and the Routing		logical spaces, the End-point 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 end-points, 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		The document [I-D.ietf-lisp-eid-block] requested an IPv6 address
	block to be reserved for exclusive use for EID prefix allocation and		block reservation exclusively for the allocation and assignment of
	assignment. The rationale, intent, size, and usage of the EID		EID prefixes. The rationale, intent, size, and usage of the EID
	address block are described in [I-D.ietf-lisp-eid-block].		address block are described in [I-D.ietf-lisp-eid-block].
	This document proposes an allocation framework for the EID address		This document proposes a management framework for the allocation and
	block based on temporary allocation of portions of the block to		assignment of EID addresses from that block based on temporary
	different requesting organizations.		allocation of portions of the block to different requesting
			organizations.
	3. Definition of Terms		3. Definition of Terms
	The present document does not introduce any new term with respect to		This document does not introduce any new terms related to the set of
	the set of LISP Specifications ( [RFC6830], [RFC6831], [RFC6832],		LISP Specifications ( [RFC6830], [RFC6831], [RFC6832], [RFC6833],
	[RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]). To help the		[RFC6834], [RFC6835], [RFC6836], [RFC6837]). To help the reading of
	reading of the present document the terminology introduced by LISP is		this document the terminology introduced by LISP is summarized in
	summarized in Appendix A.		Appendix A.
	4. EID Prefix Allocation Policy		4. EID Prefix Allocation Policy
	The allocation of EID prefixes MUST respect the following policies:		The allocation of EID prefixes MUST be done under the following
			policies:
	1. EID addressing prefixes are made available in the reserved space		1. EID addressing prefixes are made available in the reserved space
	on a temporary basis and for experimental uses. The requester of		on a temporary basis and for experimental uses. The requester of
	an experimental prefix MUST provide a short description of the		an 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, the renewal of the
	allocation may be denied or withdrawn (see Section 5).		allocation may be denied or withdrawn (see Section 5).
	2. EID prefixes are allocated on a lease/license basis for a limited		2. EID prefixes are allocated on a lease/license basis for a limited
	period of time (which can be renewed). The lease/license period		period of time (which can be renewed). The lease/license period
	SHOULD NOT be longer than one year.		SHOULD NOT be longer than one year in order to ensure the leases
			and registration information about those leases is kept
			reasonably up to date.
	3. Exception to the previous rule may be granted in cases in which		3. Exception to the previous rule may be granted in cases in which
	the prefix has been delegated to an organization that will act as		the prefix has been delegated to an organization that will act as
	a registry for further sub-allocations. Sub-allocations MUST		a registry for further sub-allocations. Sub-allocations MUST
	respect this present list of policies as well as the allocation		abide by these policies as well as the allocation requirements
	requirements outlined in Section 5. Requests for a prefix		outlined in Section 5. Requests for a prefix delegation that
	delegation that will be used for further sub-allocations MUST		will be used for further sub-allocations MUST clearly state such
	clearly state such intent in the short description of the		intent in the short description of the intended use document.
	intended use document.
	4. All of the allocations (renewed or not, including delegations and		4. All of the allocations (renewed or not, including delegations and
	sub-allocations) MUST end by 31 December 2017, in accordance to		sub-allocations) MUST be returned by 31 December 2017, in
	the 3+3 years experimental allocation plan outlined in		accordance with the 3+3 years experimental allocation plan
	[I-D.ietf-lisp-eid-block].		outlined in [I-D.ietf-lisp-eid-block].
	5. Upon IETF review before 31 December 2017, the EID prefix space		5. Upon IETF review before 31 December 2017, the EID prefix space
	may become a permanent allocation. In this case existing		may become a permanent allocation. In this case existing
	allocations CAN be renewed and new allocations granted (still on		allocations CAN be renewed and new allocations granted (still on
	a yearly temporary basis). All allocations (renewed or not,		a yearly temporary basis). All allocations (renewed or not,
	including delegations and sub-allocations) MUST end by 31		including delegations and sub-allocations) MUST be returned by 31
	December 2020, in accordance to the 3+3 years plan outlined in		December 2020, in accordance to the 3+3 years plan outlined in
	[I-D.ietf-lisp-eid-block]. During the second 3 years phase of		[I-D.ietf-lisp-eid-block]. During the second 3 years phase of
	the experiment, the IETF will decide the final EID prefix block		the experiment, the IETF will decide the final EID prefix block
	size and elaborate the allocation and management policies that		size and elaborate the allocation and management policies that
	will be applied starting 1 January 2021.		will be applied starting 1 January 2021.
	6. When an allocation is freed because of non-renewal or the		6. When an allocation is freed because of non-renewal or the
	termination of an experiment, the address space is returned to		termination of an experiment, the address space is returned to
	the global pool of free EID prefixes. This freed allocation MUST		the global pool of free EID prefixes. This freed allocation MUST
	NOT be announced through registration on Map Servers in the LISP		NOT be announced through registration on Map Servers in the LISP
	skipping to change at page 5, line 12		skipping to change at page 5, line 15
	orders, etc. Withdrawal can be enforced by filtering on Map		orders, etc. Withdrawal can be enforced by filtering on Map
	Servers so to prevent map registration.		Servers so to prevent map registration.
	If/When the EID block experiment changes status (e.g., to not being		If/When the EID block experiment changes status (e.g., to not being
	"experimental"), and following the policies outlined in [RFC5226],		"experimental"), and following the policies outlined in [RFC5226],
	the EID block will change status as well and will be converted to a		the EID block will change status as well and will be converted to a
	permanent allocation. The IETF will define the transition process		permanent allocation. The IETF will define the transition process
	from the policies and requirements outlined in this document to a new		from the policies and requirements outlined in this document to a new
	set of policies and requirements. This transition process will		set of policies and requirements. This transition process will
	include mechanisms that will allow for requests to convert existing		include mechanisms that will allow for requests to convert existing
	temporary allocations (without renumbering) to permanent allocations.		temporary allocations (with or without renumbering) to permanent
			allocations.
	5. EID Prefixes Allocation Requirements		5. EID Prefixes Allocation Requirements
	All EID prefix allocations (and delegations) MUST respect the		All EID prefix allocations (and delegations) MUST respect the
	following requirements:		following requirements:
	1. Allocations MUST be globally unique.		1. Allocations MUST be globally unique.
	2. Requirements for allocation MUST be the same globally. No		2. Requirements for allocation MUST be the same globally. No
	regional/national/local variations are permitted.		regional/national/local variations are permitted.
	3. The minimum allocated prefix size MUST be a /48. An allocation		3. The registration information MUST be maintained and made publicly
	may be larger (i.e., shorter prefix) provided that the requester
	is able to justify the intended size in their request
	description.
	4. Registration information MUST be maintained and made publicly
	available through a searchable interface, preferably RDAP		available through a searchable interface, preferably RDAP
	([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or		([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or
	similar.		similar access methods.
	5. If fees are charged for EID allocation and registration services,
	those fees MUST be no more than the cost of providing those
	services.
	6. Requesters obtaining an allocation SHOULD provide Reverse DNS		4. The registration information service MUST be available 99% of the
	service.		time. The allocation service SHOULD be provided during regular
			business hours in venue in which the allocation service is
			housed.
	7. Requesters obtaining a delegation, hence acting as registries,		5. Facilities SHOULD exist to allow for the delegation of the
	MUST provide Reverse DNS service.		reverse DNS for EID address prefixes. Reverse DNS delegation is
			not required, and may not be provided from the beginning of the
			use of the EID Block. However it may be made available on a
			later stage if operational requirements necessitate it or IETF
			decides it should be available.
	8. The service SHOULD be available 99% of the time.		6. If fees are charged for EID allocation and registration services,
			those fees MUST be no more than the cost of providing those
			services.
	9. Anyone, private persons, companies, or other entities can request		7. Anyone, private persons, companies, or other entities can request
	EID space and those requests MUST be granted, provided that they		EID space and those requests MUST be granted, provided that they
	can show a clear intent in carrying out LISP experimentation.		can show a clear intent in carrying out LISP experimentation.
	6. EID Prefix Request Template		6. EID Prefix Request Template
	Future versions of this document will include a detailed allocation		The following is a basic request template for prefix allocation (and
	(and delegation) request template to ensure a uniform process. An		delegation) so to ensure a uniform process. Such a template is
	example of a similar template/process is the IANA Private Enterprise		inspired by the IANA Private Enterprise Number online request form
	Number online request form		(http://pen.iana.org/pen/PenApplication.page).
	(http://pen.iana.org/pen/PenApplication.page). The EID Prefix
	Request template MUST at minimum contain:
	o Requester Information (e.g., company name)		The EID Prefix Request template MUST at minimum contain:
	o Requester Referral Person (and Contact Information)		1. Organization (In case of individuals requesting an EID prefix
			this section can be left empty)
	o Requested EID prefix size		(a) Organization Name
	o Request Rationale		(b) Organization Address
	7. General Considerations		(c) Organization Phone
	This document is a starting point for discussion aiming to address		2. Contact Person (Mandatory)
	the concerns raised during the IETF Review of
	[I-D.ietf-lisp-eid-block], more specifically the lack of guidelines
	concerning the EID Block allocation and management.
	Discussion with IANA, the RIR communities, and the IETF community		(a) Name
	should be carried out in order to verify compatibility of the
	proposed policy and agree upon the process for EID prefix allocation		(b) Address
	and management.
			(c) Phone
			(d) Fax (optional)
			(e) Email
			3. EID Prefix Request (Mandatory)
			(a) Prefix Size
			(b) Prefix Size Rationale
			(c) Lease Period
			+ Start Date
			+ End Date
			Note that according to the 3+3 year allocation plan, defined
			in [I-D.ietf-lisp-eid-block], all allocations (and
			delegations) MUST end by 31 December 2017, unless the IETF
			community decides to grant a permanent LISP EID address
			block. In the latter case, allocations (and delegations)
			following the present document policy MUST end by 31
			December 2020 and a new policy (to be decided see Section 7)
			will apply starting 1 January 2021.
			4. Experiment Description
			(a) Experiment and Deployment Description
			(b) Interoperability with existing LISP deployments
			(c) Interoperability with Legacy Internet
			5. Reverse DNS Servers (Optional)
			(a) Name server name:
			(b) Name server address:
			(c) Name server name:
			(d) Name server address:
			(Repeat if necessary)
			7. Policy Validity Period
			Policy outlined in the present document is tight to the existence of
			the experimental LISP EID block requested in
			[I-D.ietf-lisp-eid-block] and valid until 31 December 2017.
			If the IETF decides to transform the block in a permanent allocation,
			the LISP EID block allocation period will be extended for three years
			(until 31 December 2020) so to give time to the IETF to define 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 allocation and management, which will be effective starting 1
			January 2021.
	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 allocation request MUST contain		considerations in [RFC7020], each allocation request MUST contain
	accurate information on the requesting entity (company, institution,		accurate information on the requesting entity (company, institution,
	individual, etc.) and valid and accurate contact information of a		individual, etc.) and valid and accurate contact information of a
	skipping to change at page 7, line 31		skipping to change at page 8, line 47
	IANA must ensure both of these services are provided, for the space		IANA must ensure both of these services are provided, for the space
	directly allocated by IANA, in a globally uniform fashion for the		directly allocated by IANA, in a globally uniform fashion for the
	duration of the experiment.		duration of the experiment.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-lisp-eid-block]		[I-D.ietf-lisp-eid-block]
	Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP		Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
	EID Block", draft-ietf-lisp-eid-block-06 (work in		EID Block", draft-ietf-lisp-eid-block-08 (work in
	progress), October 2013.		progress), January 2014.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
	[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.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-weirds-rdap-sec]		[I-D.ietf-weirds-rdap-sec]
	Hollenbeck, S. and N. Kong, "Security Services for the		Hollenbeck, S. and N. Kong, "Security Services for the
	Registration Data Access Protocol",		Registration Data Access Protocol",
	draft-ietf-weirds-rdap-sec-05 (work in progress),		draft-ietf-weirds-rdap-sec-05 (work in progress),
	August 2013.		August 2013.
			[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
			Understanding Concerning the Technical Work of the
			Internet Assigned Numbers Authority", RFC 2860, June 2000.
	[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,
	January 2013.		January 2013.
	[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, January 2013.		Environments", RFC 6831, January 2013.
	[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
	skipping to change at page 11, line 25		skipping to change at page 12, line 40
	logical next-hop on the overlay network. The primary function of		logical next-hop on the overlay network. The primary function of
	LISP+ALT routers is to provide a lightweight forwarding		LISP+ALT routers is to provide a lightweight forwarding
	infrastructure for LISP control-plane messages (Map-Request and		infrastructure for LISP control-plane messages (Map-Request and
	Map-Reply), and to transport data packets when the packet has the		Map-Reply), and to transport data packets when the packet has the
	same destination address in both the inner (encapsulating)		same destination address in both the inner (encapsulating)
	destination and outer destination addresses ((i.e., a Data Probe		destination and outer destination addresses ((i.e., a Data Probe
	packet). See [RFC6830] for more details.		packet). See [RFC6830] for more details.
	Appendix B. Document Change Log		Appendix B. Document Change Log
			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.		Version 00 Posted December 2013.
	o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.		o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	Telecom ParisTech		Telecom ParisTech
	Email: luigi.iannone@telecom-paristech.fr		Email: luigi.iannone@telecom-paristech.fr
End of changes. 32 change blocks.
	75 lines changed or deleted		157 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/