draft-iab-smart-object-workshop-00.txt   draft-iab-smart-object-workshop-01.txt 
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational J. Arkko Intended status: Informational J. Arkko
Expires: January 5, 2012 Ericsson Expires: January 12, 2012 Ericsson
July 4, 2011 July 11, 2011
Report from the 'Interconnecting Smart Objects with the Internet' Report from the 'Interconnecting Smart Objects with the Internet'
Workshop, 25th March 2011, Prague Workshop, 25th March 2011, Prague
draft-iab-smart-object-workshop-00.txt draft-iab-smart-object-workshop-01.txt
Abstract Abstract
This document provides an overview of a workshop held by the Internet This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on 'Interconnecting Smart Objects with the Architecture Board (IAB) on 'Interconnecting Smart Objects with the
Internet'. The workshop took place in Prague on March, 25th. The Internet'. The workshop took place in Prague on March, 25th. The
main goal of the workshop was to solicit feedback from the wider main goal of the workshop was to solicit feedback from the wider
community on their experience with deploying IETF protocols in community on their experience with deploying IETF protocols in
constrained environments. This report summarizes the discussions and constrained environments. This report summarizes the discussions and
lists the conclusions and recommendations to the Internet Engineering lists the conclusions and recommendations to the Internet Engineering
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 5, 2012. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 4, line 35 skipping to change at page 4, line 35
o Interworking between different technologies and network domains o Interworking between different technologies and network domains
o Usability and manageability o Usability and manageability
o Security and Privacy o Security and Privacy
The goals of the workshop can be summarized as follows: The goals of the workshop can be summarized as follows:
As many deployed smart objects demonstrate running protocols, like As many deployed smart objects demonstrate running protocols, like
IP, TCP, UDP, HTTP, etc. on constrained devices is clearly is IP, TCP, UDP, HTTP, etc., on constrained devices is clearly is
possible. Still, protocol designers, system architects and possible. Still, protocol designers, system architects and
developers have to keep various limitations in mind. The developers have to keep various limitations in mind. The
organizers were interested to discuss the experience with organizers were interested to discuss the experience with
deploying IETF protocols in different constrained environments. deploying IETF protocols in different constrained environments.
Furthermore, the organizers were seeking to identify either issues Furthermore, the organizers were seeking to identify either issues
where current implementers do not yet have solutions or where where current implementers do not yet have solutions or where
researchers predict potential issues. researchers predict potential issues.
The workshop served as a venue to identify problems and to The workshop served as a venue to identify problems and to
skipping to change at page 8, line 49 skipping to change at page 8, line 49
Cullen Jennings compared the current state of smart object deployment Cullen Jennings compared the current state of smart object deployment
with the evolution of voice-over-IP: "Initially, many vendors with the evolution of voice-over-IP: "Initially, many vendors
recommended to run VoIP over a separate VLAN or a separate recommended to run VoIP over a separate VLAN or a separate
infrastructure. Nobody could imagine how to make the type of real- infrastructure. Nobody could imagine how to make the type of real-
time guarantees, how to debug it, and how to get it to work because time guarantees, how to debug it, and how to get it to work because
the Internet is not ideally suited for making any types of guarantees the Internet is not ideally suited for making any types of guarantees
for real-time systems. As time went on people got better at making for real-time systems. As time went on people got better at making
voice work across that type of IP network. They suddenly noticed voice work across that type of IP network. They suddenly noticed
that having voice running on a separate virtual network than their that having voice running on a separate virtual network than their
other applications was a disaster. They couldn't decide if a PC is other applications was a disaster. They couldn't decide if a PC was
running a softphone and whether it went on a voice or a data network. running a softphone and whether it went on a voice or a data network.
At that point people realized that they needed a converged network At that point people realized that they needed a converged network
and all moved to one. I wouldn't be surprised to see the same and all moved to one. I wouldn't be surprised to see the same
happens here. Initially, we will see very separated networks. Then, happens here. Initially, we will see very separated networks. Then,
those will be running over the same hardware to take advantage of the those will be running over the same hardware to take advantage of the
cost benefits of not having to deploy multiple sets of wires around cost benefits of not having to deploy multiple sets of wires around
buildings. Over time there will be strong needs to directly buildings. Over time there will be strong needs to directly
communicate with each other. We need to be designing the system for communicate with each other. We need to be designing the system for
the long run. Assuming everything will end up on the same network the long run. Assuming everything will end up on the same network
even if you initially plan to run it in separate networks." even if you initially plan to run it in separate networks."
skipping to change at page 9, line 35 skipping to change at page 9, line 35
3.1.2. Domain Specific Stacks and Profiles 3.1.2. Domain Specific Stacks and Profiles
Imagine a home network scenario where a new light bulb is installed Imagine a home network scenario where a new light bulb is installed
that should, out of the box without further configuration, that should, out of the box without further configuration,
interoperate with the already present light switch from a different interoperate with the already present light switch from a different
vendor in the room. For many this is the desired level of vendor in the room. For many this is the desired level of
interoperability in the area of smart object design. To accomplish interoperability in the area of smart object design. To accomplish
this level of interoperability it is not sufficient to provide this level of interoperability it is not sufficient to provide
interoperability only at the network layer. Even running the same interoperability only at the network layer. Even running the same
transport and application layer protocols is insufficient since both transport protocol (e.g., TCP) and application layer protocol (e.g.,
devices need to understand the semantics of the protocol HTTP) is insufficient since both devices need to understand the
communication for "Turn the light on" as well. semantics of the payloads for "Turn the light on" as well.
Standardizing the entire protocol stack for this specific "light Standardizing the entire protocol stack for this specific "light
switch/light bulb" scenario is possible. A possible stack would, for switch/light bulb" scenario is possible. A possible stack would, for
example, use IPv6 with a specific address configuration mechanism example, use IPv6 with a specific address configuration mechanism
(such as stateless address autoconfiguration), a network access (such as stateless address autoconfiguration), a network access
authentication security mechanism such as PANA, a service discovery authentication security mechanism such as PANA, a service discovery
mechanism (multicast DNS with DNS-SD), an application layer protocol, mechanism (multicast DNS with DNS-SD), an application layer protocol,
for example, Constrained Application Protocol (CoAP) (which uses for example, Constrained Application Protocol (CoAP) (which uses
UDP), and the syntax and semantic for the light on/off functionality. UDP), and the syntax and semantic for the light on/off functionality.
skipping to change at page 12, line 41 skipping to change at page 12, line 41
we send an IP packet, we run neighbor discovery, we cannot keep we send an IP packet, we run neighbor discovery, we cannot keep
neighbor discovery for 15 minutes and so when a node wakes up again neighbor discovery for 15 minutes and so when a node wakes up again
it essentially has to re-do it to refresh the cache, we want to run it essentially has to re-do it to refresh the cache, we want to run
Detecting Network Attachment (DNA) procedures to check that hosts are Detecting Network Attachment (DNA) procedures to check that hosts are
on the same network either by re-getting an address using the Dynamic on the same network either by re-getting an address using the Dynamic
Host Configuration Protocol (DHCP) or by noticing that the node is Host Configuration Protocol (DHCP) or by noticing that the node is
using the same default gateway because of a received Router using the same default gateway because of a received Router
Advertisement (RA). Essentially, a number of steps have to be taken Advertisement (RA). Essentially, a number of steps have to be taken
before sending a packet. before sending a packet.
However, these protocols do not work well, at all, when the cost of However, these protocols do not work well, if at all, when the cost
sending/receiving those messages are high (in terms of bandwidth or of sending/receiving those messages is high (in terms of bandwidth or
battery life) or in cases where nodes sleep periodically and are not battery life) or in cases where nodes sleep periodically and are not
persistently available to receive those messages. A number of issue persistently available to receive those messages. A number of issue
arise from these almost-always-off nodes. arise from these almost-always-off nodes.
Also a lot of our protocols are getting more chatty. Keeping the Also a lot of our protocols are getting more chatty. Keeping the
receiver up for an additional roundtrip costs extra energy. Protocol receiver up for an additional roundtrip costs extra energy. Protocol
messages can also be lengthy, e.g., many protocols carry XML-based messages can also be lengthy, e.g., many protocols carry XML-based
payloads. payloads.
There are a couple of ways to think about how to make the situation There are a couple of ways to think about how to make the situation
skipping to change at page 13, line 44 skipping to change at page 13, line 44
Some protocols involve multiple roundtrips and/or lengthy Some protocols involve multiple roundtrips and/or lengthy
messages. As a result, low-powered nodes have to use more power messages. As a result, low-powered nodes have to use more power
in sending messages and have to stay powered on for a longer in sending messages and have to stay powered on for a longer
period of time as they wait for the protocol exchanges to period of time as they wait for the protocol exchanges to
complete. The best way to address these problems is to ensure complete. The best way to address these problems is to ensure
that the simplest possible protocol exchanges are used when the that the simplest possible protocol exchanges are used when the
protocols in question are designed. However, in some cases protocols in question are designed. However, in some cases
alternative encoding formats and compression may also help. alternative encoding formats and compression may also help.
A number of protocol could be considered in such an investigation.
The main focus of past investigations has so far been on IPv6 and ND.
One can argue that certain features are not useful in an environment One can argue that certain features are not useful in an environment
where most nodes are sleeping, such as duplicate address detection. where most nodes are sleeping. The main focus of past investigations
Other protocols to investigate would be DNS, and DHCP. has been on IPv6 and ND but other protocols do also deserve a deeper
investigation, such as DNS, and DHCP.
During the protocol design phase certain protocols were assumed to be During the protocol design phase certain protocols were assumed to be
used in a human-to-device context and therefore it was argued that used in a human-to-device context and therefore it was argued that
the verbose encoding is helpful. Examples are the Hypertext Transfer the verbose encoding is helpful. Examples are the Hypertext Transfer
Protocol (HTTP), the Session Initiation Protocol (SIP), and Protocol (HTTP), the Session Initiation Protocol (SIP), and
Extensible Messaging and Presence Protocol (XMPP). Nowadays these Extensible Messaging and Presence Protocol (XMPP). Nowadays these
protocols are also being considered and used in device-to-device protocols are also being considered and used in device-to-device
communication and the verbose nature is not helpful. communication and the verbose nature is not helpful.
While the principles seem to be most useful for low-power, battery While the principles seem to be most useful for low-power, battery
skipping to change at page 14, line 28 skipping to change at page 14, line 27
therefore one has to consider the overall energy consumption of the therefore one has to consider the overall energy consumption of the
entire solution. This is not always an easy question to answer. entire solution. This is not always an easy question to answer.
IEEE 802.11 nodes, for example, use a lot of power if they cannot be IEEE 802.11 nodes, for example, use a lot of power if they cannot be
made to sleep most of the time. A light bulb may use less power but made to sleep most of the time. A light bulb may use less power but
there is also the device that controls the bulb that may consume a there is also the device that controls the bulb that may consume a
lot of energy all the time. In total, more energy may be consumed lot of energy all the time. In total, more energy may be consumed
when considering these two devices together. when considering these two devices together.
3.3. Security 3.3. Security
In the development of a smart object application security, as with In the development of a smart object applications, as with any other
any other protocol application solution, has to be considered early protocol application solution, security has to be considered early in
in the design process. As such, the recommendations currently the design process. As such, the recommendations currently provided
provided by IETF protocol architects, such as RFC 3552 [RFC3552], RFC to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101
4101 [RFC4101], and other recommendations, apply also to the smart [RFC4101], apply also to the smart object space.
object space.
While there are additional constraints, as described in Section 2, While there are additional constraints, as described in Section 2,
security has to be a mandatory part of the solution. The hope is security has to be a mandatory part of the solution. The hope is
that this will lead to implementations that provide security that this will lead to implementations that provide security
features, deployments that utilize these, and finally that this leads features, deployments that utilize these, and finally that this leads
to use of better security mechanisms. It is important to point out to use of better security mechanisms. It is important to point out
that the lack of direct user interaction will place hard requirements that the lack of direct user interaction will place hard requirements
on deployment models, configuration mechanisms, and software upgrade/ on deployment models, configuration mechanisms, and software upgrade/
crypto agility mechanisms. crypto agility mechanisms.
Since many of the security mechanism allow for customization, Since many of the security mechanisms allow for customization,
particularly with regard to the cryptographic primitives utilized, particularly with regard to the cryptographic primitives utilized,
many believe that IETF security solutions are usable without many believe that IETF security solutions are usable without
modifications in a large part of the smart object domain. Others modifications in a large part of the smart object domain. Others
call for new work on cryptographic primitives that make use of a call for new work on cryptographic primitives that make use of a
single primitive (such as the Advanced Encryption Standard (AES)) as single primitive (such as the Advanced Encryption Standard (AES)) as
a building block for all cryptographic functions with the benefit of a building block for all cryptographic functions with the benefit of
a smaller footprint of the overall solution. Specifically the a smaller footprint of the overall solution. Specifically the
different hardware limitations (e.g., the hardware architecture of different hardware limitations (e.g., the hardware architecture of
certain embedded devices prevents pipelining to be utilized). In the certain embedded devices prevents pipelining to be utilized). In the
excitement for new work on optimizations of cryptograhpic primitives excitement for new work on optimizations of cryptograhpic primitives
other factors have to be taken into consideration that influence other factors have to be taken into consideration that influence
successful deployment, such as widespread ability in libraries, as successful deployment, such as widespread support in libraries, as
well as intellectual property rights (IPR). As an example of the well as intellectual property rights (IPR). As an example of the
latter aspect the struggle of Elliptic Curve Cryptography (ECC)-based latter aspect the struggle of Elliptic Curve Cryptography (ECC)-based
cryptographic algorithms to find deployment can partially be cryptographic algorithms to find deployment can partially be
attributed to the IPR situation. The reuse of libraries providing attributed to the IPR situation. The reuse of libraries providing
cryptographic functions is clearly an important way to use available cryptographic functions is clearly an important way to use available
memory resources in a more efficient way. To deal with the memory resources in a more efficient way. To deal with the
performance and footprint concerns investigations into offloading performance and footprint concerns investigations into offloading
certain resource-hungry functions to parties that possess more certain resource-hungry functions to parties that possess more
cryptographic power have been considered. For example, the ability cryptographic power have been considered. For example, the ability
to delegate certificate validation to servers has been standardized to delegate certificate validation to servers has been standardized
skipping to change at page 16, line 18 skipping to change at page 16, line 16
and none in the link layer. Each physical hop appears as a single IP and none in the link layer. Each physical hop appears as a single IP
hop (ignoring devices that just extend the physical range of hop (ignoring devices that just extend the physical range of
signaling, such as repeaters). Routing in this context means running signaling, such as repeaters). Routing in this context means running
a routing protocol. IPv6 Routing Protocol for Low power and Lossy a routing protocol. IPv6 Routing Protocol for Low power and Lossy
Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the
route-over category. route-over category.
From an architectural point of view there are several questions that From an architectural point of view there are several questions that
arise from where routing is provided, for example: arise from where routing is provided, for example:
o Protocols often assume that link characteristics are deterministic o Protocols often assume that link characteristics are predictable
when communicating with any device attached to the same link. when communicating with any device attached to the same link.
Latency, throughput, and reliability may vary considerably between Latency, throughput, and reliability may vary considerably between
different devices that are multiple link layer hops away. What different devices that are multiple link layer hops away. What
timeout should be used? What happens if a device is unreachable? timeout should be used? What happens if a device is unreachable?
In case of default router selection two advertised routers may be In case of default router selection two advertised routers may be
a different number of hops away. Should a device have visibility a different number of hops away. Should a device have visibility
into the path to make a decision and what path characteristics into the path to make a decision and what path characteristics
would be useful to have? would be useful to have?
o Scoped message delivery to a neighboring IP hop (via link-local o Scoped message delivery to a neighboring IP hop (via link-local
skipping to change at page 17, line 8 skipping to change at page 17, line 6
vs. route-over approach will have to be decided and further decisions vs. route-over approach will have to be decided and further decisions
will have to be made about the choice of a specific routing protocol. will have to be made about the choice of a specific routing protocol.
In 2008 the IETF formed the Routing Over Low power and Lossy networks In 2008 the IETF formed the Routing Over Low power and Lossy networks
(ROLL) working group to specify a routing solution for smart object (ROLL) working group to specify a routing solution for smart object
environments. During its first year of existence, the working group environments. During its first year of existence, the working group
studied routing requirements in details (see [RFC5867], [RFC5826], studied routing requirements in details (see [RFC5867], [RFC5826],
[RFC5673], [RFC5548]), published a protocol survey looking at a [RFC5673], [RFC5548]), published a protocol survey looking at a
number of existing routing protocols number of existing routing protocols
[I-D.ietf-roll-protocols-survey], including Ad hoc On-Demand Distance [I-D.ietf-roll-protocols-survey], including Ad hoc On-Demand Distance
Vector (AODV)-style of protocols. The ROLL WG concluded that a new Vector (AODV)-style of protocols [RFC3561]. The ROLL WG concluded
routing protocol satisfying the documented requirements has to be that a new routing protocol satisfying the documented requirements
developed and the work on the RPL was started, as the IETF routing has to be developed and the work on the RPL was started, as the IETF
protocol for smart object networks. Nevertheless, controversial routing protocol for smart object networks. Nevertheless,
discussions at the workshop about which routing protocols is best in controversial discussions at the workshop about which routing
a given environment are still ongoing. Thomas Clausen, for example, protocols is best in a given environment are still ongoing. Thomas
argued for using an AODV-like [RFC3561] routing protocol in Clausen, for example, argued for using an AODV-like routing protocol
[Clausen]. in [Clausen].
4. Conclusions and Next Steps 4. Conclusions and Next Steps
The workshop allowed the participants to get exposed to interesting The workshop allowed the participants to get exposed to interesting
applications and their requirements (buildings, fountains, theater, applications and their requirements (buildings, fountains, theater,
etc.), to have discussions about radically different architectures etc.), to have discussions about radically different architectures
and their issues (e.g., information centric networking), to look at and their issues (e.g., information centric networking), to look at
existing technology from a new angle (sleep nodes, energy existing technology from a new angle (sleep nodes, energy
consumption), to focus on some details of the protocol stack consumption), to focus on some details of the protocol stack
(neighbour discovery, security, routing) and to implementation (neighbour discovery, security, routing) and to implementation
skipping to change at page 18, line 33 skipping to change at page 18, line 33
A discussion of security is provided in Section 3.3. In general, A discussion of security is provided in Section 3.3. In general,
security related protocol exchanges and the required amount of security related protocol exchanges and the required amount of
computational resource requirements can contribute significantly computational resource requirements can contribute significantly
to the overall processing. Therefore, it remains a challenge how to the overall processing. Therefore, it remains a challenge how
to accomplish performance improvements without sacrifying the to accomplish performance improvements without sacrifying the
overall security level taking the usability of the entire system overall security level taking the usability of the entire system
into consideration. into consideration.
Another challenge is how to balance the security and performance Another challenge is how to balance the security and performance
needs of challenged nodes with the interoperability requirements needs of smart objects with the interoperability requirements of
of hosts on the Internet since different suites of algorithms may hosts on the Internet since different suites of algorithms may
tend to be chosen for these different environments. This involves tend to be chosen for these different environments. This involves
trade-offs between performance on the challenged nodes versus end- trade-offs between performance on the smart objects versus end-to-
to-end security. Solutions that mandate a "trusted" middlebox end security. Solutions that mandate a "trusted" middlebox whose
whose only role is to terminate security associations tend to be only role is to terminate security associations tend to be frowned
frowned upon from the security perspective, especially since end- upon from the security perspective, especially since end-users of
users of challenged devices (where those exist) are unlikely to challenged devices (where those exist) are unlikely to understand
understand the security consequences of such middleboxes. the security consequences of such middleboxes.
The discussion concluded with the following recommendations: The discussion concluded with the following recommendations:
* Investigate usability in cryptographic protocol design with * Investigate usability in cryptographic protocol design with
regard to credential management. As an example, the Bluetooth regard to credential management. As an example, the Bluetooth
pairing mechanism was mentioned as a simple and yet reasonably pairing mechanism was mentioned as a simple and yet reasonably
secure method of introducing devices into a new environment. secure method of introducing devices into a new environment.
In fact, the IETF working group 'Credential and Provisioning In fact, the IETF working group 'Credential and Provisioning
(ENROLL)' working group was established years ago to deal with (ENROLL)' working group was established years ago to deal with
this topic but was terminated prematurely due to lack of this topic but was terminated prematurely due to lack of
progress. The email archives still exists and is available progress. The email archive still exists and is available
[enroll] and may provide useful historical information. [enroll] and may provide useful historical information.
* Standardized authentication and key exchange mechanisms should * Standardized authentication and key exchange mechanisms should
be surveyed for suitability in smart object environments with be surveyed for suitability in smart object environments with
respect to message size, computational performance, number of respect to message size, computational performance, number of
messages, codesize, and main memory requirements. A starting messages, codesize, and main memory requirements. A starting
point of such an investigation (in case of IKEv2) was provided point of such an investigation (in case of IKEv2) was provided
by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a
suitable venue for discussion could be the recently established suitable venue for discussion could be the recently established
skipping to change at page 19, line 26 skipping to change at page 19, line 26
* Research has to be done in the area of lightweight * Research has to be done in the area of lightweight
cryptographic primitives, namely block ciphers, stream ciphers, cryptographic primitives, namely block ciphers, stream ciphers,
and cryptographic hash functions. Worthwhile to mention is and cryptographic hash functions. Worthwhile to mention is
early work with the National Institute of Standards and early work with the National Institute of Standards and
Technology (NIST) new cryptographic hash algorithm 'SHA-3' Technology (NIST) new cryptographic hash algorithm 'SHA-3'
competition. A suitable forum for discussion is the IRTF competition. A suitable forum for discussion is the IRTF
Crypto Forum Research Group (CFRG) [CFRG]. Crypto Forum Research Group (CFRG) [CFRG].
The difficulty and impact of choosing specialised algorithms for The difficulty and impact of choosing specialised algorithms for
challenged nodes should not be underestimated. Issues that arise smart objects should not be underestimated. Issues that arise
include the additional specification complexity (e.g., TLS already include the additional specification complexity (e.g., TLS already
has 100's of ciphersuites defined, most of which are unused in has 100's of ciphersuites defined, most of which are unused in
practice), the long latency in terms of roll out (many hosts are practice), the long latency in terms of roll out (many hosts are
still using deprecated algorithms 5-10 years after those still using deprecated algorithms 5-10 years after those
algorithms were deprecated) and the barriers that IPR-encumbered algorithms were deprecated) and the barriers that IPR-encumbered
schemes present to widespread deployment. While research on this schemes present to widespread deployment. While research on this
topic within CFRG and the cryptographic research community is a topic within CFRG and the cryptographic research community is a
very worthwhile goal, any such algorithms will likely have to very worthwhile goal, any such algorithms will likely have to
offer very significant benefits before they will be broadly offer very significant benefits before they will be broadly
adopted. 20% less CPU is unlikely to be a winning argument no adopted. 20% less CPU is unlikely to be a winning argument no
skipping to change at page 20, line 44 skipping to change at page 20, line 44
[I-D.ietf-core-coap], the question of congestion control mechanism [I-D.ietf-core-coap], the question of congestion control mechanism
should be used at the underlying transport protocol or by the should be used at the underlying transport protocol or by the
application protocol itself. [I-D.eggert-core-congestion-control] application protocol itself. [I-D.eggert-core-congestion-control]
is a starting point for the CoAP protocol but further work is is a starting point for the CoAP protocol but further work is
needed. needed.
Data Models: Data Models:
Standardization of application layer protocols is important but Standardization of application layer protocols is important but
does not ensure that, for example, a light switch and a light bulb does not ensure that, for example, a light switch and a light bulb
are able to interact with each other. One are where participants are able to interact with each other. One area where participants
saw the need for further work was in the area of data models. saw the need for further work was in the area of data models.
While prior IETF standardization work on, for example, location While prior IETF standardization work on, for example, location
[GEOPRIV] can be re-used the question was raised where the IETF [GEOPRIV] can be re-used the question was raised where the IETF
should focus their standardization efforts on since domain should focus their standardization efforts on since domain
expertise in each area will be needed. As potential example expertise in each area will be needed. As potential example
energy pricing was discussed, with an example provided by energy pricing was discussed, with an example provided by
[I-D.jennings-energy-pricing]. [I-D.jennings-energy-pricing].
Discovery: Discovery:
skipping to change at page 23, line 11 skipping to change at page 23, line 11
As described in this report part of the agenda was focused on the As described in this report part of the agenda was focused on the
discussion of security, see Section 3.3. discussion of security, see Section 3.3.
6. Acknowledgements 6. Acknowledgements
We would like to thank all the participants for their position We would like to thank all the participants for their position
papers. The authors of the position papers were invited to the papers. The authors of the position papers were invited to the
workshop. workshop.
Big thanks to Elwyn Davies for helping us to fix language bugs. Big thanks to Elwyn Davies for helping us to fix language bugs. We
would also like to thank Andrei Robachevsky for his review comments.
Additionally, we would like to thank Ericsson and Nokia Siemens Additionally, we would like to thank Ericsson and Nokia Siemens
Networks for their financial support. Networks for their financial support.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Informative References 8. Informative References
skipping to change at page 26, line 5 skipping to change at page 26, line 5
[I-D.hamid-6lowpan-snmp-optimizations] [I-D.hamid-6lowpan-snmp-optimizations]
Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP
Optimizations for Constrained Devices", Optimizations for Constrained Devices",
draft-hamid-6lowpan-snmp-optimizations-03 (work in draft-hamid-6lowpan-snmp-optimizations-03 (work in
progress), October 2010. progress), October 2010.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-06 (work in progress), May 2011. draft-ietf-core-coap-07 (work in progress), July 2011.
[I-D.ietf-roll-protocols-survey] [I-D.ietf-roll-protocols-survey]
Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview
of Existing Routing Protocols for Low Power and Lossy of Existing Routing Protocols for Low Power and Lossy
Networks", draft-ietf-roll-protocols-survey-07 (work in Networks", draft-ietf-roll-protocols-survey-07 (work in
progress), April 2009. progress), April 2009.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.jennings-energy-pricing] [I-D.jennings-energy-pricing]
Jennings, C., "Communication of Energy Pricing Jennings, C. and B. Nordman, "Communication of Energy
Information", draft-jennings-energy-pricing-00 (work in Price Information", draft-jennings-energy-pricing-01 (work
progress), March 2011. in progress), July 2011.
[I-D.kivinen-ipsecme-ikev2-minimal] [I-D.kivinen-ipsecme-ikev2-minimal]
Kivinen, T., "Minimal IKEv2", Kivinen, T., "Minimal IKEv2",
draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress),
February 2011. February 2011.
[I-D.routing-architecture-iot] [I-D.routing-architecture-iot]
Hui, J. and J. Vasseur, "Routing Architecture in Low-Power Hui, J. and J. Vasseur, "Routing Architecture in Low-Power
and Lossy Networks (LLNs)", and Lossy Networks (LLNs)",
draft-routing-architecture-iot-00 (work in progress), draft-routing-architecture-iot-00 (work in progress),
 End of changes. 22 change blocks. 
48 lines changed or deleted 47 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/