draft-iab-smart-object-workshop-06.txt   draft-iab-smart-object-workshop-07.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: April 28, 2012 Ericsson Expires: June 30, 2012 Ericsson
October 26, 2011 December 28, 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-06.txt draft-iab-smart-object-workshop-07.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
Task Force (IETF) community. Task Force (IETF) community.
Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.
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.
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 April 28, 2012. This Internet-Draft will expire on June 30, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 6 2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 5
3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 8 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 8 3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 7
3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 9 3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 8
3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 9
3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18 4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Informative References . . . . . . . . . . . . . . . . . . . . 25 8. Informative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29
Appendix B. Published Workshop Material . . . . . . . . . . . . . 30 Appendix B. Published Workshop Material . . . . . . . . . . . . . 30
Appendix C. Workshop Participants . . . . . . . . . . . . . . . . 35 Appendix C. Workshop Participants . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The Internet Architecture Board (IAB) holds occasional workshops The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet Internet, and to suggest future directions for the Internet
skipping to change at page 3, line 39 skipping to change at page 3, line 39
humans, but exist as components in buildings, vehicles, and the humans, but exist as components in buildings, vehicles, and the
environment. There is a large variation in the computing power, environment. There is a large variation in the computing power,
available memory, (electrical) power, and communications bandwidth available memory, (electrical) power, and communications bandwidth
between different types of devices. between different types of devices.
Many of these devices offer a range of new possibilities or provide Many of these devices offer a range of new possibilities or provide
additional value for previously unconnected devices. Some devices additional value for previously unconnected devices. Some devices
have been connected using proprietary communication networks in the have been connected using proprietary communication networks in the
past but are now migrating to the use of the Internet Protocol suite past but are now migrating to the use of the Internet Protocol suite
in order to share the same communication network between all in order to share the same communication network between all
applications and enabling rich communications services. applications and to enable rich communications services.
Much of this development can simply run on existing Internet Much of this development can simply run on existing Internet
protocols. For instance, home entertainment and monitoring systems protocols. For instance, home entertainment and monitoring systems
often offer a web interface to the end user. In many cases the new, often offer a web interface to the end user. In many cases the new,
constrained environments can benefit from additional protocols and constrained environments can benefit from additional protocols and
protocol extensions that help optimize the communications and lower protocol extensions that help optimize the communications and lower
the computational requirements. Examples of currently ongoing the computational requirements. Examples of currently ongoing
standardization efforts targeted for these environments include the standardization efforts targeted for these environments include the
"Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN
(6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and
the "Light-Weight Implementation Guidance (LWIG)" working groups at the "Light-Weight Implementation Guidance (LWIG)" working groups at
the IETF. the IETF.
This workshop explored the experiences of researchers and developers This workshop explored the experiences of researchers and developers
when considering the characteristics of constrained devices. when considering the characteristics of constrained devices.
Engineers know that many design considerations need to be taken into Engineers know that many design considerations need to be taken into
account when developing protocols and architecture. Balancing account when developing protocols and architecture. Balancing
between the conflicting goals of code size, economic incentives, between the conflicting goals of code size, economic incentives,
power consumption, usability and security is often difficult, as power consumption, usability and security is often difficult, as
illustrated by Clark, et al. in "Tussle in Cyberspace: Defining illustrated by Clark, et al. in "Tussle in Cyberspace: Defining
Tomorrow's Internet". Tomorrow's Internet" [Tussle].
Participants at the workshop discussed the experience and approaches Participants at the workshop discussed the experience and approaches
taken when designing protocols and architectures for interconnecting taken when designing protocols and architectures for interconnecting
smart objects to the Internet. The scope of the investigations smart objects to the Internet. The scope of the investigations
included constrained nodes as well as constrained networks. included constrained nodes as well as constrained networks.
The call for position papers suggested investigating the area of The call for position papers suggested investigating the area of
integration with the Internet in the following categories: integration with the Internet in the following categories:
o Scalability o Scalability
skipping to change at page 4, line 50 skipping to change at page 5, line 5
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
discover common interests that may turn into new work or into discover common interests that may turn into new work or into
changes in direction of already ongoing work at the IETF and or changes in direction of already ongoing work at the IETF and or
the Internet Research Task Force (IRTF). the Internet Research Task Force (IRTF).
Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.
2. Constrained Nodes and Networks 2. Constrained Nodes and Networks
The workshop was spurred by the increasing presence of constrained The workshop was spurred by the increasing presence of constrained
devices on the network. It is quite natural to ask how these devices on the network. It is quite natural to ask how these
limitations impact the design of the affected nodes. Note that not limitations impact the design of the affected nodes. Note that not
all nodes suffer from the same set of limitations. all nodes suffer from the same set of limitations.
Energy constraints: Energy constraints:
Since wireless communication can be a large portion of the power- Since wireless communication can be a large portion of the power-
skipping to change at page 6, line 36 skipping to change at page 5, line 36
Various low power radio networks offer only ~100 kbit/s or even Various low power radio networks offer only ~100 kbit/s or even
only a few KBits/s, and show high packet loss as well as high link only a few KBits/s, and show high packet loss as well as high link
quality variability. Nodes may be used in usually highly unstable quality variability. Nodes may be used in usually highly unstable
radio environments. The physical layer packet size may be limited radio environments. The physical layer packet size may be limited
(~100 bytes). (~100 bytes).
Memory constraints: Memory constraints:
The amount of volatile and persistent storage impacts the program The amount of volatile and persistent storage impacts the program
executtion has important implications for the functionality of the execution has important implications for the functionality of the
protocol stack. The Arduino UNO board, for example, provides a protocol stack. The Arduino UNO board, for example, provides a
developer with 2 KByte RAM and 32 KByte flash memory (without any developer with 2 KByte RAM and 32 KByte flash memory (without any
extensions, such as microSD cards). extensions, such as microSD cards).
A system designer also needs to consider CPU constraints, which often A system designer also needs to consider CPU constraints, which often
relate to energy constraints: a processor with lower performance relate to energy constraints: a processor with lower performance
consumes less energy. As described later in this document, the consumes less energy. As described later in this document, the
design of the mainboard may allow certain components to be put to design of the mainboard may allow certain components to be put to
sleep to further lower energy consumption. In general, embedded sleep to further lower energy consumption. In general, embedded
systems are often purpose built with only the hardware components systems are often purpose built with only the hardware components
skipping to change at page 8, line 35 skipping to change at page 7, line 35
3.1.1. One Internet vs. Islands 3.1.1. One Internet vs. Islands
Devices that used to be in proprietary or application-specific Devices that used to be in proprietary or application-specific
networks are today migrating to IP networks. There is, however, the networks are today migrating to IP networks. There is, however, the
question of whether these smart objects are now on the same IP question of whether these smart objects are now on the same IP
network as any other application. Controlled applications, like the network as any other application. Controlled applications, like the
fountains in front of the Bellagio hotel in Las Vegas that are fountains in front of the Bellagio hotel in Las Vegas that are
operated as a distributed control system [Dolin], probably are not operated as a distributed control system [Dolin], probably are not
exchanging their control messages over the same network that is also exchanging their control messages over the same network that is also
used by hotel guests for their Internet traffic. The same had been used by hotel guests for their Internet traffic. The same had been
argued for the smart grid. The question that was raised during the argued for smart grids [SmartGrid]. The question that was raised
workshop is therefore in what sense are we talking about one Internet during the workshop is therefore in what sense are we talking about
or about using IP technology for a separate, walled garden network one Internet or about using IP technology for a separate, walled
that is independent of the Internet? garden network that is independent of the Internet?
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
skipping to change at page 9, line 43 skipping to change at page 8, line 43
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 protocol (e.g., TCP) and application layer protocol (e.g., transport protocol (e.g., TCP) and application layer protocol (e.g.,
HTTP) is insufficient since both devices need to understand the HTTP) is insufficient since both devices need to understand the
semantics of the payloads 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 Protocol for carrying
mechanism (multicast DNS with DNS-SD), an application layer protocol, Authentication for Network Access (PANA) [RFC5191], a service
for example, Constrained Application Protocol (CoAP) (which uses discovery mechanism (e.g., multicast DNS with DNS-SD
UDP), and the syntax and semantic for the light on/off functionality. [I-D.cheshire-dnsext-dns-sd]), an application layer protocol, for
example, Constrained Application Protocol (CoAP) [I-D.ietf-core-coap]
(which uses UDP), and the syntax and semantic for the light on/off
functionality.
As this list shows there is already some amount of protocol As this list shows there is already some amount of protocol
functionality that has to be agreed on by various stakeholders to functionality that has to be agreed on by various stakeholders to
make this scenario work seamlessly. As we approach more complex make this scenario work seamlessly. As we approach more complex
protocol interactions the functionality quickly becomes more complex: protocol interactions the functionality quickly becomes more complex:
IPv4 and IPv6 on the network layer, various options at the transport IPv4 and IPv6 on the network layer, various options at the transport
layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices
at the application layer with respect to communication protocols, at the application layer with respect to communication protocols,
data formats and data models. Different requirements have led to the data formats and data models. Different requirements have led to the
development of a variety of communication protocols: client-server development of a variety of communication protocols: client-server
protocols in the style of the original HTTP, publish-subscribe protocols in the style of the original HTTP, publish-subscribe
protocols (like SIP or XMPP), store-and-forward messaging (borrowed protocols (like Session Initiation Protocol (SIP) [RFC3261] or
from the delay tolerant networking community). Along with the Extensible Messaging and Presence Protocol (XMPP) [RFC3921]), store-
different application layer communication protocols come various and-forward messaging (borrowed from the delay tolerant networking
identity and security mechanisms. community). Along with the different application layer communication
protocols come various identity and security mechanisms.
With the smart object constraints it feels natural to develop these With the smart object constraints it feels natural to develop these
stacks since each application domain (e.g., health-care, smart grids, stacks since each application domain (e.g., health-care, smart grids,
building networking) will have their unique requirements and their building networking) will have their unique requirements and their
own community involved in the design process. How likely are these own community involved in the design process. How likely are these
profiles going to be the right match for the future, specifically for profiles going to be the right match for the future, specifically for
the new innovations that will come? How many of these stacks are we the new innovations that will come? How many of these stacks are we
going to have? Will the differences in the profiles purely be the going to have? Will the differences in the profiles purely be the
result of different requirements coming from the individual result of different requirements coming from the individual
application domains or will these mismatches reflect the spirit, application domains or will these mismatches reflect the spirit,
skipping to change at page 12, line 35 skipping to change at page 11, line 40
In the early days a machine had been allocated a specific IP address In the early days a machine had been allocated a specific IP address
and it could use it when it wanted to send an IP packet. The machine and it could use it when it wanted to send an IP packet. The machine
might need to execute an ARP exchange first before sending the might need to execute an ARP exchange first before sending the
packet, but it could keep the mapping in the cache for 15 minutes. packet, but it could keep the mapping in the cache for 15 minutes.
Nowadays a number of steps have to be taken before sending a packet. Nowadays a number of steps have to be taken before sending a packet.
We want to make sure that we are on the right network before we send We want to make sure that we are on the right network before we send
an IP packet. We run neighbor discovery. We cannot keep neighbor an IP packet. We run neighbor discovery. We cannot keep neighbor
discovery for 15 minutes and so when a node wakes up again it 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 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, see [RFC4436] and
on the same network either by re-obtaining an address using the [RFC6059], to check that hosts are on the same network either by re-
Dynamic Host Configuration Protocol (DHCP) or by noticing that the obtaining an address using the Dynamic Host Configuration Protocol
node is using the same default gateway because of a received Router (DHCP) or by noticing that the node is using the same default gateway
Advertisement (RA). because of a received Router Advertisement (RA).
However, these protocols do not work well, if at all, when the cost However, these protocols do not work well, if at all, when the cost
of sending/receiving those messages is 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 issues
arise from these almost-always-off nodes. arise from these almost-always-off nodes.
Many protocols are also becoming more chatty. Keeping the receiver Many protocols are also becoming more chatty. Keeping the receiver
up for an additional roundtrip costs extra energy. Protocol messages up for an additional roundtrip costs extra energy. Protocol messages
can also be lengthy, e.g., many protocols carry XML-based payloads. can also be lengthy, e.g., many protocols carry XML-based 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
less worse: less worse:
1. The Always-On Assumption 1. The Always-On Assumption
skipping to change at page 14, line 7 skipping to change at page 13, line 12
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.
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. The main focus of past investigations where most nodes are sleeping. The main focus of past investigations
has been on IPv6 and ND but other protocols do also deserve a deeper has been on IPv6 and ND but other protocols do also deserve a deeper
investigation, such as DNS, and DHCP. 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 HTTP, SIP, and XMPP.
Protocol (HTTP), the Session Initiation Protocol (SIP), and Nowadays these protocols are also being considered and used in
Extensible Messaging and Presence Protocol (XMPP). Nowadays these device-to-device communication and the verbose nature is not helpful.
protocols are also being considered and used in device-to-device
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
powered devices they would also be useful for other devices as well. powered devices they would also be useful for other devices as well.
Energy efficiency is useful for normal devices as well, such as Energy efficiency is useful for normal devices as well, such as
notebooks, desktops and smart phones. notebooks, desktops and smart phones.
For example, consider energy consumption in a home environment. The For example, consider energy consumption in a home environment. The
question is whether it will save more energy than it uses and question is whether it will save more energy than it uses and
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.
skipping to change at page 14, line 50 skipping to change at page 14, line 4
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 mechanisms 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)
a building block for all cryptographic functions with the benefit of [AES]) as a building block for all cryptographic functions with the
a smaller footprint of the overall solution, specifically with benefit of a smaller footprint of the overall solution, specifically
respect to hardware limitations (e.g., the hardware architecture of with respect to hardware limitations (e.g., the hardware architecture
certain embedded devices prevents pipelining from being used). In of certain embedded devices prevents pipelining from being used). In
the excitement for new work on optimizations of cryptograhpic the excitement for new work on optimizations of cryptograhpic
primitives other factors have to be taken into consideration that primitives other factors have to be taken into consideration that
influence successful deployment, such as widespread support in influence successful deployment, such as widespread support in
libraries, as well as intellectual property rights (IPR). As an libraries, as well as intellectual property rights (IPR). As an
example of the latter aspect, the struggle of Elliptic Curve example of the latter aspect, the struggle of Elliptic Curve
Cryptography (ECC)-based cryptographic algorithms to find deployment Cryptography (ECC)-based cryptographic algorithms [ECC] to find
can partially be attributed to its IPR situation. The reuse of deployment can partially be attributed to its IPR situation. The
libraries providing cryptographic functions is clearly an important reuse of libraries providing cryptographic functions is clearly an
way to use available memory resources in a more efficient way. To important way to use available memory resources in a more efficient
deal with the performance and footprint concerns investigations into way. To deal with the performance and footprint concerns
offloading certain resource-hungry functions to parties that possess investigations into offloading certain resource-hungry functions to
more cryptographic power have been considered. For example, the parties that possess more cryptographic power have been considered.
ability to delegate certificate validation to servers has been For example, the ability to delegate certificate validation to
standardized in the IETF before (see Online Certificate Status servers has been standardized in the IETF before; for the support of
Protocol (OCSP) in the Internet Key Exchange protocol version 2 the Online Certificate Status Protocol (OCSP) in the Internet Key
(IKEv2) and in Transport Layer Security (TLS)). Exchange protocol version 2 (IKEv2) and in Transport Layer Security
(TLS) see see [RFC4806] and [RFC3546], respectively.
Focusing only on the cryptographic primitives would be shortsighted; Focusing only on the cryptographic primitives would be shortsighted;
many would argue that this is the easy part of a smart object many would argue that this is the easy part of a smart object
security solution. Key management and credential enrollment, security solution. Key management and credential enrollment,
however, are considered a big challenge by many particularly when however, are considered a big challenge by many particularly when
usability requirements have to be taken into account. Another group usability requirements have to be taken into account. Another group
of challenges concern privacy; with smart grids, for example, some of challenges concern privacy; with smart grids, for example, some
have voiced concerns regarding the ability of third parties to keep have voiced concerns regarding the ability of third parties to keep
track of an individual's energy consumption (and draw associated track of an individual's energy consumption (and draw associated
conclusions). As another example, it is easy to see how a scale that conclusions). As another example, it is easy to see how a scale that
skipping to change at page 18, line 11 skipping to change at page 17, line 11
routing protocols is best in a given environment are still ongoing. routing protocols is best in a given environment are still ongoing.
Thomas Clausen, for example, argued for using an AODV-like routing Thomas Clausen, for example, argued for using an AODV-like routing
protocol in [Clausen]. protocol 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 modes, 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 learn about (neighbor discovery, security, routing) and to learn about
implementation experience. implementation experience.
One goal of the workshop was to identify areas that require further One goal of the workshop was to identify areas that require further
investigation. The list below reflects the thoughts of the workshop investigation. The list below reflects the thoughts of the workshop
participants as expressed on the day of the workshop. Note that the participants as expressed on the day of the workshop. Note that the
suggested items concern potential work by the IETF and the IRTF and suggested items concern potential work by the IETF and the IRTF and
the order does not imply a particular preference. the order does not imply a particular preference.
Security: Security:
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 to to the overall processing. Therefore, it remains a challenge to
accomplish performance improvements without sacrifying the overall accomplish performance improvements without sacrificing the
security level, taking the usability of the entire system into overall security level, taking the usability of the entire system
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 smart objects with the interoperability requirements of needs of smart objects with the interoperability requirements 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 smart objects versus end-to- trade-offs between performance on the smart objects versus end-to-
end security. Solutions that mandate a "trusted" middlebox whose end security. Solutions that mandate a "trusted" middlebox whose
only role is to terminate security associations tend to be frowned only role is to terminate security associations tend to be frowned
upon from the security perspective, especially since end-users of upon from the security perspective, especially since end-users of
challenged devices (where those exist) are unlikely to understand challenged devices (where those exist) are unlikely to 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)' was established years ago to deal with this topic but (ENROLL)' was established years ago to deal with residential
was terminated prematurely due to lack of progress. The email networks but was terminated prematurely due to lack of
archive still exists and is available [enroll] and may provide progress. The email archive still exists and is available
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
Light-Weight Implementation Guidance (LWIG) working group Light-Weight Implementation Guidance (LWIG) working group
[LWIG]. [LWIG].
* 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 [SHA3]. A suitable forum for discussion is the
Crypto Forum Research Group (CFRG) [CFRG]. IRTF Crypto Forum Research Group (CFRG) [CFRG].
The difficulty and impact of choosing specialised algorithms for The difficulty and impact of choosing specialised algorithms for
smart objects 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
skipping to change at page 20, line 23 skipping to change at page 19, line 23
these different elements may be combined to offer an explanation these different elements may be combined to offer an explanation
for the broader community. This would be a task for the Internet for the broader community. This would be a task for the Internet
Architecture Board (IAB). An example of prior work that serves as Architecture Board (IAB). An example of prior work that serves as
input is [I-D.baker-ietf-core]. input is [I-D.baker-ietf-core].
Network Management: Network Management:
While this topic did not make it onto the workshop agenda it was While this topic did not make it onto the workshop agenda it was
considered useful to start a discussion about how to implement considered useful to start a discussion about how to implement
network management protocols, such as Network Configuration network management protocols, such as Network Configuration
Protocol (NETCONF), on smart objects. The following position Protocol (NETCONF) [RFC6241], on smart objects. The following
papers may be useful as a starting point for further discussions position papers may be useful as a starting point for further
[Ersue], [Schoenwaelde]. An IETF draft is also available discussions [Ersue], [Schoenwaelde]. An IETF draft is also
[I-D.hamid-6lowpan-snmp-optimizations]. available [I-D.hamid-6lowpan-snmp-optimizations].
Congestion Control: Congestion Control:
When smart objects transmit sensor readings to some server on the When smart objects transmit sensor readings to some server on the
Internet then these protocol interactions often carry a small Internet then these protocol interactions often carry a small
amount of data and happen infrequently, although regularly. With amount of data and happen infrequently, although regularly. With
the work on new application protocols, like the CoAP the work on new application protocols, like the CoAP
[I-D.ietf-core-coap], the question of whether a congestion control [I-D.ietf-core-coap], the question of whether a congestion control
mechanism should be used at the underlying transport protocol or mechanism should be used at the underlying transport protocol or
by the application protocol itself arises. by the application protocol itself arises.
skipping to change at page 23, line 13 skipping to change at page 22, line 13
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. We Big thanks to Elwyn Davies for helping us to fix language bugs. We
would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas
Clausen, Bruce Nordman, Alissa Cooper, and Henning Schulzrinne for Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba,
their review comments. and Henning Schulzrinne for their 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
[AES] "Wikipedia Entry for 'Advanced Encryption Standard'",
http://en.wikipedia.org/wiki/
Advanced_Encryption_Standard , Dec 2011.
[CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group [CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group
(CFRG)", http://irtf.org/cfrg , June 2011. (CFRG)", http://irtf.org/cfrg , June 2011.
[Clausen] Clausen, T. and U. Herberg, "Some Considerations on [Clausen] Clausen, T. and U. Herberg, "Some Considerations on
Routing in Particular and Lossy Environments", IAB Routing in Particular and Lossy Environments", IAB
Interconnecting Smart Objects with the Internet Workshop, Interconnecting Smart Objects with the Internet Workshop,
Prague, Czech Republic, http://www.iab.org/wp-content/ Prague, Czech Republic, http://www.iab.org/wp-content/
IAB-uploads/2011/03/Clausen.pdf, March 2011. IAB-uploads/2011/03/Clausen.pdf, March 2011.
[Dolin] Dolin, B., "Application Communications Requirements for [Dolin] Dolin, B., "Application Communications Requirements for
'The Internet of Things'", IAB Interconnecting Smart 'The Internet of Things'", IAB Interconnecting Smart
Objects with the Internet Workshop, Prague, Czech Republic Objects with the Internet Workshop, Prague, Czech Republic
, http://www.iab.org/wp-content/IAB-uploads/2011/03/ , http://www.iab.org/wp-content/IAB-uploads/2011/03/
Ersue.pdf, March 2011. Ersue.pdf, March 2011.
[ECC] "Wikipedia Entry for 'Elliptic Curve Cryptography'",
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography ,
Dec 2011.
[Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object [Ersue] Ersue, M. and J. Korhonen, "Ersue / Korhonen Smart Object
Workshop Position Paper", IAB Interconnecting Smart Workshop Position Paper", IAB Interconnecting Smart
Objects with the Internet Workshop, Prague, Czech Republic Objects with the Internet Workshop, Prague, Czech Republic
, http://www.iab.org/wp-content/IAB-uploads/2011/03/ , http://www.iab.org/wp-content/IAB-uploads/2011/03/
Ersue.pdf, March 2011. Ersue.pdf, March 2011.
[FUN] "FUture home Networking (FUN) Mailing List", [FUN] "FUture home Networking (FUN) Mailing List",
https://www.ietf.org/mailman/listinfo/fun , June 2011. https://www.ietf.org/mailman/listinfo/fun , June 2011.
[GEOPRIV] "IETF Geographic Location/Privacy Working Group", [GEOPRIV] "IETF Geographic Location/Privacy Working Group",
http://datatracker.ietf.org/wg/geopriv/ , June 2011. http://datatracker.ietf.org/wg/geopriv/ , June 2011.
[I-D.baker-ietf-core] [I-D.baker-ietf-core]
Baker, F. and D. Meyer, "Internet Protocols for the Smart Baker, F. and D. Meyer, "Internet Protocols for the Smart
Grid", draft-baker-ietf-core-15 (work in progress), Grid", draft-baker-ietf-core-15 (work in progress),
April 2011. April 2011.
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.eggert-core-congestion-control] [I-D.eggert-core-congestion-control]
Eggert, L., "Congestion Control for the Constrained Eggert, L., "Congestion Control for the Constrained
Application Protocol (CoAP)", Application Protocol (CoAP)",
draft-eggert-core-congestion-control-01 (work in draft-eggert-core-congestion-control-01 (work in
progress), January 2011. progress), January 2011.
[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-07 (work in progress), July 2011. draft-ietf-core-coap-08 (work in progress), October 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.
skipping to change at page 26, line 50 skipping to change at page 26, line 15
[RECIPE] "Reducing Energy Consumption with Internet Protocols [RECIPE] "Reducing Energy Consumption with Internet Protocols
Exploration (RECIPE) Mailing List", Exploration (RECIPE) Mailing List",
https://www.ietf.org/mailman/listinfo/recipe , June 2011. https://www.ietf.org/mailman/listinfo/recipe , June 2011.
[RFC2222] Myers, J., "Simple Authentication and Security Layer [RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561, Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003. July 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status
Protocol (OCSP) Extensions to IKEv2", RFC 4806,
February 2007.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007. June 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. Framework", RFC 5582, September 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[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", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., 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, June 2010.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
November 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[SHA3] "NIST Cryptographic Hash Algorithm Competition",
http://csrc.nist.gov/groups/ST/hash/sha-3/index.html ,
Dec 2011.
[Schoenwaelde] [Schoenwaelde]
Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol Schoenwaelde, J., Tsou, T., and B. Sarikaya, "Protocol
Profiles for Constrained Devices", IAB Interconnecting Profiles for Constrained Devices", IAB Interconnecting
Smart Objects with the Internet Workshop, Prague, Czech Re Smart Objects with the Internet Workshop, Prague, Czech Re
public, http://www.iab.org/wp-content/IAB-uploads/2011/03/ public, http://www.iab.org/wp-content/IAB-uploads/2011/03/
Schoenwaelder.pdf, March 2011. Schoenwaelder.pdf, March 2011.
[SmartGrid]
"Wikipedia Entry for 'Smart Grid'",
http://en.wikipedia.org/wiki/Smart_grid , Dec 2011.
[Tussle] Clark, D., Wroslawski, J., Sollins, K., and R. Braden,
"Tussle in Cyberspace: Defining Tomorrow's Internet", In
Proc. ACM SIGCOMM ,
http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.html,
2002.
[Wasserman] [Wasserman]
Wasserman, M., "It's Not Easy Being "Green"", IAB Wasserman, M., "It's Not Easy Being "Green"", IAB
Interconnecting Smart Objects with the Internet Workshop, Interconnecting Smart Objects with the Internet Workshop,
Prague, Czech Republic, http://www.iab.org/wp-content/ Prague, Czech Republic, http://www.iab.org/wp-content/
IAB-uploads/2011/03/Wasserman.pdf, March 2011. IAB-uploads/2011/03/Wasserman.pdf, March 2011.
[enroll] "IETF Credential and Provisioning Working Group Mailing [enroll] "IETF Credential and Provisioning Working Group Mailing
List", http://mailman.mit.edu/pipermail/ietf-enroll/ , List", http://mailman.mit.edu/pipermail/ietf-enroll/ ,
June 2011. June 2011.
[irtf-discuss] [irtf-discuss]
"Draft ICN RG Charter on IRTF DISCUSS Mailing List", http: "Draft ICN RG Charter on IRTF DISCUSS Mailing List", http:
//www.ietf.org/mail-archive/web/irtf-discuss/current/ //www.ietf.org/mail-archive/web/irtf-discuss/current/
msg00041.html , May 2011. msg00041.html , May 2011.
Appendix A. Program Committee Appendix A. Program Committee
The following persons are responsible for the organization of the The following persons are responsible for the organization of the
associated workshop and are responsible also for this event: Jari associated workshop and are responsible also for this event: Jari
Arkko, Hannes Tschofenig, Bernard Aboba,Carsten Bormann, David Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David
Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph Culler, Lars Eggert, JP Vasseur, Stewart Bryant, Adrian Farrel, Ralph
Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo
Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen
Jennings, Manfred Hauswirth, and Lukas Kencl. Jennings, Manfred Hauswirth, and Lukas Kencl.
Appendix B. Published Workshop Material Appendix B. Published Workshop Material
Information about the workshop can be found at the IAB webpage: Information about the workshop can be found at the IAB webpage:
http://www.iab.org/about/workshops/smartobjects/ http://www.iab.org/about/workshops/smartobjects/
 End of changes. 38 change blocks. 
83 lines changed or deleted 145 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/