draft-ietf-roll-applicability-ami-10.txt		draft-ietf-roll-applicability-ami-11.txt
	Roll D. Popa		Roll D. Popa
	Internet-Draft M. Gillmore		Internet-Draft M. Gillmore
	Intended status: Standards Track Itron, Inc		Intended status: Standards Track Itron, Inc
	Expires: August 3, 2015 L. Toutain		Expires: February 4, 2016 L. Toutain
	Telecom Bretagne		Telecom Bretagne
	J. Hui		J. Hui
	Cisco		Nest
	R. Ruben		R. Ruben
	Landis+Gyr		Landis+Gyr
	K. Monden		K. Monden
	Hitachi, Ltd., Yokohama Research Laboratory		Hitachi, Ltd., Yokohama Research Laboratory
	N. Cam-Winget, Ed.		N. Cam-Winget, Ed.
	Cisco Systems		Cisco Systems
	January 30, 2015		August 3, 2015
	Applicability Statement for the Routing Protocol for Low Power and Lossy		Applicability Statement for the Routing Protocol for Low Power and Lossy
	Networks (RPL) in AMI Networks		Networks (RPL) in AMI Networks
	draft-ietf-roll-applicability-ami-10		draft-ietf-roll-applicability-ami-11
	Abstract		Abstract
	This document discusses the applicability of RPL in Advanced Metering		This document discusses the applicability of RPL in Advanced Metering
	Infrastructure (AMI) networks.		Infrastructure (AMI) networks.
	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.
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 August 3, 2015.		This Internet-Draft will expire on February 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 3, line 33		skipping to change at page 3, line 33
	distribution automation elements, and eventually home area network		distribution automation elements, and eventually home area network
	devices. They are typically inter-connected using some combination		devices. They are typically inter-connected using some combination
	of wireless and power-line communications, forming the so-called		of wireless and power-line communications, forming the so-called
	Neighbor Area Network (NAN) along with a backhaul network providing		Neighbor Area Network (NAN) along with a backhaul network providing
	connectivity to "command-and-control" management software		connectivity to "command-and-control" management software
	applications at the utility company back office.		applications at the utility company back office.
	1.1. Requirements Language		1.1. Requirements Language
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	1.2. Required Reading		1.2. Required Reading
	[surveySG] gives an overview of Smart Grid architecture and related		[surveySG] gives an overview of Smart Grid architecture and related
	applications.		applications.
	NAN can use wireless communication technology in which case is using,		NAN can use wireless communication technology in which case is using,
	from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer		from the IEEE 802.15.4 standard family, the IEEE 802.15.4g PHY Layer
	amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically		amendment and IEEE 802.15.4e MAC sub-layer amendment, specifically
	adapted to smart grid networks.		adapted to smart grid networks.
	skipping to change at page 5, line 13		skipping to change at page 5, line 13
	[RFC5673].		[RFC5673].
	o Home Automation Routing Requirements in Low-Power and Lossy		o Home Automation Routing Requirements in Low-Power and Lossy
	Networks [RFC5826].		Networks [RFC5826].
	o Building Automation Routing Requirements in Low-Power and Lossy		o Building Automation Routing Requirements in Low-Power and Lossy
	Networks [RFC5867].		Networks [RFC5867].
	The Routing Requirements for Urban Low-Power and Lossy Networks are		The Routing Requirements for Urban Low-Power and Lossy Networks are
	applicable to AMI networks as well. The terminology used in this		applicable to AMI networks as well. The terminology used in this
	document is defined in [I-D.ietf-roll-terminology].		document is defined in [RFC7102].
	3. Description of AMI networks for electric meters		3. Description of AMI networks for electric meters
	In many deployments, in addition to measuring energy consumption, the		In many deployments, in addition to measuring energy consumption, the
	electric meter network plays a central role in the Smart Grid since		electric meter network plays a central role in the Smart Grid since
	the device enables the utility company to control and query the		the device enables the utility company to control and query the
	electric meters themselves and can serve as a backhaul for all other		electric meters themselves and can serve as a backhaul for all other
	devices in the Smart Grid, e.g., water and gas meters, distribution		devices in the Smart Grid, e.g., water and gas meters, distribution
	automation and home area network devices. Electric meters may also		automation and home area network devices. Electric meters may also
	be used as sensors to monitor electric grid quality and to support		be used as sensors to monitor electric grid quality and to support
	skipping to change at page 14, line 43		skipping to change at page 14, line 43
	o IEEE 1901.2 MAC sub-layer endorses the concept of Information		o IEEE 1901.2 MAC sub-layer endorses the concept of Information
	Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The		Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. The
	format and use of Information Elements are not relevant to RPL		format and use of Information Elements are not relevant to RPL
	applicability statement.		applicability statement.
	The IEEE 1901.2 PHY frame payload size varies as a function of the		The IEEE 1901.2 PHY frame payload size varies as a function of the
	modulation used to transmit the frame and the strength of the Forward		modulation used to transmit the frame and the strength of the Forward
	Error Correction scheme.		Error Correction scheme.
	The maximum IEEE 1901.2 PHY frame payload is 512 bytes. The maximum		The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY
	IEEE 1901.2 MAC frame payload is 1280 bytes, which supports the IPv6		settings in use (e.g. bandwidth, modulation, tones, etc). As quoted
	minimum MTU requirement.		from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is
			more than 247 octets for robust OFDM (ROBO) and Super-ROBO
	When there is a mistmatch between the PHY frame payload size and the		modulations or more than 239 octets for all other modulations, the
	size of a MAC frame carrying an IPv6 packet, IEEE 1901.2 specifies a		MAC layer shall divide the MSDU into multiple segments as described
	MAC sub-layer segmentation and re-assembly mechanism that provides a		in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the
	reliable one-hop transfer of that MAC frame segments.		following conditions: a) For ROBO and Super-ROBO modulations, the
			MSDU size is more than 247 octets but less than 494 octets, b) For
			all other modulations, the MSDU size is more than 239 octets but less
			than 478 octets.
	7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features		7.2.2. IEEE 802.15.4 (g + e) PHY and MAC features
	IEEE Std 802.15.4g defines multiple modes of operation, where each		IEEE Std 802.15.4g defines multiple modes of operation, where each
	mode uses different modulation and has multiple data rates.		mode uses different modulation and has multiple data rates.
	Additionally, 802.15.4g PHY layer includes mechanisms to improve the		Additionally, 802.15.4g PHY layer includes mechanisms to improve the
	robustness of the radio communications, such as data whitening and		robustness of the radio communications, such as data whitening and
	Forward Error Correction coding. The 802.15.4g PHY frame payload can		Forward Error Correction coding. The 802.15.4g PHY frame payload can
	carry up to 2048 octets.		carry up to 2048 octets.
	skipping to change at page 15, line 32		skipping to change at page 15, line 34
	operation. These include: Timetimeslotslotted channel hopping		operation. These include: Timetimeslotslotted channel hopping
	(TSCH), specifically designed for application domains such as process		(TSCH), specifically designed for application domains such as process
	automation, Low latency deterministic networks (LLDN), for		automation, Low latency deterministic networks (LLDN), for
	application domains such as factory automation, Deterministic and		application domains such as factory automation, Deterministic and
	synchronous multi-channel extension (DSME), for general industrial		synchronous multi-channel extension (DSME), for general industrial
	and commercial application domains that includes Channel diversity to		and commercial application domains that includes Channel diversity to
	increase network robustness, and Asynchronous multi-channel		increase network robustness, and Asynchronous multi-channel
	adaptation (AMCA), for large infrastructure application domains.		adaptation (AMCA), for large infrastructure application domains.
	The MAC addressing scheme supports short (16-bits) addresses along		The MAC addressing scheme supports short (16-bits) addresses along
	with extended (64-bits) addresses.		with extended (64-bits) addresses. These addresses are assigned in
			different ways and is specified by specific standards organizations.
	Information Elements, Enhanced Beacons and frame version 2, as		Information Elements, Enhanced Beacons and frame version 2, as
	defined in 802.15.4e, MUST be supported.		defined in 802.15.4e, MUST be supported.
	Since the MAC frame payload size limitation is given by the 4g PHY		Since the MAC frame payload size limitation is given by the 4g PHY
	frame payload size limitation (i.e.,2048 bytes) and MAC layer		frame payload size limitation (i.e.,2048 bytes) and MAC layer
	overhead (headers, trailers, Information Elements and security		overhead (headers, trailers, Information Elements and security
	overhead), the MAC frame payload MUST able to carry a full IPv6		overhead), the MAC frame payload MUST able to carry a full IPv6
	packet of 1280 octets without upper layer fragmentation and re-		packet of 1280 octets without upper layer fragmentation and re-
	assembly.		assembly.
	skipping to change at page 16, line 45		skipping to change at page 16, line 50
	o AES-CBC-MAC-128 = No encryption, 128-bit MAC.		o AES-CBC-MAC-128 = No encryption, 128-bit MAC.
	o AES-CBC-MAC-64 = No encryption, 64-bit MAC.		o AES-CBC-MAC-64 = No encryption, 64-bit MAC.
	o AES-CCM-128 = Encryption and 128-bit MAC.		o AES-CCM-128 = Encryption and 128-bit MAC.
	o AES-CCM-64 = Encryption and 64-bit MAC.		o AES-CCM-64 = Encryption and 64-bit MAC.
	o AES-CCM-32 = Encryption and 32-bit MAC.		o AES-CCM-32 = Encryption and 32-bit MAC.
			Note that AES-CCM-32 is the most commonly used cipher in these
			deployments today.
	To achieve authentication, any device can maintain an Access Control		To achieve authentication, any device can maintain an Access Control
	List (ACL) which is a list of trusted nodes from which the device		List (ACL) which is a list of trusted nodes from which the device
	wishes to receive data. Data encryption is done by encryption of		wishes to receive data. Data encryption is done by encryption of
	Message Authentication Control (MAC) frame payload using the key		Message Authentication Control (MAC) frame payload using the key
	shared between two devices, or among a group of peers. If the key is		shared between two devices, or among a group of peers. If the key is
	to be shared between two peers, it is stored with each entry in the		to be shared between two peers, it is stored with each entry in the
	ACL list; otherwise, the key is stored as the default key. Thus, the		ACL list; otherwise, the key is stored as the default key. Thus, the
	device can make sure that its data can not be read by devices that do		device can make sure that its data can not be read by devices that do
	not possess the corresponding key. However, device addresses are		not possess the corresponding key. However, device addresses are
	always transmitted unencrypted, which makes attacks that rely on		always transmitted unencrypted, which makes attacks that rely on
	skipping to change at page 17, line 28		skipping to change at page 17, line 36
	constrained environments such as metering infrastructures, an optimum		constrained environments such as metering infrastructures, an optimum
	balance between security requirements and network throughput must be		balance between security requirements and network throughput must be
	found.		found.
	7.3. 6LowPAN Options		7.3. 6LowPAN Options
	AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all		AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all
	of the IPv6 Header Compression schemes specified in [RFC6282]		of the IPv6 Header Compression schemes specified in [RFC6282]
	Section 3 and all of the IPv6 Next Header compression schemes		Section 3 and all of the IPv6 Next Header compression schemes
	specified in [RFC6282] Section 4, if reducing over the air/wire		specified in [RFC6282] Section 4, if reducing over the air/wire
	overhead is a requirement. However, since the link-layer MTU in both		overhead is a requirement.
	wireless and PLC links supports the transmission of a full IPv6
	packet, the use of 6LowPAN fragmentation is NOT RECOMMENDED.
	7.4. Recommended Configuration Defaults and Ranges		7.4. Recommended Configuration Defaults and Ranges
	7.4.1. Trickle Parameters		7.4.1. Trickle Parameters
	Trickle was designed to be density-aware and perform well in networks		Trickle was designed to be density-aware and perform well in networks
	characterized by a wide range of node densities. The combination of		characterized by a wide range of node densities. The combination of
	DIO packet suppression and adaptive timers for sending updates allows		DIO packet suppression and adaptive timers for sending updates allows
	Trickle to perform well in both sparse and dense environments. Node		Trickle to perform well in both sparse and dense environments. Node
	densities in AMI deployments can vary greatly, from nodes having only		densities in AMI deployments can vary greatly, from nodes having only
	skipping to change at page 18, line 23		skipping to change at page 18, line 28
	deployment, the Trickle parameters are specified in terms of the		deployment, the Trickle parameters are specified in terms of the
	link's maximum capacity for transmitting link-local multicast		link's maximum capacity for transmitting link-local multicast
	messages. If the link can transmit m link-local multicast packets		messages. If the link can transmit m link-local multicast packets
	per second on average, the expected time it takes to transmit a link-		per second on average, the expected time it takes to transmit a link-
	local multicast packet is 1/m seconds.		local multicast packet is 1/m seconds.
	DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that		DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that
	the Trickle Imin is at least 50 times as long as it takes to		the Trickle Imin is at least 50 times as long as it takes to
	transmit a link-local multicast packet. This value is larger than		transmit a link-local multicast packet. This value is larger than
	that recommended in [RFC6206] to avoid congestion in dense urban		that recommended in [RFC6206] to avoid congestion in dense urban
	deployments as described above. In energy-constrained deployments		deployments as described above.
	(e.g., in water and gas battery-based routing infrastructure),
	DIOIntervalMin MAY be set to a value resulting in a Trickle Imin
	of several (e.g. 2) hours.
	DIOIntervalDoublings: AMI deployments SHOULD set		DIOIntervalDoublings: AMI deployments SHOULD set
	DIOIntervalDoublings such that the Trickle Imax is at least 2		DIOIntervalDoublings such that the Trickle Imax is at least 2
	hours or more. For very energy constrained deployments (e.g.,		hours or more.
	water and gas battery-based routing infrastructure),
	DIOIntervalDoublings MAY be set to a value resulting in a Trickle
	Imax of several (e.g., 2) days.
	DIORedundancyConstant: AMI deployments SHOULD set		DIORedundancyConstant: AMI deployments SHOULD set
	DIORedundancyConstant to a value of at least 10. This is due to		DIORedundancyConstant to a value of at least 10. This is due to
	the larger chosen value for DIOIntervalMin and the proportional		the larger chosen value for DIOIntervalMin and the proportional
	relationship between Imin and k suggested in [RFC6206]. This		relationship between Imin and k suggested in [RFC6206]. This
	increase is intended to compensate for the increased communication		increase is intended to compensate for the increased communication
	latency of DIO updates caused by the increase in the		latency of DIO updates caused by the increase in the
	DIOIntervalMin value, though the proportional relationship between		DIOIntervalMin value, though the proportional relationship between
	Imin and k suggested in [RFC6206] is not preserved. Instead,		Imin and k suggested in [RFC6206] is not preserved. Instead,
	DIORedundancyConstant is set to a lower value in order to reduce		DIORedundancyConstant is set to a lower value in order to reduce
	skipping to change at page 22, line 8		skipping to change at page 22, line 8
	802.15.4e, April 2012.		802.15.4e, April 2012.
	[IEEE1901.2]		[IEEE1901.2]
	"IEEE Standard for Low-Frequency (less than 500 kHz)		"IEEE Standard for Low-Frequency (less than 500 kHz)
	Narrowband Power Line Communications for Smart Grid		Narrowband Power Line Communications for Smart Grid
	Applications", IEEE Standard 1901.2, December 2013.		Applications", IEEE Standard 1901.2, December 2013.
	13.2. Normative references		13.2. Normative references
	[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,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,		[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
	"Routing Requirements for Urban Low-Power and Lossy		D. Barthel, Ed., "Routing Requirements for Urban Low-Power
	Networks", RFC 5548, May 2009.		and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
			2009, <http://www.rfc-editor.org/info/rfc5548>.
	[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,		[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", RFC 6206, March 2011.		"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
			March 2011, <http://www.rfc-editor.org/info/rfc6206>.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Lossy Networks", RFC 6550, March 2012.		Low-Power and Lossy Networks", RFC 6550,
			DOI 10.17487/RFC6550, March 2012,
			<http://www.rfc-editor.org/info/rfc6550>.
	[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.		[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
	Barthel, "Routing Metrics Used for Path Calculation in		and D. Barthel, "Routing Metrics Used for Path Calculation
	Low-Power and Lossy Networks", RFC 6551, March 2012.		in Low-Power and Lossy Networks", RFC 6551,
			DOI 10.17487/RFC6551, March 2012,
			<http://www.rfc-editor.org/info/rfc6551>.
	[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,		[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
	"Building Automation Routing Requirements in Low-Power and		"Building Automation Routing Requirements in Low-Power and
	Lossy Networks", RFC 5867, June 2010.		Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
			2010, <http://www.rfc-editor.org/info/rfc5867>.
	[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation		[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
	Routing Requirements in Low-Power and Lossy Networks", RFC		Routing Requirements in Low-Power and Lossy Networks",
	5826, April 2010.		RFC 5826, DOI 10.17487/RFC5826, April 2010,
			<http://www.rfc-editor.org/info/rfc5826>.
	[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,		[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
	"Industrial Routing Requirements in Low-Power and Lossy		Phinney, "Industrial Routing Requirements in Low-Power and
	Networks", RFC 5673, October 2009.		Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
			2009, <http://www.rfc-editor.org/info/rfc5673>.
	[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with		[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with
	Hysteresis Objective Function", RFC 6719, September 2012.		Hysteresis Objective Function", RFC 6719,
			DOI 10.17487/RFC6719, September 2012,
	[RFC6552] Thubert, P., "Objective Function Zero for the Routing		<http://www.rfc-editor.org/info/rfc6719>.
	Protocol for Low-Power and Lossy Networks (RPL)", RFC
	6552, March 2012.
	[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.		[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
	Martocci, "Reactive Discovery of Point-to-Point Routes in		Protocol for Low-Power and Lossy Networks (RPL)",
	Low-Power and Lossy Networks", RFC 6997, August 2013.		RFC 6552, DOI 10.17487/RFC6552, March 2012,
			<http://www.rfc-editor.org/info/rfc6552>.
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	September 2011.		DOI 10.17487/RFC6282, September 2011,
			<http://www.rfc-editor.org/info/rfc6282>.
	[I-D.ietf-roll-trickle-mcast]		[I-D.ietf-roll-trickle-mcast]
	Hui, J. and R. Kelsey, "Multicast Protocol for Low power		Hui, J. and R. Kelsey, "Multicast Protocol for Low power
	and Lossy Networks (MPL)", draft-ietf-roll-trickle-		and Lossy Networks (MPL)", draft-ietf-roll-trickle-
	mcast-11 (work in progress), November 2014.		mcast-12 (work in progress), June 2015.
	[I-D.ietf-roll-terminology]		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Vasseur, J., "Terms used in Routing for Low power And		Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
	Lossy Networks", draft-ietf-roll-terminology-13 (work in		2014, <http://www.rfc-editor.org/info/rfc7102>.
	progress), October 2013.
	[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,		[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
	and M. Richardson, "A Security Threat Analysis for the		and M. Richardson, Ed., "A Security Threat Analysis for
	Routing Protocol for Low-Power and Lossy Networks (RPLs)",		the Routing Protocol for Low-Power and Lossy Networks
	RFC 7416, January 2015.		(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
			<http://www.rfc-editor.org/info/rfc7416>.
			[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
			J. Martocci, "Reactive Discovery of Point-to-Point Routes
			in Low-Power and Lossy Networks", RFC 6997,
			DOI 10.17487/RFC6997, August 2013,
			<http://www.rfc-editor.org/info/rfc6997>.
	Authors' Addresses		Authors' Addresses
	Daniel Popa		Daniel Popa
	Itron, Inc		Itron, Inc
	52, rue Camille Desmoulins		52, rue Camille Desmoulins
	Issy les Moulineaux 92130		Issy les Moulineaux 92130
	FR		FR
	Email: daniel.popa@itron.com		Email: daniel.popa@itron.com
	skipping to change at page 24, line 4		skipping to change at page 24, line 19
	Email: matthew.gillmore@itron.com		Email: matthew.gillmore@itron.com
	Laurent Toutain		Laurent Toutain
	Telecom Bretagne		Telecom Bretagne
	2 rue de la Chataigneraie		2 rue de la Chataigneraie
	Cesson Sevigne 35510		Cesson Sevigne 35510
	FR		FR
	Email: laurent.toutain@telecom-bretagne.eu		Email: laurent.toutain@telecom-bretagne.eu
	Jonathan Hui		Jonathan Hui
	Cisco		Nest
	170 West Tasman Drive		3400 Hillview Ave
	San Jose, CA 95134		Palo Alto, CA 94304
	USA		USA
	Email: johui@cisco.com		Email: jonhui@nestlabs.com
	Ruben Salazar		Ruben Salazar
	Landys+Gyr		Landys+Gyr
	30000 Mill Creek Ave # 100		30000 Mill Creek Ave # 100
	Alpharetta, GA 30022		Alpharetta, GA 30022
	USA		USA
	Email: ruben.salazar@landisgyr.com		Email: ruben.salazar@landisgyr.com
	Kazuya Monden		Kazuya Monden
End of changes. 32 change blocks.
	69 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/