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/