draft-iab-iotsi-workshop-01.txt   draft-iab-iotsi-workshop-02.txt 
Network Working Group J. Jimenez Network Working Group J. Jimenez
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: May 18, 2017 ARM Expires: January 3, 2019 Arm Ltd.
D. Thaler D. Thaler
Microsoft Microsoft
November 14, 2016 July 02, 2018
Report from the Internet of Things (IoT) Semantic Interoperability Report from the Internet of Things (IoT) Semantic Interoperability
(IOTSI) Workshop 2016 (IOTSI) Workshop 2016
draft-iab-iotsi-workshop-01.txt draft-iab-iotsi-workshop-02
Abstract Abstract
This document provides a summary of the 'Workshop on Internet of This document provides a summary of the 'Workshop on Internet of
Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIAG], [IOTSIWS], Things (IoT) Semantic Interoperability (IOTSI)', which took place in
which took place in Santa Clara, CA, on March 17-18, 2016. The main Santa Clara, California, on March 17-18, 2016. The main goal of the
goal of the workshop was to foster a discussion on the different workshop was to foster a discussion on the different approaches used
approaches used by companies and standards developing organizations by companies and Standards Developing Organizations (SDOs) to
to accomplish interoperability at the application layer. This report accomplish interoperability at the application layer. This report
summarizes the discussions and lists recommendations to the standards summarizes the discussions, and lists recommendations to the
community. The views and positions in this report are those of the standards community. The views and positions in this report are
workshop participants and do not necessarily reflect those of the those of the workshop participants and do not necessarily reflect
authors and the Internet Architecture Board (IAB), which organized those of the authors and the Internet Architecture Board (IAB), which
the workshop. organized the workshop.
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 May 18, 2017. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 4
4. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5 4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Dealing with change . . . . . . . . . . . . . . . . . . . . . 9
6. Dealing with change . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Appendix A: Program Committee . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Appendix B: Accepted Position Papers . . . . . . . . . . . . 8 9. Appendix A: Program Committee . . . . . . . . . . . . . . . . 11
10. Appendix C: List of Participants . . . . . . . . . . . . . . 10 10. Appendix B: Accepted Position Papers . . . . . . . . . . . . 11
11. Informative References . . . . . . . . . . . . . . . . . . . 12 11. Appendix C: List of Participants . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 12. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
architecture. The investigated topics often require coordinated architecture. The investigated topics often require coordinated
efforts of many organizations and industry bodies to improve an efforts of many organizations and industry bodies to improve an
identified problem. One of the targets of the workshops is to identified problem. One of the targets of the workshops is to
establish communication between relevant organizations, specially establish communication between relevant organizations, especially
when the topics are out of the scope for the Internet Engineering when the topics are out of the scope for the Internet Engineering
Task Force (IETF). This long-term planning function of the IAB is Task Force (IETF). This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working complementary to the ongoing engineering efforts performed by working
groups of the IETF. groups of the IETF.
Increasing interoperability in the area of Internet of Things (IoT) With the expansion of the Internet of Things (IoT), interoperability
has been a top priority for many standards organizations and becomes more and more important. Standards Developing Organizations
pariticularly the lower layers of the Internet protocol stack have (SDOs) have done a tremendous amount of work to standardize new
received a lot of attention. Also at the application layer, such as protocols, and to profile existing protocols.
with CoAP and HTTP, there is a trend in reusing RESTful design
patterns. However, data exchanged on top of these application layer At the application layer and at the level of solution frameworks,
protocols there is still a lot of fragmentation and the same degree interoperability is not yet mature. Particularly, the work on data
of increase in interoperability has not been observed. formats (in the form of data models and information models) has not
seen the same level of consistency throughout SDOs.
One common problem is the lack of an encoding-independent
standardization of the information, the so-called information model.
Another problem is the strong relationship with the underlying
communication architecture, such as a Remote Procedure Call (RPC)
style design or a RESTful design. Furthermore, groups develop
solutions that are very similar on the surface but differ slightly in
their standardized outcome, leading to interoperability problems.
Finally, some groups favor different encodings for use with various
application layer protocols.
Thus, the IAB decided to organize a workshop to reach out to relevant Thus, the IAB decided to organize a workshop to reach out to relevant
stakeholders to explore the state-of-the-art and to identify stakeholders to explore the state-of-the-art and to identify
communality and gaps. commonality and gaps [IOTSIAG][IOTSIWS]. In particular, the IAB was
interested to learn about the following aspects:
o The different perceived state of the art on data and information o What is the state of the art in data and information models? What
models. should an information model look like?
o The lack of an encoding-independent standardization of the o What is the role of formal languages, such as schema languages, in
information, the so-called information model. describing information and data models?
o The strong relationship with the underlying communication pattern, o What is the role of metadata, which is attached to data to make it
such as remote procedure calls (RPC), publish/subscribe or RESTful self-describing?
designs.
o Identifying which similar concepts groups have develop in o How can we achieve interoperability when different organizations,
parallel, specially those that would require only slight companies and individuals develop extensions?
modifications to solve interoperability.
o Identifying how existing data models can be mapped against each o What is the experience with interworking various data models
other to offer inter working. developed from different groups, or with data models that evolved
over time?
o Identifying common use cases for cooperation and harmonization. o What functionality should online repositories for sharing schemas
have?
o How can existing data models be mapped against each other to offer
interworking?
o Is there room for harmonization, or are the use cases of different
groups and organizations so unique that there is no possibility
for cooperation?
o How can organizations better work together to increase awareness
and information sharing?
2. Terminology 2. Terminology
The first roadblock to semantic interoperability is the lack of a The first roadblock to interoperability at the level of data models
common vocabulary to start the discussion. There is a need to align is the lack of a common vocabulary to start the discussion.
between participating organizations on a common set of basic terms. [RFC3444] provides a starting point by separating conceptual models
[RFC3444] does a start by separating conceptual models for designers for designers, or "information models", from concrete detailed
or Information Models (IMs) and concrete detailed definitions for definitions for implementers, or "data models". There are concepts
implementors or Data Models (DMs). There are concepts that are that are undefined in that RFC and elsewhere, such as the interaction
undefined in that RFC and elsewhere, such as the interaction with the with the resources of an endpoint, or "interaction model". Therefore
resources of an endpoint or Interaction Model. Therefore the three the three "main" common models that were identified were:
"main" common models that could be identified were:
Information Model (IM) it defines an environment at the highest Information Model
level of abstraction, they express the desired functionality. An information model defines an environment at the highest level
They can be defined informally (e.g. in plain English) or more of abstraction and expresses the desired functionality.
formally (e.g. UML, Entity-Relationship Diagrams, etc.). Information models can be defined informally (e.g., in plain
Implementation details are hidden. English) or more formally (e.g., UML, Entity-Relationship
Diagrams, etc.). Implementation details are hidden.
Data Model (DM) it defines concrete data representations at a lower Data Model
A data model defines concrete data representations at a lower
level of abstraction, including implementation and protocol- level of abstraction, including implementation and protocol-
specific details. Some examples are: SNMP Management Information specific details. Some examples are: SNMP Management Information
Base (MIBs), W3C Thing Description (TD) Things, YANG models, LWM2M Base (MIB) modules, W3C Thing Description (TD) Things, YANG
Schemas, OCF Schemas and so on. models, LWM2M Schemas, OCF Schemas, and so on.
Interaction Model (IN) it defines how data is accessed and retrieved Interaction Model
An interaction model defines how data is accessed and retrieved
from the endpoints, being therefore tied to the specific from the endpoints, being therefore tied to the specific
communication pattern that the system has (e.g. REST methods, communication pattern that the system has (e.g., REST methods,
Publish/Subscribe operations or RPC-calls). Publish/Subscribe operations, or RPC calls).
Another identified terminology issue is the semantic meaning overload Another identified terminology issue is the semantic meaning overload
that some terms have. Meaning will vary depending on the context the that some terms have. The meaning can vary depending on the context
term is used. Some examples of such terms are: semantics, models, in which the term is used. Some examples of such terms are:
encoding, serialization format, media types or encoding types. Due semantics, models, encoding, serialization format, media types or
to time constraints no concrete terminology was agreed upon, however encoding types. Due to time constraints, no concrete terminology was
work will continue within each organization to create various agreed upon, but work will continue within each organization to
terminology documents, see [IOTSIGIT]. create various terminology documents. The participants agreed to set
up a github repository [IOTSIGIT] for sharing information.
3. Architecture
Architectures follow different design patterns, some are REST- 3. What Problems to Solve
oriented with clear methods to find and manipulate resources on
endpoints with almost no state kept between them. Others are more
Publish/Subscribe-oriented that focus on the flow of information
based on the topics of the information that is being shared. Others
are RPC-like requiring to know beforehand the set of parameters that
are accessed, requiring to generate code both on the client and
server side, they are tightly coupled and service-oriented.
Thing-hub-cloud things talk to a hub, which talks back to them and The participants agreed that there is not simply a single problem to
to the cloud. There is a spectrum of emphasis on the hub vs. the be solved, but rather a range. During the workshop the following
cloud. For some the hub is simply an access point; for others it problems were discussed:
is a critical place for control loops and ALGs.
Meta Thing some things are actually virtual, like an alarm composed o Formal Languages for Documentation Purposes
of clock, lights, and thermostat.
Nearby things some things may be geospatially related even if they To simplify review and publication, SDOs need formal descriptions of
are not on the same network or within the same administrative their data and interaction models. Several of them use a tabular
domain. representation found in the specification itself, but use a formal
language as an alternative way of describing objects and resources
for formal purposes. Some examples of formal language use are as
follows.
Current data models and definitions for "things" often focus on The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML schema
defining actual physical devices and representing their state. That [LWM2M-Schema] to describe their object and resource definitions.
focus should perhaps be shifted into a more holistic or user-oriented The XML files of standardized objects are available for download at
perspective, defining abstract concepts as well. On the other a lot [OMNA].
of focus is placed on human interaction with physical devices while
IoT will be more oriented to interaction between "things" instead.
Those things should be designed to be multiple-purpose, keeping in The Bluetooth SIG defined Generic Attributes (GATT) services and
mind that solutions should be open-ended to facilitate new usages and characteristics for use with Bluetooth Smart/Low Energy. The
new future domains of operation. this pattern has already happened, services and characteristics are shown in a tabular form on the
devices that were intended for one purpose end up being used for a Bluetooth SIG website at [SIG], and are also defined as XML instance
different one given the right context ((e.g. smart phone led light documents.
turned out to be a heartrate monitor). IoT domain is currently
missing insights into what user actually expect.
4. What Problems to Solve The Open Connectivity Foundation (OCF) uses JSON Schemas to formally
define data models, and RAML to define interaction models. The
standard files are available online at OneIoTa.org.
Although the workshop focused on a specific problem it became obvious The AllSeen Alliance uses AllJoyn Introspection XML to define data
from the position papers that various organizations, industry groups and interaction models in the same formal language, tailored for RPC-
and individuals attempted to solve different problems. At least the style interaction. The standard files are available online on the
following goals have been described: AllSeen Alliance web site, but both standard and vendor-defined model
files can be obtained by directly querying a device for them at
runtime.
o Formal Languages for Documentation Purposes The World-Wide Web Consortium (W3C) uses the Resource Description
Framework (RDF) to define data and interaction models using a format
tailored for the web.
Standardization organizations are in the need for a more formal The Internet Engineering Task Force (IETF) uses YANG to define data
description of their information and data models in order to simplify and interaction models. Other SDOs may use various other formats.
review, and publication. For example, the Open Mobile Alliance (OMA)
used an XML schema [LWM2M-Schema] to describe their object
definitions (i.e., data model) as XML instance documents. These XML
documents offer an alternative way of describing objects compared to
the tabular representation found in the specification itself. The
XML files of standardized objects are available for download at
[OMNA]. Furthermore, a tool is offered to define new objects and
resources. The online editor tool can be found at [OMA-Editor].
o Formal Languages for Code Generation o Formal Languages for Code Generation
Formal data and information modelling languages for use by developers Code generation tools that use formal data and information modelling
to enable code generation. For example, the Allseen Visual Studio languages are needed by developers. For example, the AllSeen Visual
Plugin [Allseen-Plugin] offers a wizzard to generate code based on Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based
the formal description of the data model. Another example of a data on the formal description of the data model. Another example of a
modelling language that can be used for code generation is YANG. A data modelling language that can be used for code generation is YANG.
popular tool to help with code generation of YANG modules is pyang A popular tool to help with code generation of YANG modules is pyang
[PYANG]. [PYANG]. An example of a tool that can do code generation for
multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for
code generation included easing development of server-side device
functionality, clients, and compliance tests.
o Debugging Support o Debugging Support
Ability to allow debugging tools to implement generic object browsers Debugging tools are needed that implement generic object browsers,
by utilizing the standardized information and data model. Example: which use standard data models and/or retrieve formal language
NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer]. descriptions from the devices themselves. As one example, the NRF
Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can
be used to display services and characteristics defined by the
Bluetooth SIG. As another example, AllJoyn Explorer
[AllJoynExplorer] can be used to browse and interact with any
resource exposed by an AllJoyn device, including both standard and
vendor-defined data models, by retrieving the formal descriptions
from the device at runtime.
o Translation o Translation
The ability for gateways and other similar devices to dynamically
translate (or map) one data model to another one. An example of this The working assumption is that devices need to have a common data
idea can be found in [UDI]. model with a priori knowledge of data types and actions. However
that would imply that each consortium/organization will try to define
their own, causing a major interoperability problem, if not a
completely intractable one given the amount of variations,
extensions, compositions or versioning changes that will happen on a
per data model basis.
Another potential approach is to have a minimal ammount of
information on the device to allow for a runtime binding to a
specific model, the objective being to require as little prior
knowledge as possible.
Moreover, gateways, bridges and other similar devices need to
dynamically translate (or map) one data model to another one.
Complexity will increase as there are also multiple protocols and
schemas that make interoperability harder to achieve.
o Runtime Discovery o Runtime Discovery
Allow IoT devices to exchange information, potentially along with the Runtime discovery allows IoT devices to exchange metadata about the
data exchange, to discover meta-data about the data and, potentially, data, potentially along with the data exchanged itself. In some
even a self-describing interaction model. An example of such an cases the metadata not only describes data but also the interaction
approach has been shown with HATEOAS [HATEOAS]. model as well. An example of such an approach has been shown with
HATEOAS [HATEOAS]. Another example is that all AllJoyn devices
support such runtime discovery using a protocol mechanism called
"introspection", where the metadata is queried from the device itself
[AllSeen].
5. Translation There are various models, whether deployed or possible, for such
discovery. The metadata might be extracted from a specification, or
looked up on a cloud repository (e.g., OneIoTa for OCF models), or
looked up via a vendor's site, or obtained from the device itself
(such as in the AllJoyn case). The relevant metadata might be
obtained from the same place, or different pieces might be obtained
from different places, such as separately obtaining information such
as (a) syntax information, (b) end-user descriptions in a desired
language, and (c) developer-specific comments for implementers.
One of the targets of interoperability is to create translators 4. Translation
between the data models. There are analogies with gateways back in
1985 when they were used to translate between network protocols,
eventually IP took over providing interoperability, however we lost
some of the features provided by those other protocols. The creation
of an equivalent "hub/s" that offer translation between the different
data models or data semantics seems one of the ways forward. Some
lose of expressiveness due to the translation between models seems
also unavoidable.
When it comes to translation two different distinctions appear: In an ideal world where organizations and companies cooperate and
translating data between data models and translating data models. agree on a single data model standard, there is no need for gateways
The first one implies doing the translation at runtime while the that translate from one data model to the other one. However, this
second performs one translation between the data models one time, is far from reality today, and there are many proprietary data models
like translating a YANG model to a RAML/JSON one. Indeed, for every in addition to the already standardized ones. As a consequence,
IM multiple DMs could be translated. gateways are needed to translate between data models. This leads to
(n^2)-n combinations, in the worst case.
In a sense these distinctions affect as to when the translation is There are analogies with gateways back in the 1980s that were used to
performed. It can be done at "design time" when the information translate between network layer protocols. Eventually IP took over,
model is done, it can be done at runtime for a concrete data model providing the necessary end-to-end interoperability at the network
and it can be done depending n the actual serialization. layer. Unfortunately, the introduction of gateways leads to the loss
of expressiveness due to the translation between data models. The
functionality of IP was so valuable in the market that advanced
features of other networking protocols became less attractive and
were not used anymore.
Yet another distinction will appear depending on the requirements Participants discussed an alternative which they called a 'red star',
from the application protocols, RPC-style ones might require a shown in Figure 1, where data models are translated to a common data
slightly different DM than REST ones for similar operations, for model shown in the middle. This reduces the number of translations
example SNMP-traps could be similar to CoAP-Observations but not that are needed down to 2n (in the best case). The problem, of
quite the same. It is easier to translate between systems that course, is that everyone wants their own data model to be the red
follow the same architecture/design pattern than across star in the center.
architectures, full translation might not even be possible (e.g.
stateless vsstateful systems).
Translation of models script to translate XML to YANG Translation of +-----+ +-----+
serialized data, on a hub in order to normalize it to other data | | | |
model. | | -- -- | |
| | -- -- | |
+-----+ -- -- +-----+
-- ---
-- --
-- --
-- --
--- -- A -- ---
/ \ ___/ \___ / \
| | ---------------', .'--------------- | |
\ / /. ^ .\ \ /
--- /' '\ ---
-- --
-- --
-- --
-- --
-- --
/\ -- -- /\
/ \ -- -- / \
/ \ / \
/ \ / \
/--------\ /--------\
6. Dealing with change Figure 1: The 'Red Star' in Data/Information Models.
While the workshop itself was not a suitable forum to discuss the
design of such translation in detail, several questions were raised:
o Do we need a "red star" that does everything or could we design
something that offers a more restricted functionality?
o How do we handle loss of data and loss of functionality?
o Should data be translated between data models or data models be
translated?
o How can interaction models be translated? They need to be dealt
with in addition to the data models.
o Many (if not all) data and interaction models have some bizarre
functionality that cannot be translated easily. How can those be
handled?
o What limitations are we going to accept in these translations?
The participants also addressed the question of when translation
should be done. Two use cases were discussed:
a) Design time: a translation between data model descriptions, such
as translating a YANG model to a RAML/JSON model, can be performed
once, during design time. A single information model might be mapped
to a number of different data models.
b) Run time: Runtime translation of values in two standard data
models can only be algorithmically done when the data model on one
side is algorithmically derived from the data model on the other
side. This was called a "derived model". It was discussed that the
availability of runtime discovery can aid in semantic translation,
such as when a vendor-specific data model on one side of a protocol
bridge is resolved and the translator can algorithmically derive the
semantically-equivalent vendor-specific data model on the other side
of a protocol bridge, as discussed in [BridgeTaxonomy].
The participants agreed that algorithm translation will generally
require custom code, whenever one is translating to anything other
than a derived model.
Participants concluded that it is typically easier to translate data
between systems that follow the same communication architecture.
5. Dealing with change
A large part of the workshop was dedicated to the evolution of A large part of the workshop was dedicated to the evolution of
devices and server side applications. Multiple of the participating devices and server-side applications. Interactions between devices
groups have defined data formats for data representation, however and services and how their relationship evolves over time is
interactions between devices and services and how their relationship complicated by their respective different interaction models.
evolves over time is more related to the interaction model.
There are various approaches to it. In the most primitive case, a The workshop participants discussed various approaches to deal with
developer will use a description of an API and implement whichever change. In the most basic case, a developer might use a description
are the protocol steps. In some cases the information model itself of an API and implement the protocol steps. Sometimes the data or
can be used to generate some of the code stubs. Changes of an API information model can be used to generate code stubs. Subsequent
imply changes on the clients to upgrade to the new version, which changes to an API require changes on the clients to upgrade to the
requires some development of new code to satisfy the needs of the new new version, which requires some development of new code to satisfy
API. the needs of the new API.
New, approaches imply that the whole interaction could be machine- These interactions could be made machine-understandable in the first
understandable on the first place with changes happening at runtime. place, enabling for changes to happen at runtime. In that scenario,
In it, a machine client can discover the possible interactions with a a machine client could discover the possible interactions with a
service, adapting to changes as they occur without specific code service, adapting to changes as they occur without specific code
being developed to adapt to them. being developed to adapt to them.
The challenge seems to be to define the human-readable parts as The challenge seems to be to code the human-readable specification
machine-readable. Machine-readable require a shared vocabulary to into a machine-readable format. Machine-readable languages require a
give meaning to the tags. shared vocabulary to give meaning to the tags.
These type of interactions are based on the The REST architectural These types of interactions are often based on the REST architectural
style. the principle is that the device or the endpoint, just needs a style. Its principle is that a device or endpoint only needs a
single entry point, the server would provide descriptions of the API single entry point with a host providing descriptions of the API in-
inband by means of web links and forms. band by means of web links and forms.
By defining IoT specific relation types, it is possible to drive By defining IoT-specific relation types, it is possible to drive
interactions through links instead of hardcoding URIs into the interactions through links instead of hardcoding URIs into a RESTful
client, thus making the system flexible enough for later changes. client, thus making the system flexible enough for later changes.
The definition of the basic hypermedia formats for IoT is still work The definition of the basic hypermedia formats for IoT is still work
in progress, however some of the existing mechanism can be reused, in progress. However, some of the existing mechanisms can be reused,
such as resource discovery, forms or links. such as resource discovery, forms, or links.
7. Acknowledgements 6. Security Considerations
There were two types of security considerations discussed: use of
formal data models for security configuration, and security of data
and data models in general.
It was observed that the security assumptions and configuration, or
"security model", varies by ecosystem today, making the job of a
translator difficult. For example, the types of security principals
(e.g., user vs. device vs. application), the use of access control
lists (ACLs) vs. capabilities, and what types of policies can be
expressed, all vary by ecosystem. As a result, the security model
architecture generally dictates where translation can be done.
One approach discussed was whether two endpoints might be able to use
some overlay security model, across a translator between two
ecosystems, which only works if the two endpoints agree on a common
data model for their communication. Another approach discussed was
simply having a translator act as a trusted intermediary, which
allows the translator to be able to translate between different data
models.
One suggestion discussed was potentially adding metadata into either
the formal data model language, or accompanying the data values over
the wire, tagging the data with privacy levels. However, sometimes
even the privacy level of information might itself be sensitive.
Still, it was observed that being able to dynamically learn security
requirements might help provide better UIs and translators.
7. Collaboration
The participants discussed how best to share information among their
various organizations. One discussion was around having joint
meetings. One current challenge reported was that organizations were
not aware of when and where each others' meetings were scheduled, and
sharing such information could help organizations better collocate
meetings. To facilitate this exchange, the participants agreed to
add links to their respective meeting schedules from a common page in
the IOTSI repository [IOTSIGIT].
Another challenge reported was that organizations did not know how to
find each others' published data models, and sharing such information
could better facilitate reuse of the same information model. To
facilitate this exchange, this participants discussed whether a
common repository might be used by multiple organizations. The OCF's
OneIoTa repository was discussed as one possibility but it was
reported that its terms of use at the time of the workshop prevented
this. The OCF agreed to take this back and look at updating the
terms of use to allow other organizations to use it too, as the
restriction was not the intent. Schema.org was discussed as another
possibility. In the meantime, the participants agreed to add links
to their respective repositories from a common page in the IOTSI
repository [IOTSIGIT].
It was also agreed that the iotsi@iab.org mailing list would remain
open and available for sharing information between all relevant
organizations.
8. Acknowledgements
We would like to thank all paper authors and participants for their We would like to thank all paper authors and participants for their
contributions. Due to the large number of position paper submissions contributions, and Ericsson for hosting the workshop.
we were unfortunately unable to invite every author; we would like to
apologize to those that could not attend the workshop.
8. Appendix A: Program Committee 9. Appendix A: Program Committee
This workshop was organized by the following individuals: Jari Arkko, This workshop was organized by the following individuals: Jari Arkko,
Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
Tschofenig. Tschofenig.
9. Appendix B: Accepted Position Papers 10. Appendix B: Accepted Position Papers
1. Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever" o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
2. Carsten Bormann, "Noise in specifications hurts" o Carsten Bormann, "Noise in specifications hurts"
3. Benoit Claise, "YANG as the Data Modelling Language in the IoT o Benoit Claise, "YANG as the Data Modelling Language in the IoT
space" space"
4. Robert Cragie, "The ZigBee Cluster Library over IP" o Robert Cragie, "The ZigBee Cluster Library over IP"
5. Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair: o Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair:
interoperable IoT services for major Building Automation and interoperable IoT services for major Building Automation and
Lighting Control ecosystems" Lighting Control ecosystems"
6. Universal Devices, "Object Oriented Approach to IoT o Universal Devices, "Object Oriented Approach to IoT
Interoperability" Interoperability"
7. Bryant Eastham, "Interoperability and the OpenDOF Project" o Bryant Eastham, "Interoperability and the OpenDOF Project"
8. Stephen Farrell, Alissa Cooper, "It's Often True: Security's o Stephen Farrell, Alissa Cooper, "It's Often True: Security's
Ignored (IOTSI) - and Privacy too" Ignored (IOTSI) - and Privacy too"
9. Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT o Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT semantics
semantics landscape" landscape"
10. Ted Hardie, "Loci of Interoperability for the Internet of o Ted Hardie, "Loci of Interoperability for the Internet of Things"
Things"
11. Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure
Communications" Communications"
12. Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart o Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart
Objects" Objects"
13. David Jones, IOTDB - "Interoperability Through Semantic o David Jones, IOTDB - "Interoperability Through Semantic
Metastandards" Metastandards"
14. Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler o Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler of
of Semantic Interoperability on the Web of Things" Semantic Interoperability on the Web of Things"
15. Achilleas Kemos, "Alliance for Internet of Things Innovation o Achilleas Kemos, "Alliance for Internet of Things Innovation
Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Semantic Interoperability Release 2.0, AIOTI WG03 - IoT
Standardisation" Standardisation"
16. Ari Keraenen, Cullen Jennings, "SenML: simple building block for o Ari Keraenen, Cullen Jennings, "SenML: simple building block for
IoT semantic interoperability" IoT semantic interoperability"
17. Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on o Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on Unified
Unified Data Model and Framework to Support Interoperability Data Model and Framework to Support Interoperability between IoT
between IoT Applications" Applications"
18. Michael Koster, "Model-Based Hypertext Language" o Michael Koster, "Model-Based Hypertext Language"
19. Matthias Kovatsch, Yassin N. Hassan, Klaus Hartke, "Semantic o Matthias Kovatsch, Yassin N. Hassan, Klaus Hartke, "Semantic
Interoperability Requires self describing Interaction Models" Interoperability Requires self describing Interaction Models"
20. Kai Kreuzer, "A Pragmatic Approach to Interoperability in the o Kai Kreuzer, "A Pragmatic Approach to Interoperability in the
Internet of Things" Internet of Things"
21. Barry Leiba, "Position Paper" o Barry Leiba, "Position Paper"
22. Marcello Lioy, "AllJoyn" o Marcello Lioy, "AllJoyn"
23. Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON o Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON Hyper-
Hyper-Schema" Schema"
24. Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope
of security issues" of security issues"
25. Open Geospatial Consortium, "OGC SensorThings API: Communicating o Open Geospatial Consortium, "OGC SensorThings API: Communicating
"Where" in the Web of Things" "Where" in the Web of Things"
26. Jean Paoli, Taqi Jaffri, "IoT Information Model o Jean Paoli, Taqi Jaffri, "IoT Information Model Interoperability:
Interoperability: An Open, Crowd-Sourced Approach in Three An Open, Crowd-Sourced Approach in Three Parallel Parti"
Parallel Parti"
27. Joaquin Prado, "OMA Lightweight M2M Resource Model" o Joaquin Prado, "OMA Lightweight M2M Resource Model"
28. Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic o Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic
Interoperability Workshop" Interoperability Workshop"
29. Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable o Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable Data
Data to Facilitate Time and Context Specific Interoperability" to Facilitate Time and Context Specific Interoperability"
30. Jasper Roes, Laura Daniele, "Towards semantic interoperability o Jasper Roes, Laura Daniele, "Towards semantic interoperability in
in the IoT using the Smart Appliances REFerence ontology (SAREF) the IoT using the Smart Appliances REFerence ontology (SAREF) and
and its extensions" its extensions"
31. Max Senges, "Submission for IAB IoT Sematic Interoperability o Max Senges, "Submission for IAB IoT Sematic Interoperability
workshop" workshop"
32. Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation o Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation
Experiences of Semantic Interoperability for RESTful Gateway Experiences of Semantic Interoperability for RESTful Gateway
Management" Management"
33. Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic o Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic
Interoperability Gaps in the Internet-of-Things Meta-Models" Interoperability Gaps in the Internet-of-Things Meta-Models"
34. Robert Sparks and Ben Campbell, "Considerations for certain IoT o Robert Sparks and Ben Campbell, "Considerations for certain IoT
based services" based services"
35. J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool" o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
36. J. Clarke Stevens, Piper Merriam, "Derived Models for o J. Clarke Stevens, Piper Merriam, "Derived Models for
Interoperability Between IoT Ecosystems" Interoperability Between IoT Ecosystems"
37. Ravi Subramaniam, "Semantic Interoperability in Open o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity
Connectivity Foundation (OCF) - formerly Open Interconnect Foundation (OCF) - formerly Open Interconnect Consortium (OIC)""
Consortium (OIC)""
38. Andrew Sullivan, "Position paper for IOTSI workshop" o Andrew Sullivan, "Position paper for IOTSI workshop"
39. Darshak Thakore, "IoT Security in the context of Semantic o Darshak Thakore, "IoT Security in the context of Semantic
Interoperability" Interoperability"
40. Dave Thaler, "IoT Bridge Taxonomy" o Dave Thaler, "IoT Bridge Taxonomy"
41. Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to o Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to
Semantic Interoperability" Semantic Interoperability"
42. Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike
Mike Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram, Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram, "Internet
"Internet of Things: Toward Smart Networked Systems and of Things: Toward Smart Networked Systems and Societies"
Societies"
43. Peter van der Stok, Andy Bierman, "YANG-Based Constrained o Peter van der Stok, Andy Bierman, "YANG-Based Constrained
Management Interface (CoMI)" Management Interface (CoMI)"
10. Appendix C: List of Participants 11. Appendix C: List of Participants
o Andy Bierman, YumaWorks o Andy Bierman, YumaWorks
o Carsten Bormann, Uni Bremen/TZI o Carsten Bormann, Uni Bremen/TZI
o Ben Campbell, Oracle o Ben Campbell, Oracle
o Benoit Claise, Cisco o Benoit Claise, Cisco
o Alissa Cooper, Cisco o Alissa Cooper, Cisco
o Robert Cragie, ARM Limited o Robert Cragie, ARM Limited
o Laura Daniele, TNO o Laura Daniele, TNO
o Bryant Eastham, OpenDof o Bryant Eastham, OpenDOF
o Christian Groves, Huawei o Christian Groves, Huawei
o Ted Hardie, Google o Ted Hardie, Google
o Yonggeun Hong, ETRI o Yonggeun Hong, ETRI
o Russ Housley, Vigil Security o Russ Housley, Vigil Security
o David Janes, IOTDB o David Janes, IOTDB
skipping to change at page 11, line 46 skipping to change at page 15, line 26
o Barry Leiba, Huawei o Barry Leiba, Huawei
o Steve Liang, Uni Calgary o Steve Liang, Uni Calgary
o Marcello Lioy, Qualcomm o Marcello Lioy, Qualcomm
o Kerry Lynn, Verizon o Kerry Lynn, Verizon
o Mayan Mathen, Catalina Labs o Mayan Mathen, Catalina Labs
o Erik Nordmenk, Arista o Erik Nordmark, Arista
o Jean Paoli, Microsoft o Jean Paoli, Microsoft
o Joaquin Prado, OMA o Joaquin Prado, OMA
o Dave Raggett, W3C o Dave Raggett, W3C
o Max Senges, Google o Max Senges, Google
o Ned Smith, Intel o Ned Smith, Intel
o Robert Sparks, Oracle o Robert Sparks, Oracle
o Ram Sriram, NIST o Ram Sriram, NIST
skipping to change at page 12, line 20 skipping to change at page 15, line 48
o Robert Sparks, Oracle o Robert Sparks, Oracle
o Ram Sriram, NIST o Ram Sriram, NIST
o Clarke Stevens o Clarke Stevens
o Ram Subramanian, Intel o Ram Subramanian, Intel
o Andrew Sullivan, DIN o Andrew Sullivan, DIN
o Darshak Thakore, Cablelabs o Darshak Thakore, CableLabs
o Dave Thaler, Microsoft o Dave Thaler, Microsoft
o Hannes Tschofenig, ARM Limited o Hannes Tschofenig, ARM Limited
o Michael Verschoor, Philips Lightning o Michael Verschoor, Philips Lighting
11. Informative References 12. Informative References
[Allseen-Plugin] [AllJoynExplorer]
Rockwell, B., "Using the AllJoyn Studio Extension", Microsoft, "AllJoyn Explorer", 2016.
https://channel9.msdn.com/Blogs/Internet-of-Things-Blog/
Using-the-AllJoyn--Studio-Extension , 2016.
[HATEOAS] Kovatsch, M., "Semantic Interoperability Requires [AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to
Self&#173;describing Interaction Models - HATEOAS for the Semantic Interoperability", 2016, <https://www.iab.org/wp-
Internet of Things", Proceedings of the IoT Semantic content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>.
Interoperability Workshop 2016, 2016.
[AllSeen-Plugin]
Rockwell, B., "Using the AllJoyn Studio Extension", 2016.
[BridgeTaxonomy]
Thaler, D., "IoT Bridge Taxonomy", 2016,
<https://www.iab.org/wp-content/IAB-uploads/2016/03/
DThaler-IOTSI.pdf>.
[HATEOAS] Kovatsch, M., "Semantic Interoperability Requires Self-
describing Interaction Models - HATEOAS for the Internet
of Things", Proceedings of the IoT Semantic
Interoperability Workshop 2016, 2016,
<https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-
IAB-HATEOAS.pdf>.
[IOTSIAG] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) - [IOTSIAG] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) -
Agenda and Slides", 2016, Agenda and Slides", 2016,
<https://www.iab.org/activities/workshops/iotsi/agenda/>. <https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIGIT] [IOTSIGIT]
IOTSI, "Github Collaborative Repository", 2016, IOTSI, "Github Collaborative Repository", 2016,
<https://github.com/iotsi>. <https://github.com/iotsi/iotsi>.
[IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) [IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI)
2016 - Main Page and Position Papers", 2016, 2016 - Main Page and Position Papers", 2016,
<https://www.iab.org/activities/workshops/iotsi/>. <https://www.iab.org/activities/workshops/iotsi/>.
[LWM2M-Schema] [LWM2M-Schema]
OMA, "OMA LWM2M XML Schema", OMA, "OMA LWM2M XML Schema", 2018.
http://technical.openmobilealliance.org/tech/profiles/
LWM2M.xsd , 2016.
[OMA-Editor] [nRF-Sniffer]
OMA, "OMA LWM2M Object and Resource Editor", Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low
http://dev_devtoolkit.openmobilealliance.org/OEditor/ , energy packet sniffer", 2016.
2016.
[OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource [OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource
Registry", Registry", 2018.
http://technical.openmobilealliance.org/Technical/
technical-information/omna/ [OpenDOF] OpenDOF, "The OpenDOF Project", 2015,
lightweight-m2m-lwm2m-object-registry , 2016. <https://opendof.org>.
[PYANG] Bjorklund, M., "An extensible YANG validator and converter [PYANG] Bjorklund, M., "An extensible YANG validator and converter
in python", https://github.com/mbj4668/pyang , 2016. in python", 2016.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, DOI Information Models and Data Models", RFC 3444,
10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3444>. editor.org/info/rfc3444>.
[UDI] Kohanim, M., "Object Oriented Approach to IoT
Interoperability", Proceedings of the IoT Workshop for
Semantic Interoperability (IOTSI), 2016.
[nRF-Sniffer] [SIG] Bluetooth SIG, "GATT Specifications", 2018,
Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low <https://www.bluetooth.com/specifications/gatt>.
energy packet sniffer",
https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-
Bluetooth-low-energy/nRF-Sniffer , 2016.
Authors' Addresses Authors' Addresses
Jaime Jimenez Jaime Jimenez
Ericsson Ericsson
Email: jaime.jimenez@ericsson.com Email: jaime.jimenez@ericsson.com
Hannes Tschofenig Hannes Tschofenig
ARM Arm Ltd.
Email: hannes.tschofenig@arm.com Email: hannes.tschofenig@arm.com
Dave Thaler Dave Thaler
Microsoft Microsoft
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
 End of changes. 118 change blocks. 
328 lines changed or deleted 494 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/