draft-iab-iotsi-workshop-02.txt   rfc8477.txt 
Network Working Group J. Jimenez Internet Architecture Board (IAB) J. Jimenez
Internet-Draft Ericsson Request for Comments: 8477 H. Tschofenig
Intended status: Informational H. Tschofenig Category: Informational D. Thaler
Expires: January 3, 2019 Arm Ltd. ISSN: 2070-1721 October 2018
D. Thaler
Microsoft
July 02, 2018
Report from the Internet of Things (IoT) Semantic Interoperability Report from the Internet of Things (IoT)
(IOTSI) Workshop 2016 Semantic Interoperability (IOTSI) Workshop 2016
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)', which took place in Things (IoT) Semantic Interoperability (IOTSI)", which took place in
Santa Clara, California, on March 17-18, 2016. The main goal of the Santa Clara, California March 17-18, 2016. The main goal of the
workshop was to foster a discussion on the different approaches used workshop was to foster a discussion on the different approaches used
by companies and Standards Developing Organizations (SDOs) to by companies and Standards Developing Organizations (SDOs) 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 summarizes the discussions and lists recommendations to the standards
standards community. The views and positions in this report are community. The views and positions in this report are those of the
those of the workshop participants and do not necessarily reflect workshop participants and do not necessarily reflect those of the
those of the authors and the Internet Architecture Board (IAB), which authors or the Internet Architecture Board (IAB), which organized the
organized the workshop. workshop. 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Architecture Board (IAB)
and may be updated, replaced, or obsoleted by other documents at any and represents information that the IAB has deemed valuable to
time. It is inappropriate to use Internet-Drafts as reference provide for permanent record. It represents the consensus of the
material or to cite them other than as "work in progress." Internet Architecture Board (IAB). Documents approved for
publication by the IAB are not candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 3, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8477.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 (https://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.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 4 3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5
4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Dealing with change . . . . . . . . . . . . . . . . . . . . . 9 5. Dealing with Change . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Appendix A: Program Committee . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . 12
10. Appendix B: Accepted Position Papers . . . . . . . . . . . . 11 Appendix A. Program Committee . . . . . . . . . . . . . . . . . 14
11. Appendix C: List of Participants . . . . . . . . . . . . . . 14 Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 14
12. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix C. List of Participants . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 from 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, especially 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 of the Internet Engineering Task
Task Force (IETF). This long-term planning function of the IAB is 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.
With the expansion of the Internet of Things (IoT), interoperability With the expansion of the Internet of Things (IoT), interoperability
becomes more and more important. Standards Developing Organizations becomes more and more important. Standards Developing Organizations
(SDOs) have done a tremendous amount of work to standardize new (SDOs) have done a tremendous amount of work to standardize new
protocols, and to profile existing protocols. protocols and profile existing protocols.
At the application layer and at the level of solution frameworks, At the application layer and at the level of solution frameworks,
interoperability is not yet mature. Particularly, the work on data interoperability is not yet mature. Particularly, the work on data
formats (in the form of data models and information models) has not formats (in the form of data models and information models) has not
seen the same level of consistency throughout SDOs. seen the same level of consistency throughout SDOs.
One common problem is the lack of an encoding-independent One common problem is the lack of an encoding-independent
standardization of the information, the so-called information model. standardization of the information, the so-called information model.
Another problem is the strong relationship with the underlying Another problem is the strong relationship between data formats and
communication architecture, such as a Remote Procedure Call (RPC) the underlying communication architecture, such as a design in Remote
style design or a RESTful design. Furthermore, groups develop Procedure Call (RPC) style or a RESTful design (where REST refers to
Representational State Transfer). Furthermore, groups develop
solutions that are very similar on the surface but differ slightly in solutions that are very similar on the surface but differ slightly in
their standardized outcome, leading to interoperability problems. their standardized outcome, leading to interoperability problems.
Finally, some groups favor different encodings for use with various Finally, some groups favor different encodings for use with various
application layer protocols. 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 identify commonality
commonality and gaps [IOTSIAG][IOTSIWS]. In particular, the IAB was and gaps [IOTSIAG] [IOTSIWS]. In particular, the IAB was interested
interested to learn about the following aspects: to learn about the following aspects:
o What is the state of the art in data and information models? What o What is the state of the art in data and information models? What
should an information model look like? should an information model look like?
o What is the role of formal languages, such as schema languages, in o What is the role of formal languages, such as schema languages, in
describing information and data models? describing information and data models?
o What is the role of metadata, which is attached to data to make it o What is the role of metadata, which is attached to data to make it
self-describing? self-describing?
o How can we achieve interoperability when different organizations, o How can we achieve interoperability when different organizations,
companies and individuals develop extensions? companies, and individuals develop extensions?
o What is the experience with interworking various data models o What is the experience with interworking various data models
developed from different groups, or with data models that evolved developed from different groups, or with data models that evolved
over time? over time?
o What functionality should online repositories for sharing schemas o What functionality should online repositories for sharing schemas
have? have?
o How can existing data models be mapped against each other to offer o How can existing data models be mapped against each other to offer
interworking? interworking?
skipping to change at page 4, line 16 skipping to change at page 4, line 33
and information sharing? and information sharing?
2. Terminology 2. Terminology
The first roadblock to interoperability at the level of data models The first roadblock to interoperability at the level of data models
is the lack of a common vocabulary to start the discussion. is the lack of a common vocabulary to start the discussion.
[RFC3444] provides a starting point by separating conceptual models [RFC3444] provides a starting point by separating conceptual models
for designers, or "information models", from concrete detailed for designers, or "information models", from concrete detailed
definitions for implementers, or "data models". There are concepts definitions for implementers, or "data models". There are concepts
that are undefined in that RFC and elsewhere, such as the interaction that are undefined in that RFC and elsewhere, such as the interaction
with the resources of an endpoint, or "interaction model". Therefore with the resources of an endpoint, or "interaction model".
the three "main" common models that were identified were: Therefore, the three "main" common models that were identified were:
Information Model Information Model
An information model defines an environment at the highest level An information model defines an environment at the highest level
of abstraction and expresses the desired functionality. of abstraction and expresses the desired functionality.
Information models can be defined informally (e.g., in plain Information models can be defined informally (e.g., in prose) or
English) or more formally (e.g., UML, Entity-Relationship more formally (e.g., Unified Modeling Language (UML), Entity-
Diagrams, etc.). Implementation details are hidden. Relationship Diagrams, etc.). Implementation details are hidden.
Data Model Data Model
A data model defines concrete data representations at a lower 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 (MIB) modules, W3C Thing Description (TD) Things, YANG Base (MIB) modules, World Wide Web Consortium (W3C) Thing
models, LWM2M Schemas, OCF Schemas, and so on. Description (TD) Things, YANG modules, Lightweight Machine-to-
Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF)
Schemas, and so on.
Interaction Model Interaction Model
An interaction model defines how data is accessed and retrieved 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. The meaning can vary depending on the context that some terms have. The meaning can vary depending on the context
in which the term is used. Some examples of such terms are: in which the term is used. Some examples of such terms are as
semantics, models, encoding, serialization format, media types or follows: semantics, models, encoding, serialization format, media
encoding types. Due to time constraints, no concrete terminology was types, and encoding types. Due to time constraints, no concrete
agreed upon, but work will continue within each organization to terminology was agreed upon, but work will continue within each
create various terminology documents. The participants agreed to set organization to create various terminology documents. The
up a github repository [IOTSIGIT] for sharing information. participants agreed to set up a GitHub repository [IOTSIGIT] for
sharing information.
3. What Problems to Solve 3. What Problems to Solve
The participants agreed that there is not simply a single problem to The participants agreed that there is not simply a single problem to
be solved, but rather a range. During the workshop the following be solved but rather a range of problems. During the workshop, the
problems were discussed: following problems were discussed:
o Formal Languages for Documentation Purposes o Formal Languages for Documentation Purposes
To simplify review and publication, SDOs need formal descriptions of To simplify review and publication, SDOs need formal descriptions of
their data and interaction models. Several of them use a tabular their data and interaction models. Several of them use a tabular
representation found in the specification itself, but use a formal representation found in the specification itself but use a formal
language as an alternative way of describing objects and resources language as an alternative way of describing objects and resources
for formal purposes. Some examples of formal language use are as for formal purposes. Some examples of formal language use are as
follows. follows.
The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML schema The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema
[LWM2M-Schema] to describe their object and resource definitions. [LWM2M-Schema] to describe their object and resource definitions.
The XML files of standardized objects are available for download at The XML files of standardized objects are available for download at
[OMNA]. [OMNA].
The Bluetooth SIG defined Generic Attributes (GATT) services and The Bluetooth Special Interest Group (SIG) defined Generic Attribute
characteristics for use with Bluetooth Smart/Low Energy. The Profile (GATT) services and characteristics for use with Bluetooth
services and characteristics are shown in a tabular form on the Smart/Low Energy. The services and characteristics are shown in a
Bluetooth SIG website at [SIG], and are also defined as XML instance tabular form on the Bluetooth SIG website [SIG] and are defined as
documents. XML instance documents.
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally The Open Connectivity Foundation (OCF) uses JSON Schemas to formally
define data models, and RAML to define interaction models. The define data models and RESTful API Modeling Language (RAML) to define
standard files are available online at OneIoTa.org. interaction models. The standard files are available online at
<oneIoTa.org>.
The AllSeen Alliance uses AllJoyn Introspection XML to define data The AllSeen Alliance uses AllJoyn Introspection XML to define data
and interaction models in the same formal language, tailored for RPC- and interaction models in the same formal language, tailored for
style interaction. The standard files are available online on the RPC-style interaction. The standard files are available online on
AllSeen Alliance web site, but both standard and vendor-defined model the AllSeen Alliance website, but both standard and vendor-defined
files can be obtained by directly querying a device for them at model files can be obtained by directly querying a device for them at
runtime. runtime.
The World-Wide Web Consortium (W3C) uses the Resource Description The World Wide Web Consortium (W3C) uses the Resource Description
Framework (RDF) to define data and interaction models using a format Framework (RDF) to define data and interaction models using a format
tailored for the web. tailored for the web.
The Internet Engineering Task Force (IETF) uses YANG to define data The Internet Engineering Task Force (IETF) uses YANG to define data
and interaction models. Other SDOs may use various other formats. and interaction models. Other SDOs may use various other formats.
o Formal Languages for Code Generation o Formal Languages for Code Generation
Code generation tools that use formal data and information modelling Code-generation tools that use formal data and information modeling
languages are needed by developers. For example, the AllSeen Visual languages are needed by developers. For example, the AllSeen Visual
Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based
on the formal description of the data model. Another example of a on the formal description of the data model. Another example of a
data modelling language that can be used for code generation is YANG. data modeling language that can be used for code generation is YANG.
A 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]. An example of a tool that can do code generation for [PYANG]. An example of a tool that can generate code for multiple
multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for ecosystems is OpenDOF [OpenDOF]. Use cases discussed for code
code generation included easing development of server-side device generation included easing development of server-side device
functionality, clients, and compliance tests. functionality, clients, and compliance tests.
o Debugging Support o Debugging Support
Debugging tools are needed that implement generic object browsers, Debugging tools are needed that implement generic object browsers,
which use standard data models and/or retrieve formal language which use standard data models and/or retrieve formal language
descriptions from the devices themselves. As one example, the NRF descriptions from the devices themselves. As one example, the nRF
Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can
be used to display services and characteristics defined by the be used to display services and characteristics defined by the
Bluetooth SIG. As another example, AllJoyn Explorer Bluetooth SIG. As another example, AllJoyn Explorer
[AllJoynExplorer] can be used to browse and interact with any [AllJoynExplorer] can be used to browse and interact with any
resource exposed by an AllJoyn device, including both standard and resource exposed by an AllJoyn device, including both standard and
vendor-defined data models, by retrieving the formal descriptions vendor-defined data models, by retrieving the formal descriptions
from the device at runtime. from the device at runtime.
o Translation o Translation
The working assumption is that devices need to have a common data The working assumption is that devices need to have a common data
model with a priori knowledge of data types and actions. However model with a priori knowledge of data types and actions. However,
that would imply that each consortium/organization will try to define that would imply that each consortium/organization will try to define
their own, causing a major interoperability problem, if not a their own data model. That would cause a major interoperability
completely intractable one given the amount of variations, problem, possibly a completely intractable one given the number of
extensions, compositions or versioning changes that will happen on a variations, extensions, compositions, or versioning changes that will
per data model basis. happen for each data model.
Another potential approach is to have a minimal ammount of Another potential approach is to have a minimal amount of information
information on the device to allow for a runtime binding to a on the device to allow for a runtime binding to a specific model, the
specific model, the objective being to require as little prior objective being to require as little prior knowledge as possible.
knowledge as possible.
Moreover, gateways, bridges and other similar devices need to Moreover, gateways, bridges and other similar devices need to
dynamically translate (or map) one data model to another one. dynamically translate (or map) one data model to another one.
Complexity will increase as there are also multiple protocols and Complexity will increase as there are also multiple protocols and
schemas that make interoperability harder to achieve. schemas that make interoperability harder to achieve.
o Runtime Discovery o Runtime Discovery
Runtime discovery allows IoT devices to exchange metadata about the Runtime discovery allows IoT devices to exchange metadata about the
data, potentially along with the data exchanged itself. In some data, potentially along with the data exchanged itself. In some
cases the metadata not only describes data but also the interaction cases, the metadata not only describes data but also the interaction
model as well. An example of such an approach has been shown with model as well. An example of such an approach has been shown with
HATEOAS [HATEOAS]. Another example is that all AllJoyn devices Hypermedia as the Engine of Application State (HATEOAS) [HATEOAS].
support such runtime discovery using a protocol mechanism called Another example is that all AllJoyn devices support such runtime
"introspection", where the metadata is queried from the device itself discovery using a protocol mechanism called "introspection", where
[AllSeen]. the metadata is queried from the device itself [AllSeen].
There are various models, whether deployed or possible, for such There are various models, whether deployed or possible, for such
discovery. The metadata might be extracted from a specification, or discovery. The metadata might be extracted from a specification,
looked up on a cloud repository (e.g., OneIoTa for OCF models), or looked up on a cloud repository (e.g., oneIoTa for OCF models),
looked up via a vendor's site, or obtained from the device itself looked up via a vendor's site, or obtained from the device itself
(such as in the AllJoyn case). The relevant metadata might be (such as in the AllJoyn case). The relevant metadata might be
obtained from the same place, or different pieces might be obtained obtained from the same place or different pieces might be obtained
from different places, such as separately obtaining information such from different places, such as separately obtaining (a) syntax
as (a) syntax information, (b) end-user descriptions in a desired information, (b) end-user descriptions in a desired language, and (c)
language, and (c) developer-specific comments for implementers. developer-specific comments for implementers.
4. Translation 4. Translation
In an ideal world where organizations and companies cooperate and In an ideal world where organizations and companies cooperate and
agree on a single data model standard, there is no need for gateways agree on a single data model standard, there is no need for gateways
that translate from one data model to the other one. However, this that translate from one data model to another one. However, this is
is far from reality today, and there are many proprietary data models far from reality today, and there are many proprietary data models in
in addition to the already standardized ones. As a consequence, addition to the already standardized ones. As a consequence,
gateways are needed to translate between data models. This leads to gateways are needed to translate between data models. This leads to
(n^2)-n combinations, in the worst case. (n^2)-n combinations, in the worst case.
There are analogies with gateways back in the 1980s that were used to There are analogies with gateways back in the 1980s that were used to
translate between network layer protocols. Eventually IP took over, translate between network layer protocols. Eventually, IP took over,
providing the necessary end-to-end interoperability at the network providing the necessary end-to-end interoperability at the network
layer. Unfortunately, the introduction of gateways leads to the loss layer. Unfortunately, the introduction of gateways leads to the loss
of expressiveness due to the translation between data models. The of expressiveness due to the translation between data models. The
functionality of IP was so valuable in the market that advanced functionality of IP was so valuable in the market that advanced
features of other networking protocols became less attractive and features of other networking protocols became less attractive and
were not used anymore. were not used anymore.
Participants discussed an alternative which they called a 'red star', Participants discussed an alternative that they called a "red star",
shown in Figure 1, where data models are translated to a common data shown in Figure 1, where data models are translated to a common data
model shown in the middle. This reduces the number of translations model shown in the middle. This reduces the number of translations
that are needed down to 2n (in the best case). The problem, of that are needed down to 2n (in the best case). The problem, of
course, is that everyone wants their own data model to be the red course, is that everyone wants their own data model to be the red
star in the center. star in the center.
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| | -- -- | | | | -- -- | |
| | -- -- | | | | -- -- | |
skipping to change at page 8, line 30 skipping to change at page 8, line 41
-- -- -- --
-- -- -- --
-- -- -- --
-- -- -- --
/\ -- -- /\ /\ -- -- /\
/ \ -- -- / \ / \ -- -- / \
/ \ / \ / \ / \
/ \ / \ / \ / \
/--------\ /--------\ /--------\ /--------\
Figure 1: The 'Red Star' in Data/Information Models. Figure 1: The "Red Star" in Data/Information Models
While the workshop itself was not a suitable forum to discuss the While the workshop itself was not a suitable forum to discuss the
design of such translation in detail, several questions were raised: design of such translation in detail, several questions were raised:
o Do we need a "red star" that does everything or could we design o Do we need a "red star" that does everything, or could we design
something that offers a more restricted functionality? something that offers a more restricted functionality?
o How do we handle loss of data and loss of functionality? o How do we handle loss of data and functionality?
o Should data be translated between data models, or should data
o Should data be translated between data models or data models be models themselves be translated?
translated?
o How can interaction models be translated? They need to be dealt o How can interaction models be translated? They need to be dealt
with in addition to the data models. with in addition to the data models.
o Many (if not all) data and interaction models have some bizarre o Many (if not all) data and interaction models have some bizarre
functionality that cannot be translated easily. How can those be functionality that cannot be translated easily. How can those be
handled? handled?
o What limitations are we going to accept in these translations? o What limitations are we going to accept in these translations?
The participants also addressed the question of when translation The participants also addressed the question of when translation
should be done. Two use cases were discussed: should be done. Two use cases were discussed:
a) Design time: a translation between data model descriptions, such (a) Design time: A translation between data model descriptions, such
as translating a YANG model to a RAML/JSON model, can be performed as translating a YANG module to a RAML/JSON model, can be
once, during design time. A single information model might be mapped performed once, during design time. A single information model
to a number of different data models. might be mapped to a number of different data models.
b) Run time: Runtime translation of values in two standard data (b) Run time: Runtime translation of values in two standard data
models can only be algorithmically done when the data model on one models can only be algorithmically done when the data model on
side is algorithmically derived from the data model on the other one side is algorithmically derived from the data model on the
side. This was called a "derived model". It was discussed that the other side. This was called a "derived model". It was
availability of runtime discovery can aid in semantic translation, discussed that the availability of runtime discovery can aid in
such as when a vendor-specific data model on one side of a protocol semantic translation, such as when a vendor-specific data model
bridge is resolved and the translator can algorithmically derive the on one side of a protocol bridge is resolved and the translator
semantically-equivalent vendor-specific data model on the other side can algorithmically derive the semantically equivalent vendor-
of a protocol bridge, as discussed in [BridgeTaxonomy]. specific data model on the other side. This situation is
discussed in [BridgeTaxonomy].
The participants agreed that algorithm translation will generally The participants agreed that algorithm translation will generally
require custom code, whenever one is translating to anything other require custom code whenever one is translating to anything other
than a derived model. than a derived model.
Participants concluded that it is typically easier to translate data Participants concluded that it is typically easier to translate data
between systems that follow the same communication architecture. between systems that follow the same communication architecture.
5. Dealing with change 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. Interactions between devices devices and server-side applications. Interactions between devices
and services and how their relationship evolves over time is and services and how their relationship evolves over time is
complicated by their respective different interaction models. complicated by their respective interaction models.
The workshop participants discussed various approaches to deal with The workshop participants discussed various approaches to deal with
change. In the most basic case, a developer might use a description change. In the most basic case, a developer might use a description
of an API and implement the protocol steps. Sometimes the data or of an API and implement the protocol steps. Sometimes, the data or
information model can be used to generate code stubs. Subsequent information model can be used to generate code stubs. Subsequent
changes to an API require changes on the clients to upgrade to the changes to an API require changes on the clients to upgrade to the
new version, which requires some development of new code to satisfy new version, which requires some development of new code to satisfy
the needs of the new API. the needs of the new API.
These interactions could be made machine-understandable in the first These interactions could be made machine understandable in the first
place, enabling for changes to happen at runtime. In that scenario, place, enabling for changes to happen at runtime. In that scenario,
a machine client could 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 code the human-readable specification The challenge seems to be to code the human-readable specification
into a machine-readable format. Machine-readable languages require a into a machine-readable format. Machine-readable languages require a
shared vocabulary to give meaning to the tags. shared vocabulary to give meaning to the tags.
These types of interactions are often based on the REST architectural These types of interactions are often based on the REST architectural
style. Its principle is that a device or endpoint only needs a style. Its principle is that a device or endpoint only needs a
single entry point with a host providing descriptions of the API in- single entry point, with a host providing descriptions of the API
band by means of web links and forms. in-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 a RESTful interactions through links instead of hard-coding 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 a
in progress. However, some of the existing mechanisms can be reused, work in progress. However, some of the existing mechanisms can be
such as resource discovery, forms, or links. reused, such as resource discovery, forms, or links.
6. Security Considerations 6. IANA Considerations
This document has no IANA actions.
7. Security Considerations
There were two types of security considerations discussed: use of There were two types of security considerations discussed: use of
formal data models for security configuration, and security of data formal data models for security configuration and security of data
and data models in general. and data models in general.
It was observed that the security assumptions and configuration, or It was observed that the security assumptions and configuration, or
"security model", varies by ecosystem today, making the job of a "security model", varies by ecosystem today, making the job of a
translator difficult. For example, the types of security principals translator difficult. For example, there are different types of
(e.g., user vs. device vs. application), the use of access control security principals (e.g., user vs. device vs. application), the use
lists (ACLs) vs. capabilities, and what types of policies can be of Access Control Lists (ACLs) versus capabilities, and what types of
expressed, all vary by ecosystem. As a result, the security model policies can be expressed, all vary by ecosystem. As a result, the
architecture generally dictates where translation can be done. security model architecture generally dictates where translation can
be done.
One approach discussed was whether two endpoints might be able to use One approach discussed was whether two endpoints might be able to use
some overlay security model, across a translator between two some overlay security model across a translator between two
ecosystems, which only works if the two endpoints agree on a common ecosystems, which only works if the two endpoints agree on a common
data model for their communication. Another approach discussed was data model for their communication. Another approach discussed was
simply having a translator act as a trusted intermediary, which simply having a translator act as a trusted intermediary, which
allows the translator to be able to translate between different data enables the translator to translate between different data models.
models.
One suggestion discussed was potentially adding metadata into either One suggestion discussed was either adding metadata into the formal
the formal data model language, or accompanying the data values over data model language or having it accompany the data values over the
the wire, tagging the data with privacy levels. However, sometimes wire, tagging the data with privacy levels. However, sometimes even
even the privacy level of information might itself be sensitive. the privacy level of information might itself be sensitive. Still,
Still, it was observed that being able to dynamically learn security it was observed that being able to dynamically learn security
requirements might help provide better UIs and translators. requirements might help provide better UIs and translators.
7. Collaboration 8. Collaboration
The participants discussed how best to share information among their The participants discussed how best to share information among their
various organizations. One discussion was around having joint various organizations. One discussion was around having joint
meetings. One current challenge reported was that organizations were meetings. One current challenge reported was that organizations were
not aware of when and where each others' meetings were scheduled, and not aware of when and where each other's meetings were scheduled, and
sharing such information could help organizations better collocate sharing such information could help organizations better collocate
meetings. To facilitate this exchange, the participants agreed to meetings. To facilitate this exchange, the participants agreed to
add links to their respective meeting schedules from a common page in add links to their respective meeting schedules from a common page in
the IOTSI repository [IOTSIGIT]. the IOTSI repository [IOTSIGIT].
Another challenge reported was that organizations did not know how to Another challenge reported was that organizations did not know how to
find each others' published data models, and sharing such information find each other's published data models, and sharing such information
could better facilitate reuse of the same information model. To could better facilitate reuse of the same information model. To
facilitate this exchange, this participants discussed whether a facilitate this exchange, the participants discussed whether a common
common repository might be used by multiple organizations. The OCF's repository might be used by multiple organizations. The OCF's
OneIoTa repository was discussed as one possibility but it was oneIoTa repository was discussed as one possibility, but it was
reported that its terms of use at the time of the workshop prevented 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 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 terms of use to allow other organizations to use it, as the
restriction was not the intent. Schema.org was discussed as another restriction was not the intent. <schema.org> was discussed as
possibility. In the meantime, the participants agreed to add links another possibility. In the meantime, the participants agreed to add
to their respective repositories from a common page in the IOTSI links to their respective repositories from a common page in the
repository [IOTSIGIT]. IOTSI repository [IOTSIGIT].
It was also agreed that the iotsi@iab.org mailing list would remain It was also agreed that the iotsi@iab.org mailing list would remain
open and available for sharing information between all relevant open and available for sharing information between all relevant
organizations. organizations.
8. Acknowledgements 9. Informative References
We would like to thank all paper authors and participants for their [AllJoynExplorer]
contributions, and Ericsson for hosting the workshop. Microsoft, "AllJoyn".
9. Appendix A: Program Committee [AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to
Semantic Interoperability", 2016, <https://www.iab.org/
wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>.
[AllSeen-Plugin]
Rockwell, B., "Using the AllJoyn Studio Extension", August
2015.
[BridgeTaxonomy]
Thaler, D., "IoT Bridge Taxonomy", IAB IOTSI
Workshop 2016, <https://www.iab.org/wp-content/
IAB-uploads/2016/03/DThaler-IOTSI.pdf>.
[HATEOAS] Kovatsch, M., Hassan, Y., and K. Hartke, "Semantic
Interoperability Requires Self-describing Interaction
Models: HATEOAS for the Internet of Things", Proceedings
of the IAB IoT Semantic Interoperability Workshop 2016,
<https://www.iab.org/wp-content/
IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf>.
[IOTSIAG] IAB, "IoT Semantic Interoperability Workshop Agenda",
2016,
<https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIGIT]
"Starting place for the IoT Semantic Interoperability
Workshop (IOTSI) Information Resource", commit ff21f74,
July 2018, <https://github.com/iotsi/iotsi>.
[IOTSIWS] IAB, "IoT Semantic Interoperability Workshop 2016", 2016,
<https://www.iab.org/activities/workshops/iotsi/>.
[LWM2M-Schema]
OMA, "LWM2M XML Schema - LWM2M Editor Schema", July 2018.
[nRF-Sniffer]
Nordic Semiconductor, "nRF Sniffer: Smart/Bluetooth low
energy packet sniffer".
[OMNA] OMA, "OMA LightweightM2M (LwM2M) Object and Resource
Registry".
[OpenDOF] OpenDOF, "The OpenDOF Project", <https://opendof.org>.
[PYANG] "An extensible YANG validator and converter in python",
commit 15c807f, September 2018,
<https://github.com/mbj4668/pyang>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[SIG] Bluetooth SIG, "GATT Specifications",
<https://www.bluetooth.com/specifications/gatt>.
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.
10. Appendix B: Accepted Position Papers Appendix B. Accepted Position Papers
o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever" o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
o Carsten Bormann, "Noise in specifications hurts" o Carsten Bormann, "Noise in Specifications hurts"
o 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"
o Robert Cragie, "The ZigBee Cluster Library over IP" o Robert Cragie, "The ZigBee Cluster Library over IP"
o Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair: o Dee Denteneer, Michael Verschoor, and 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"
o Universal Devices, "Object Oriented Approach to IoT o Universal Devices, "Object Oriented Approach to IoT
Interoperability" Interoperability"
o Bryant Eastham, "Interoperability and the OpenDOF Project" o Bryant Eastham, "Interoperability and the OpenDOF Project"
o Stephen Farrell, Alissa Cooper, "It's Often True: Security's o Stephen Farrell and Alissa Cooper, "It's Often True: Security's
Ignored (IOTSI) - and Privacy too" Ignored (IOTSI) - and Privacy too"
o Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT semantics o Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT
landscape" semantics landscape"
o Ted Hardie, "Loci of Interoperability for the Internet of Things" o Ted Hardie, "Loci of Interoperability for the Internet of Things"
o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure
Communications" Communications"
o Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart o Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart
Objects" Objects"
o David Jones, IOTDB - "Interoperability Through Semantic o David Jones, "IOTDB - interoperability Through Semantic
Metastandards" Metastandards"
o Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler of o Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler
Semantic Interoperability on the Web of Things" of Semantic Interoperability on the Web of Things"
o 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"
o Ari Keraenen, Cullen Jennings, "SenML: simple building block for o Ari Keraenen and Cullen Jennings, "SenML: simple building block
IoT semantic interoperability" for IoT semantic interoperability"
o Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on Unified o Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on
Data Model and Framework to Support Interoperability between IoT Unified Data Model and Framework to Support Interoperability
Applications" between IoT Applications"
o Michael Koster, "Model-Based Hypertext Language" o Michael Koster, "Model-Based Hypertext Language"
o Matthias Kovatsch, Yassin N. Hassan, Klaus Hartke, "Semantic o Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, "Semantic
Interoperability Requires self describing Interaction Models" Interoperability Requires Self-describing Interaction Models"
o 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"
o Barry Leiba, "Position Paper" o Barry Leiba, "Position Paper"
o Marcello Lioy, "AllJoyn" o Marcello Lioy, "AllJoyn"
o Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON Hyper- o Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON
Schema" Hyper-Schema"
o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope
of security issues" of security issues"
o 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"
o Jean Paoli, Taqi Jaffri, "IoT Information Model Interoperability: o Jean Paoli and Taqi Jaffri, "IoT Information Model
An Open, Crowd-Sourced Approach in Three Parallel Parti" Interoperability: An Open, Crowd-Sourced Approach in Three
Parallel Parti"
o Joaquin Prado, "OMA Lightweight M2M Resource Model" o Joaquin Prado, "OMA Lightweight M2M Resource Model"
o Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic o Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic
Interoperability Workshop" Interoperability Workshop"
o Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable Data o Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable
to Facilitate Time and Context Specific Interoperability" Data to Facilitate Time and Context Specific Interoperability"
o Jasper Roes, Laura Daniele, "Towards semantic interoperability in o Jasper Roes and Laura Daniele, "Towards semantic interoperability
the IoT using the Smart Appliances REFerence ontology (SAREF) and in the IoT using the Smart Appliances REFerence ontology (SAREF)
its extensions" and its extensions"
o Max Senges, "Submission for IAB IoT Sematic Interoperability o Max Senges, "Submission for IAB IoT Sematic Interoperability
workshop" workshop"
o Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation o Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation
Experiences of Semantic Interoperability for RESTful Gateway Experiences of Semantic Interoperability for RESTful Gateway
Management" Management"
o Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic o Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic
Interoperability Gaps in the Internet-of-Things Meta-Models" Interoperability Gaps in the Internet-of-Things Meta-Models"
o Robert Sparks and Ben Campbell, "Considerations for certain IoT o Robert Sparks and Ben Campbell, "Considerations for certain IoT-
based services" based services"
o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool" o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
o J. Clarke Stevens, Piper Merriam, "Derived Models for o J. Clarke Stevens and Piper Merriam, "Derived Models for
Interoperability Between IoT Ecosystems" Interoperability Between IoT Ecosystems"
o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity
Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"" Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"
o Andrew Sullivan, "Position paper for IOTSI workshop" o Andrew Sullivan, "Position paper for IOTSI workshop"
o Darshak Thakore, "IoT Security in the context of Semantic o Darshak Thakore, "IoT Security in the context of Semantic
Interoperability" Interoperability"
o Dave Thaler, "IoT Bridge Taxonomy" o Dave Thaler, "IoT Bridge Taxonomy"
o Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to o Dave Thaler, "Summary of AllSeen Alliance Work Relevant to
Semantic Interoperability" Semantic Interoperability"
o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike
Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram, "Internet Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram,
of Things: Toward Smart Networked Systems and Societies" "Internet of Things: Toward Smart Networked Systems and Societies"
o Peter van der Stok, Andy Bierman, "YANG-Based Constrained o Peter van der Stok and Andy Bierman, "YANG-Based Constrained
Management Interface (CoMI)" Management Interface (CoMI)"
11. Appendix C: List of Participants Appendix C. List of Participants
o Andy Bierman, YumaWorks
o Carsten Bormann, Uni Bremen/TZI
o Ben Campbell, Oracle
o Benoit Claise, Cisco
o Alissa Cooper, Cisco
o Robert Cragie, ARM Limited
o Laura Daniele, TNO
o Bryant Eastham, OpenDOF
o Christian Groves, Huawei
o Ted Hardie, Google
o Yonggeun Hong, ETRI
o Russ Housley, Vigil Security
o David Janes, IOTDB
o Jaime Jimenez, Ericsson
o Shailendra Karody, Catalina Labs
o Ari Keraenen, Ericsson
o Michael Koster, SmartThings
o Matthias Kovatsch, Siemens
o Kai Kreuzer, Deutsche Telekom
o Barry Leiba, Huawei
o Steve Liang, Uni Calgary
o Marcello Lioy, Qualcomm
o Kerry Lynn, Verizon
o Mayan Mathen, Catalina Labs
o Erik Nordmark, Arista
o Jean Paoli, Microsoft
o Joaquin Prado, OMA
o Dave Raggett, W3C
o Max Senges, Google
o Ned Smith, Intel
o Robert Sparks, Oracle
o Ram Sriram, NIST
o Clarke Stevens
o Ram Subramanian, Intel
o Andrew Sullivan, DIN
o Darshak Thakore, CableLabs
o Dave Thaler, Microsoft
o Hannes Tschofenig, ARM Limited
o Michael Verschoor, Philips Lighting
12. Informative References
[AllJoynExplorer]
Microsoft, "AllJoyn Explorer", 2016.
[AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to
Semantic Interoperability", 2016, <https://www.iab.org/wp-
content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>.
[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) -
Agenda and Slides", 2016,
<https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIGIT]
IOTSI, "Github Collaborative Repository", 2016,
<https://github.com/iotsi/iotsi>.
[IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI)
2016 - Main Page and Position Papers", 2016,
<https://www.iab.org/activities/workshops/iotsi/>.
[LWM2M-Schema]
OMA, "OMA LWM2M XML Schema", 2018.
[nRF-Sniffer]
Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low
energy packet sniffer", 2016.
[OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource Andy Bierman, YumaWorks
Registry", 2018. Carsten Bormann, Uni Bremen/TZI
Ben Campbell, Oracle
Benoit Claise, Cisco
Alissa Cooper, Cisco
Robert Cragie, ARM Limited
Laura Daniele, TNO
Bryant Eastham, OpenDOF
Christian Groves, Huawei
Ted Hardie, Google
Yonggeun Hong, ETRI
Russ Housley, Vigil Security
David Janes, IOTDB
Jaime Jimenez, Ericsson
Shailendra Karody, Catalina Labs
Ari Keraenen, Ericsson
Michael Koster, SmartThings
Matthias Kovatsch, Siemens
Kai Kreuzer, Deutsche Telekom
Barry Leiba, Huawei
Steve Liang, Uni Calgary
Marcello Lioy, Qualcomm
Kerry Lynn, Verizon
Mayan Mathen, Catalina Labs
Erik Nordmark, Arista
Jean Paoli, Microsoft
Joaquin Prado, OMA
Dave Raggett, W3C
Max Senges, Google
Ned Smith, Intel
Robert Sparks, Oracle
Ram Sriram, NIST
Clarke Stevens
Ram Subramanian, Intel
Andrew Sullivan, DIN
Darshak Thakore, CableLabs
Dave Thaler, Microsoft
Hannes Tschofenig, ARM Limited
Michael Verschoor, Philips Lighting
[OpenDOF] OpenDOF, "The OpenDOF Project", 2015, IAB Members at the Time of Approval
<https://opendof.org>.
[PYANG] Bjorklund, M., "An extensible YANG validator and converter Jari Arkko
in python", 2016. Alissa Cooper
Ted Hardie
Christian Huitema
Gabriel Montenegro
Erik Nordmark
Mark Nottingham
Melinda Shore
Robert Sparks
Jeff Tantsura
Martin Thomson
Brian Trammell
Suzanne Woolf
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Acknowledgements
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, <https://www.rfc-
editor.org/info/rfc3444>.
[SIG] Bluetooth SIG, "GATT Specifications", 2018, We would like to thank all paper authors and participants for their
<https://www.bluetooth.com/specifications/gatt>. contributions and Ericsson for hosting the workshop.
Authors' Addresses Authors' Addresses
Jaime Jimenez Jaime Jimenez
Ericsson
Email: jaime.jimenez@ericsson.com Email: jaime.jimenez@ericsson.com
Hannes Tschofenig Hannes Tschofenig
Arm Ltd.
Email: hannes.tschofenig@arm.com Email: hannes.tschofenig@arm.com
Dave Thaler Dave Thaler
Microsoft
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
 End of changes. 106 change blocks. 
352 lines changed or deleted 337 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/