rfc-xmldiff rfc8477.original.xml rfc8477.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>

<rfc docName="draft-iab-iotsi-workshop-02" category="info" submissionType="IETF">

  <front>
    <title abbrev="draft-iab-iotsi-workshop">Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016</title>

    <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
      <organization>Ericsson</organization>
      <address>
        <email>jaime.jimenez@ericsson.com</email>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Arm Ltd.</organization>
      <address>
        <email>hannes.tschofenig@arm.com</email>
      </address>
    </author>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</organization>
      <address>
        <email>dthaler@microsoft.com</email>
      </address>
    </author>

    <date year="2018" month="July" day="02"/>

    
    
    

    <abstract>


<t>This document provides a summary of the ‘Workshop on Internet of
Things (IoT) Semantic Interoperability (IOTSI)’,
which took place in Santa Clara, California, on March 17-18, 2016.  The main
goal of the workshop was to foster a discussion on the different
approaches used by companies and Standards Developing Organizations (SDOs)
to accomplish interoperability at the application layer.  This report
summarizes the discussions, and lists recommendations to the standards
community.  The views and positions in this report are those of the
workshop participants and do not necessarily reflect those of the
authors and the Internet Architecture Board (IAB), which organized
the workshop.</t>



    </abstract>


  </front>

  <middle>


<section anchor="section-1" title="Introduction">

<t>The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture.  The investigated topics often require coordinated
efforts of many organizations and industry bodies to improve an
identified problem.  One of the targets of the workshops is to
establish communication between relevant organizations, especially
when the topics are out of the scope for the Internet Engineering
Task Force (IETF).  This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the IETF.</t>

<t>With the expansion of the Internet of Things (IoT), interoperability
becomes more and more important. Standards Developing Organizations (SDOs)
have done a tremendous amount of work to standardize new protocols,
and to profile existing protocols.</t>

<t>At the application layer and at the level of solution frameworks, 
interoperability is not yet mature. Particularly, the
work on data formats (in the form of data models and information
models) has not seen the same level of consistency throughout
SDOs.</t>

<t>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.</t>

<t>Thus, the IAB decided to organize a workshop to reach out to relevant
stakeholders to explore the state-of-the-art and to identify
commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
interested to learn about the following aspects:</t>

<t><list style="symbols">
  <t>What is the state of the art in data and information models? What should
an information model look like?</t>
  <t>What is the role of formal languages, such as schema languages, in
describing information and data models?</t>
  <t>What is the role of metadata, which is attached to data to make it self-describing?</t>
  <t>How can we achieve interoperability when different organizations, companies
and individuals develop extensions?</t>
  <t>What is the experience with interworking various data models developed
from different groups, or with data models that evolved over time?</t>
  <t>What functionality should online repositories for sharing schemas have?</t>
  <t>How can existing data models be mapped against each other to offer interworking?</t>
  <t>Is there room for harmonization, or are the use cases of different groups
and organizations so unique that there is no possibility for cooperation?</t>
  <t>How can organizations better work together to increase awareness and information sharing?</t>
</list></t>

</section>
<section anchor="section-2" title="Terminology">

<t>The first roadblock to interoperability at the level of data models is the lack of a
common vocabulary to start the discussion.
<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
or “information models”, from concrete detailed definitions for implementers, or
“data models”. There are concepts that are
undefined in that RFC and elsewhere, such as the interaction with the
resources of an endpoint, or “interaction model”.  Therefore the three
“main” common models that were identified were:</t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Information Model'><vspace blankLines='0'/>
  An information model defines an environment at the highest level of abstraction and
expresses the desired functionality.
Information models can be defined informally (e.g., in plain English) or more
formally (e.g., UML, Entity-Relationship Diagrams, etc.).
Implementation details are hidden.</t>
</list></t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Data Model'><vspace blankLines='0'/>
  A data model defines concrete data representations at a lower level of
abstraction, including implementation and protocol-specific details.
Some examples are: SNMP Management Information
Base (MIB) modules, W3C Thing Description (TD) Things, YANG models, LWM2M
Schemas, OCF Schemas, and so on.</t>
</list></t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Interaction Model'><vspace blankLines='0'/>
  An interaction model defines how data is accessed and retrieved from the endpoints,
being therefore tied to the specific
communication pattern that the system has (e.g., REST methods,
Publish/Subscribe operations, or RPC calls).</t>
</list></t>

<t>Another identified terminology issue is the semantic meaning overload
that some terms have.  The meaning can vary depending on the context in which the
term is used.  Some examples of such terms are: semantics, models,
encoding, serialization format, media types or encoding types.  Due
to time constraints, no concrete terminology was agreed upon, but
work will continue within each organization to create various
terminology documents.  The participants agreed to set up a github repository
<xref target="IOTSIGIT"/> for sharing information.</t>

</section>
<section anchor="section-4" title="What Problems to Solve">

<t>The participants agreed that there is not simply a single problem to be solved, but
rather a range. During the workshop the following problems were discussed:</t>

<t><list style="symbols">
  <t>Formal Languages for Documentation Purposes</t>
</list></t>

<t>To simplify review and publication, SDOs need
formal descriptions of their data and interaction models.
Several of them use a tabular 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.</t>

<t>The Open Mobile Alliance (OMA), now OMA SpecWorks,
used an XML schema <xref target="LWM2M-Schema"/> to describe their object
and resource definitions. The XML files of standardized objects are available for download at
<xref target="OMNA"/>.</t>

<t>The Bluetooth SIG defined Generic Attributes (GATT) services and characteristics for use with 
Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on 
the Bluetooth SIG website at <xref target="SIG"/>, and are also defined as XML instance documents.</t>

<t>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.</t>

<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
models in the same formal language, tailored for RPC-style interaction.  The standard
files are available online on the AllSeen Alliance web site, but both standard and
vendor-defined model files can be obtained by directly querying a device for them at runtime.</t>

<t>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.</t>

<t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models.
Other SDOs may use various other formats.</t>

<t><list style="symbols">
  <t>Formal Languages for Code Generation</t>
</list></t>

<t>Code generation tools that use formal data and information modelling languages
are needed by developers. For example, the AllSeen Visual Studio
Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
the formal description of the data model.  Another example of a data
modelling language that can be used for code generation is YANG.  A
popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>.
An example of a tool that can do code generation for multiple ecosystems is
OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
development of server-side device functionality, clients, and compliance tests.</t>

<t><list style="symbols">
  <t>Debugging Support</t>
</list></t>

<t>Debugging tools are needed that implement generic object browsers, which
use standard data models and/or retrieve formal language descriptions
from the devices themselves. As one example, the
NRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
used to display services and characteristics defined by the Bluetooth SIG.
As another example, AllJoyn Explorer <xref target="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.</t>

<t><list style="symbols">
  <t>Translation</t>
</list></t>

<t>The working assumption is that devices need to have a common data 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.</t>

<t>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.</t>

<t>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.</t>

<t><list style="symbols">
  <t>Runtime Discovery</t>
</list></t>

<t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the
data exchanged itself. In some cases the metadata not only describes data but also the interaction model as well. 
An example of such an approach has been shown with HATEOAS <xref target="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 <xref target="AllSeen"/>.</t>

<t>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.</t>

</section>
<section anchor="section-5" title="Translation">

<t>In an ideal world where organizations and companies cooperate and 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 is far from reality today, and there are many
proprietary data models in addition to the already standardized ones. As a 
consequence, gateways are needed to translate between data models. This leads to 
(n^2)-n combinations, in the worst case.</t>

<t>There are analogies with gateways back in the 1980s that were used to
translate between network layer protocols.  Eventually IP took over, providing
the necessary end-to-end interoperability at the network 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.</t>

<t>Participants discussed an alternative which they called a ‘red star’, shown in <xref target="red-star"/>, 
where data models are translated to a common data model shown in the middle. This 
reduces the number of translations 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 star in the center.</t>

<figure title="The 'Red Star' in Data/Information Models." anchor="red-star"><artwork><![CDATA[
   +-----+                                        +-----+
   |     |                                        |     |
   |     |  --                                 -- |     |
   |     |    --                             --   |     |
   +-----+      --                         --     +-----+
                  --                    ---
                    --                --
                      --            --
                        --        --
     ---                  -- A  --                  ---
    /   \                ___/ \___                 /   \
   |     | ---------------',   .'---------------  |     |
    \   /                 /. ^ .\                  \   /
     ---                 /'     '\                  ---   
                        --        --
                      --            --
                    --                --
                  --                    --
                --                        --
       /\     --                            --     /\
      /  \  --                                --  /  \
     /    \                                      /    \
    /      \                                    /      \
   /--------\                                  /--------\
]]></artwork></figure>

<t>While the workshop itself was not a suitable forum to discuss the design of 
such translation in detail, several questions were raised:</t>

<t><list style="symbols">
  <t>Do we need a “red star” that does everything or could we design something that 
offers a more restricted functionality?</t>
  <t>How do we handle loss of data and loss of functionality?</t>
  <t>Should data be translated between data models or data models be translated?</t>
  <t>How can interaction models be translated? They need to be dealt with in addition 
 to the data models.</t>
  <t>Many (if not all) data and interaction models have some bizarre functionality 
 that cannot be translated easily. How can those be handled?</t>
  <t>What limitations are we going to accept in these translations?</t>
</list></t>

<t>The participants also addressed the question of when translation should be done.
Two use cases were discussed:</t>

<t>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.</t>

<t>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 <xref target="BridgeTaxonomy"/>.</t>

<t>The participants agreed that algorithm translation will generally require
custom code, whenever one is translating to anything other than a derived model.</t>

<t>Participants concluded that it is typically easier to translate data between systems that
follow the same communication architecture.</t>

</section>
<section anchor="section-6" title="Dealing with change">

<t>A large part of the workshop was dedicated to the evolution of
devices and server-side applications.
Interactions between devices and services and how their relationship
evolves over time is complicated by their respective different 
interaction models.</t>

<t>The workshop participants discussed various approaches to deal with change.  In the most basic case, a
developer might use a description of an API and implement 
the protocol steps.  Sometimes the data or information model can be used to generate code stubs.  Subsequent changes to an API
require changes on the clients to upgrade to the new version, which
requires some development of new code to satisfy the needs of the new
API.</t>

<t>These interactions could be made machine-understandable in the first place,
enabling for changes to happen at runtime.
In that scenario, a machine client could discover the possible interactions with a
service, adapting to changes as they occur without specific code
being developed to adapt to them.</t>

<t>The challenge seems to be to code the human-readable specification into a machine-readable format.  Machine-readable languages require a shared vocabulary to
give meaning to the tags.</t>

<t>These types of interactions are often based on the REST architectural
style. Its principle is that a device or endpoint only needs a
single entry point with a host providing descriptions of the API
in-band by means of web links and forms.</t>

<t>By defining IoT-specific relation types, it is possible to drive
interactions through links instead of hardcoding URIs into a RESTful
client, thus making the system flexible enough for later changes.
The definition of the basic hypermedia formats for IoT is still work
in progress. However, some of the existing mechanisms can be reused,
such as resource discovery, forms, or links.</t>

</section>
<section anchor="section-7" title="Security Considerations">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="section-8" title="Collaboration">

<t>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 <xref target="IOTSIGIT"/>.</t>

<t>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 <xref target="IOTSIGIT"/>.</t>

<t>It was also agreed that the iotsi@iab.org mailing list would remain open and available
for sharing information between all relevant organizations.</t>

</section>
<section anchor="section-9" title="Acknowledgements">

<t>We would like to thank all paper authors and participants for their
contributions, and Ericsson for hosting the workshop.</t>

</section>
<section anchor="section-10" title="Appendix A: Program Committee">

<t>This workshop was organized by the following individuals: Jari Arkko,
Ralph Droms, Jaime Jiménez, Michael Koster, Dave Thaler, and Hannes
Tschofenig.</t>

</section>
<section anchor="section-11" title="Appendix B: Accepted Position Papers">

<t><list style="symbols">
  <t>Jari Arkko, “Gadgets and Protocols Come and Go, Data Is Forever”</t>
  <t>Carsten Bormann, “Noise in specifications hurts”</t>
  <t>Benoit Claise, “YANG as the Data Modelling Language in the IoT space”</t>
  <t>Robert Cragie, “The ZigBee Cluster Library over IP”</t>
  <t>Dee Denteneer, Michael Verschoor, Teresa Zotti, “Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems”</t>
  <t>Universal Devices, “Object Oriented Approach to IoT Interoperability”</t>
  <t>Bryant Eastham, “Interoperability and the OpenDOF Project”</t>
  <t>Stephen Farrell, Alissa Cooper, “It’s Often True: Security’s Ignored (IOTSI) - and Privacy too”</t>
  <t>Christian Groves, Lui Yan, ang Weiwei, “Overview of IoT semantics landscape”</t>
  <t>Ted Hardie, “Loci of Interoperability for the Internet of Things”</t>
  <t>Russ Housley, “Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications”</t>
  <t>Jaime Jimenez, Michael Koster, Hannes Tschofenig, “IPSO Smart Objects”</t>
  <t>David Jones, IOTDB - “Interoperability Through Semantic Metastandards”</t>
  <t>Sebastian Kaebisch, Darko Anicic, “Thing Description as Enabler of Semantic Interoperability on the Web of Things”</t>
  <t>Achilleas Kemos, “Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation”</t>
  <t>Ari Keraenen, Cullen Jennings, “SenML: simple building block for IoT semantic interoperability”</t>
  <t>Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, “Research on Unified Data Model and Framework to Support Interoperability between IoT Applications”</t>
  <t>Michael Koster, “Model-Based Hypertext Language”</t>
  <t>Matthias Kovatsch, Yassin N.  Hassan, Klaus Hartke, “Semantic Interoperability Requires self describing Interaction Models”</t>
  <t>Kai Kreuzer, “A Pragmatic Approach to Interoperability in the Internet of Things”</t>
  <t>Barry Leiba, “Position Paper”</t>
  <t>Marcello Lioy, “AllJoyn”</t>
  <t>Kerry Lynn, Laird Dornin, “Modeling RESTful APIs with JSON Hyper-Schema”</t>
  <t>Erik Nordmark, “Thoughts on IoT Semantic Interoperability: Scope of security issues”</t>
  <t>Open Geospatial Consortium, “OGC SensorThings API: Communicating “Where” in the Web of Things”</t>
  <t>Jean Paoli, Taqi Jaffri, “IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti”</t>
  <t>Joaquin Prado, “OMA Lightweight M2M Resource Model”</t>
  <t>Dave Raggett, Soumya Kanti Datta, “Input paper for IAB Semantic Interoperability Workshop”</t>
  <t>Pete Rai, Stephen Tallamy, “Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability”</t>
  <t>Jasper Roes, Laura Daniele, “Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions”</t>
  <t>Max Senges, “Submission for IAB IoT Sematic Interoperability workshop”</t>
  <t>Bill Silverajan, Mert Ocak, Jaime Jimenez, “Implementation Experiences of Semantic Interoperability for RESTful Gateway Management”</t>
  <t>Ned Smith, Jeff Sedayao, Claire Vishik, “Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models”</t>
  <t>Robert Sparks and Ben Campbell, “Considerations for certain IoT based services”</t>
  <t>J.  Clarke Stevens, “Open Connectivity Foundation oneIoTa Tool”</t>
  <t>J.  Clarke Stevens, Piper Merriam, “Derived Models for Interoperability Between IoT Ecosystems”</t>
  <t>Ravi Subramaniam, “Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)””</t>
  <t>Andrew Sullivan, “Position paper for IOTSI workshop”</t>
  <t>Darshak Thakore, “IoT Security in the context of Semantic Interoperability”</t>
  <t>Dave Thaler, “IoT Bridge Taxonomy”</t>
  <t>Dave Thaler, S”ummary of AllSeen Alliance Work Relevant to Semantic Interoperability”</t>
  <t>Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram, “Internet of Things: Toward Smart Networked Systems and Societies”</t>
  <t>Peter van der Stok, Andy Bierman, “YANG-Based Constrained Management Interface (CoMI)”</t>
</list></t>

</section>
<section anchor="section-12" title="Appendix C: List of Participants">

<t><list style="symbols">
  <t>Andy Bierman, YumaWorks</t>
  <t>Carsten Bormann, Uni Bremen/TZI</t>
  <t>Ben Campbell, Oracle</t>
  <t>Benoit Claise, Cisco</t>
  <t>Alissa Cooper, Cisco</t>
  <t>Robert Cragie, ARM Limited</t>
  <t>Laura Daniele, TNO</t>
  <t>Bryant Eastham, OpenDOF</t>
  <t>Christian Groves, Huawei</t>
  <t>Ted Hardie, Google</t>
  <t>Yonggeun Hong, ETRI</t>
  <t>Russ Housley, Vigil Security</t>
  <t>David Janes, IOTDB</t>
  <t>Jaime Jimenez, Ericsson</t>
  <t>Shailendra Karody, Catalina Labs</t>
  <t>Ari Keraenen, Ericsson</t>
  <t>Michael Koster, SmartThings</t>
  <t>Matthias Kovatsch, Siemens</t>
  <t>Kai Kreuzer, Deutsche Telekom</t>
  <t>Barry Leiba, Huawei</t>
  <t>Steve Liang, Uni Calgary</t>
  <t>Marcello Lioy, Qualcomm</t>
  <t>Kerry Lynn, Verizon</t>
  <t>Mayan Mathen, Catalina Labs</t>
  <t>Erik Nordmark, Arista</t>
  <t>Jean Paoli, Microsoft</t>
  <t>Joaquin Prado, OMA</t>
  <t>Dave Raggett, W3C</t>
  <t>Max Senges, Google</t>
  <t>Ned Smith, Intel</t>
  <t>Robert Sparks, Oracle</t>
  <t>Ram Sriram, NIST</t>
  <t>Clarke Stevens</t>
  <t>Ram Subramanian, Intel</t>
  <t>Andrew Sullivan, DIN</t>
  <t>Darshak Thakore, CableLabs</t>
  <t>Dave Thaler, Microsoft</t>
  <t>Hannes Tschofenig, ARM Limited</t>
  <t>Michael Verschoor, Philips Lighting</t>
</list></t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC3444" target='https://www.rfc-editor.org/info/rfc3444'>
<front>
<title>On the Difference between Information Models and Data Models</title>
<author initials='A.' surname='Pras' fullname='A. Pras'><organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author>
<date year='2003' month='January' />
<abstract><t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3444'/>
<seriesInfo name='DOI' value='10.17487/RFC3444'/>
</reference>


<reference anchor="AllSeen-Plugin" >
  <front>
    <title>Using the AllJoyn Studio Extension</title>
    <author initials="B." surname="Rockwell" fullname="B. Rockwell">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf">
  <front>
    <title>Semantic Interoperability Requires Self-describing Interaction Models - HATEOAS for the Internet of Things</title>
    <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
  <seriesInfo name="Proceedings" value="of the IoT Semantic Interoperability Workshop 2016"/>
</reference>
<reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf">
  <front>
    <title>Summary of AllSeen Alliance Work Relevant to Semantic Interoperability</title>
    <author initials="D." surname="Thaler" fullname="D. Thaler">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf">
  <front>
    <title>IoT Bridge Taxonomy</title>
    <author initials="D." surname="Thaler" fullname="D. Thaler">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/">
  <front>
    <title>IoT Workshop for Semantic Interoperability (IOTSI) - Agenda and Slides</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi">
  <front>
    <title>Github Collaborative Repository</title>
    <author >
      <organization>IOTSI</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/">
  <front>
    <title>IoT Workshop for Semantic Interoperability (IOTSI) 2016 - Main Page and Position Papers</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="LWM2M-Schema" >
  <front>
    <title>OMA LWM2M XML Schema</title>
    <author >
      <organization>OMA</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="OMNA" >
  <front>
    <title>OMNA Lightweight M2M (LWM2M) Object &amp; Resource Registry</title>
    <author >
      <organization>OMA</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt">
  <front>
    <title>GATT Specifications</title>
    <author >
      <organization>Bluetooth SIG</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="PYANG" >
  <front>
    <title>An extensible YANG validator and converter in python</title>
    <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="nRF-Sniffer" >
  <front>
    <title>nRF Sniffer - Smart/Bluetooth low energy packet sniffer</title>
    <author >
      <organization>Nordic Semiconductor</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="AllJoynExplorer" >
  <front>
    <title>AllJoyn Explorer</title>
    <author >
      <organization>Microsoft</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="OpenDOF" target="https://opendof.org">
  <front>
    <title>The OpenDOF Project</title>
    <author >
      <organization>OpenDOF</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>


    </references>




  </back>

<!-- ##markdown-source:
H4sIAKeZOlsAA7V963IbyZXmf0bwHSroiBXZBsi+eOweRjjavEhqqkWRS7Jb
0w7HOBKoJFDNQhVcF0JojeZ99jn2xfb7zsnMyiqAbHm9K4dbIlCVefLkuXzn
ksnxeLy7UzemSP9u8rKwx0lTtXZ3Jy2nhVngx7Qy9804M5NxVjZ1Nl6V1UM9
L5fjL7/e3Zma5jjJivsSY7STRVbXWVk06yXeu3h592p3Z5kd7+4kybRcLM0U
z75Y2/oFP2nsh2acZ3UzrteLSZnXx0n5xe/H/Aojdc8XpTxel1VT2fs6GgHv
DT9pqqw/STkNPzVZk4OsG7vEUMl9VS6SZm6Ti6KxVWGbpLxP7uZZMauT/Yvy
7iC5tQtTNNlUnyiXtjKTLM+aNb6/uru9OOAE7x0zkq+//OqPuztmMqns49M8
A1tNAyLw9LfjL/8kLDRtMy8rcGkMRmI1bw6TN9nCFvZXTqB78Mbgk/jjspod
Jy+x2rouC34AYrP8OPmFDx7+og/+xboHDsHOMP73h8ldPZ2X97bIZt0U35ui
sPXgK5nmpFokb5v0MJpmLg8fNuHhv5hq0ZvlHLPMTW6rboZz82ijD2Xsy2xa
lXV530SDp40885eF/04HppRVC9Nkj1ZE6ubV2Td/+MMf5N8neX5rbTG+zttZ
VshH2Hzd8B9rbKpsNZ56U66L5LZp06xMXn5obEF51cfDPvAHt4rTw+SmnD6s
bJ7r534tW76Q9bx4oT+Gbf4jf/7+5O7l1cmtp8tUMwspnTfNsj4+OlqtVocQ
lUMMcLRajqdQIFs0Rxcnp+N2mZcmrY840NGX38jfY37hRjxcpve9xT4ttDf2
H21WYYdvbX4/Tm09rbIJOSNPQtfAiOSyTG1e+xWNPeEJOP+EsjzNu8vD5Ify
0VBG+rzb8sUzvINWQ4xtze0/9s9fV+XU2pQEHJMWoa28e2b5A0UNIvOv74mX
vbpdLEy1Hotx2NwY/ZbEuhf4d2aKqRXasD+5fQTxsFlPL+Npbvf0reP1xsfP
cPq0ytKZvTMfyqJcrP91xpzrzE8whNulMyZ+yv+vqxMqTl5/xrKoC49ZA5k7
8na7PhI7fmRmtkjN0cZCgnRRUX7TcWBVJzJQAq+b3OYZtHHr2mU5YO2T63l9
cffEgmZZM28ntJyOdPlvj/DX8khyVua5mZSVWFZxj3XWlNX23VCKOPWTNL3/
HDv3DI//VeaSGFB6abIiucaGkcnBbnBtNHTXBm/+80x/+/7y68vx7XQOKvpe
5uryRL9N/uPybaJPPD08nh4M/y1/vrp8dzIc9h3GzWbzZmX534Qz7MtEB8nV
5Bc7bZL/gU2ry7aacvdmQFTP7d0TM0OUntm1Sd7apiybuchTvbTT7D4D9AMn
66OZaZq+XJ3cwRL3HnqanlM/NEnYRtn1zyfvXveZclIkVn33JLcJv08eDbTI
QGxFpWCVHm0F+YD1SJZrzPqMj4c7Ov0FIpa3nZwER7XxzTMWprh5Nb4tsvt7
W/XpxReJ+wKT3sIPNEfduvNylQCtVbN1Asj7AOda67NPM+1dWaVQAehChqWm
7RQL30aRAzwvP8AyV0OqPBry3z49XQ+kDee4Wtri/OrVE9IDBS3S8p4635v8
Dg7bvUlnTjl+Rmb1wcHs/7a7A7Q5HidmApE3HID/AyypEwQvLSBwkyyr8pHm
NTFJ3XlgwoUXwazAHES4Rkb4J6KAF6PdndU8m87huMuHZJkb6CHE7havmeQs
N5UZJWcQT1ivIsO/CbNMhee/+tP4q29HwsjDRDgC/AtBnZUm91R645isTE1k
cF/WFGuTpFk9bSXa4oB8NBWhwaIRUiyxbgMbVCdtbdNkstYArMjICfocxnum
Suvk3D7avFwSCF5VMzzxq2pssn97flUjxsGkZsq3EavNsbABF0wjk2PG3Cl7
kpu1rWRF2IlKwi1Gh+R+9isIUGI9+fVIKGIkyKcx04KuUYnA5Hy69uQi4MT3
bYGZHcseM7vSNS2dba/J/aabOzGVxc9lbR1TsV+eq0uoYjbNwJlGB0nLpCib
pLBTW9egN19jlPucZrY/hMqpvtRDxifY2qzBCy2mPS1BNSTl5PRglKiUlMpl
C4sSb/Chl+ZFlqa55U+/46BVSfUmWz/+rrbyr/FXn1TQP2PWZF7m2OVyOjVk
NgQruFvEokDVswLyATbDjtRQlArmqJiNMeoiQTDfOnmhgjXwLfjRhQK7O35u
3T8MUbezma0RWrdCRYpoY6obMgwfwL6IXreTGWx23WRwJ0LREqEruA0zjx2Q
0AU00u4VfGB3x95j1IaPQG2KteerExySlMEy0hkmkzIl5SAxW9AgEBIgnkyh
K3BRmA0fwpMsQMhV4bfYmbJ6qIkQLw4FAiCVE1EKJ5NO/CcWvlqodoC+R9ko
seI/TZ6vaTisKq9bL0W1bBs/Zz2Fqm0GXy8LBLkWUVEBo3pn6ofkVUnvv8+U
y4HXvG4jYZOKghp+3xYqSz5kOjnFakSpllg/+EED6ZQOr5d8yXazJZ7pMAAM
xtW0kDNCyqwq22VgGIkRqX4PnCmf2A9QtDqe/4ncy2jDzuzuTGgasIsL+CrZ
XvkHNhQEgcuH/4xNmzMTkZbYa5M0FReeli24vyjbQojhkkSk3ZjQV9iEFQWl
KadlXsPoO6nHR/dZzsXBgnHK8Iws/uQJ+yhLcMYzJ72cti7zVh65rwBAROJG
CTMfA6OL3aWVWoNzC6MqdC2WrIW7ydejzsrROcCYmkRzJ2BBpgLHnzmlfLmQ
sN8pjcuyEDLp5zAiRiesrRPXGuR1ZIvtgF8qphCeOYRgNocQ7+6Q28IEahWV
BMQ4VRMl4tKBeDiEAaQrpiUj+jH01hI20H93G+BIcpITkTlSisrxFDpleyvQ
hR0CMAJogefd5Gp8YR0g5dRUFZB5BkfrpRWgz4KZ3NK+gse2a0TPBqtuiDBu
7KJsrCYnUppAuP082b+5PjvAVGsIiVrchDA1uXl5e3ff5u6zw+RVW5FIivUo
caqUqiRjEicZ5JpRlwaEu07qbJFhzz0GqNvqnvhjAhuieCCpc8YN8GO68VkV
C3VKa0O9GmE3TSqJsnKL8jnG1aAS9jeniNV4y5N5bx6xpABAwlaq5QcEEa7u
7jzCo4qibWhDX2nu5m09ChYqhblM1Ut55wn2BR+Ojytr6FnbRn9QuytZ7QdL
B4hQj99YRboeUjR2XN6P8cPYECWoOjuvsFakQY8pKAdfzgxW+vGjyyN8+uT+
+f7206dDWDKHJaiBHelAbU594S10CeBzBRmaCLWiiDkiAHLe0DE09TE58EXy
nvvstESI9UaTxGZOqwca6xT5O30Z3GlzCVygXRtPwT8ArubZg/1uc8KqzGU+
eQePmmLWIpTGpnhpryXCjb/JJMaKEovxlIKtOlPzzJQL2xg+6fESvkaASTAr
7JNB8PcCW5tkNEm9bKYb+HvEVFOsegV2QVmhRZvIVXxvJ7MDLx3wsvJP0ESG
UKI1eVBLH4XihS0LgrQxcckEn9gUIcD5ysRrQmx+3ahWtkzqEx11qmgjWg4Z
LH5PLIJ9LPNH6jPMAoKsRW9Xvd9XYVa5gMnI4dcFJEvCx4O7em7E1+sO1wmd
5YCtwdfFZEwYvyxBfmJmiGMABFUrxfJSd8UcxVxwo14IvyqKANZMEkABVM9t
hizaOLWlLQGUtYIyhuzxW9WHgnUJU579o7XKKJ1KPChDhjpz4sB5ATApIHxv
sOL+kIB4jMIcSgBKdEvMiilMEUg0KxBcIITY0FDH3e8U4N/B3mdFmZcI/jt8
/3XA9/dZBT4ilksneTl92GacN0BEvCdDL+utWvJYTs2EtmrtYE7VDOIyGOKP
H12N5dOnXiDNpwXpAB82RIC1hfEzjbpKCPyygZp4GshYF2lUxE34cW/TZu2N
VOT5fmUbusrGZPTnqb3PiqwLJDKPVTlcwsTHXrTkPaaEucNGAgYhpnOauzv0
6hhPcIJ+jDXKLuFlu+KrnZFTpNGVRzw22N2pXMatDuAlFW6IsO7F7whZexrj
IJT0/gc4yWKcPYb8ex4cxQq9EjHtYhT+LK7ho5TfZhcCkP784psXnxiLdfyU
Gs7ujqTJNq2+rr5Wmh8z4B/JkzghmgMrMIQLwuRzK86GS5XuwxKrr30gj52t
QF7PxEip8GJjj0WTJjbpdkD9C8DJvj2cHY4kXZczcYsQh6HVAdlJRCQmcfDw
j5dvR3iwwYTjmxjCnWdmBgDNWKuZHh4oNSHCEYJUujTgmiPitiLvx8ljvQR+
+vOLL198eorX5xS2jsmRvgXmdkLM72BhwTA/Nd0ZlAg+n8G247NYro7VZMQ0
bwWPZX3CJdPhwNLYZ2L9cmSltwRm9oPhe7LA4+T23eV1cmkKOGrZ7YsY5CfJ
KU3W/uXF6QHX0eb05u+/OdOQDNEUnetSZt+/Oz9wkdpIE6+6syPNfcv06jZG
ydXZq+4HSSLAB3w+mzfKkkGkB7oVuD6HrRaGEzJMmcChL8LE2IqKGCDtqv5e
X2mQEsikKxF7Bc0UbAj2cjx2XQxRHLA09AJFcCtJvQbIW0i05ESUGJ+IZl6m
OtN1KymDo9t2IpAFkMd7HPXuCBYSBjL1wVZO+UgmMgxN5EMkZRNQo09dLqyR
8J/YgCU6Bj/EhxQUvq0+3ucg3cPU1Uf6Bw3G5H0NMqTm90FAqEt80iK6lJEk
HA+HUsjYljZVZxOZ9NRh2U6Gdnd83DCSmi9MiTpcF7ziQZtmQH/rJYesQpih
n2DSczaucN/YLcGoFAolm0xnH5QyZhjTqjAWFnxsl1S8CQNXceyrDMEb15oV
rUI4LFghTQQGJHcGp49xHaZTVvgJfCa6duztZxx1ZnpghPLtEnZB63YdKlvT
DftaH/xwjNAi636oeELQ3rUL1qSSTFQYQYs/BGixlZABQGoYXy5hceH0MSEA
uo+gMfSEQTcxp2MapHguqekKqgxpOm8r33jRxWq9gMdHlerrHPSwqQuAXmns
8dZHGLL0c8dO5f11W4FNxOhYU6nEInYD95gWVltJhZs6IMmERFJYImwX2aSd
cfOJK0TIUWw1MDY0sbcwJVVI0S8Ek0IqFU8NrD2IbguHNTpbol9lDYMXiD2j
dR1kEG9JWgE2P6ed0frsykgFIwqzSqkC1s7SOVgiC/TDLR2btqnlcEaho5KZ
daN8RK71GpjiCbNdoXdh/+ry5ID6tZISKMt+UljBslq1v1IQdeHix49xBRXi
zIjOOkuovNflaHrNLyfGgILvZEym3dS09BIanh1cxCO8omGRUEBouSpo/uCA
qVQsrSJ096vrFSIDRHnNyhxM6EkDF4J9woT7rG8e0EI9ZlOXH59CIyEmeLSm
SeulPZLdnWhsKf69BbdeSslPV/PsWFwIlGdF1xfJmSbwikQzWX3qV3YC42GJ
ND5+xAefPqkHFp7kdRmWh10mJxmtyW521qq36WdlUVit2K+hl62rz2Dzz14d
cKF18ub26p1391qocmBNp4qjEpc7vTnBzI2nZZuqqcX0u+v2u7+vGsRiwIap
+4vyzrDUGKjfaLURWn3lU8orknThpP/RI2ebCfAJ0aDOzIIOFGiUEImVAonV
nY819ReNM1gYdPXJlXmfu7EQbHHCPRbjm0y484FRAtQfmdSuxn6nFSrpRA6G
lxOQWmgOX4s12C7EyZXkPA3zERBKX35YUJqqtqBvDfyFqufp+D3QSPLespWk
YJ9m1i6SfQBIJxqkP3QoxGjylc9yJ/s356+01vgM+30U0dZKnzq/Pr/F29jJ
4UaBLKqZJBslE6VT8OxnkYDhr8TZiUNZwCRT2X1ORxGaS7gfPuPMzjCYWhgH
xXd35KNZ+Ig1ZR8QcgrvtZ7M/eVcX0jKsc5mxeG5XXYZpoqJXAIodQSjnoj9
lNWM3rVJcndHWyphR/o9lrDdktBhQmAFLFQJjHGUE3xhHRNDD8CF+YpD3+P6
jGZnG6AZHuE62iQIlSec9vVWqJxx8iz+RtM4fSZmurccfHdnWS7FfpKzJHlu
c5f0H76GmX2Iw5iIwyzXmBi8kKYUcR7SixJRqsN6qtJyY1QSuGjzJuMrdlpq
0FBLTcJ3RMA56b+YWv4xpLwCQtq+SgkZ8aU1tZTj3G5LxEcvCSdjqzGrvEG1
46B9lEzzzApa1h4agimxNfB6QZDP7aSdzbgHt+1SS/sIicOHKq+R1AkrQgyr
9MKfqpdOJhUAhuRxJJIQzNDZsUFt6qisQii3gVtiIAeD6uM8XajYoAXQ1iNB
0AlUtLA94d/deXfzKhm4ad+Ho1Hjtp4bbFTU9AOVUEl00IemJKuXuVk/7+C9
iZ6skw1XTgnjWz2dGG307qh6xr0+gZjE06K8Vt/rTZoKPsvnAWrZD8SKQo0p
wkTKxzgvQZfjDg44n5MMXE7s8jmc2zsfFGxB4BsbN/Q5XyR3iC7qPNjLOxdd
aP2kbhdLr/EieH77CxdmSeHX+HRblLlBzCecQEySlVWWPADQ5pbNqT6jqlGn
oKipA6Lflysr6XbJ10lSXcMlF2BLsDgNPvGoFzdKeNlo/tV5HAeAV4hUpsZ7
uYX5BYK2pQjsoifsyb2EakZVFhGuFPskl+SQhE0QV2J31BB3ZW56rNCWEGoZ
WvwI3TSYHYvkN5IWYKLGKnvJNCxizqy/tCEZNgbEbIUHyMCoOHOxLNkwjOA+
8V1K2lDh9waRc0a5MItAZuzlFA+JcaN8sDuJUYpYRONlJZlkhS9mmhB1KU3q
7NT+MKCS3I9AD99mAgALBjcS7UIYIlnAN1oyyK0u6hKqxqzKKGHbCmIzSro0
NdeuFCFr9lXaoTim68LAnGgvSOMkG6CELsIsD2TnIm5yNY6L+OYQ+IH7/UGK
WdyIUH6AkvuaSoD8weeEUqsm5Txkp8BqUW2j+gt7lWqBwxXTdPFUxxvH8HO4
JjJizY/9h6n/UPeolm7eYJFZj1VpCjW/qCyqJcAgLMxBsKElSsHLC36I1EXT
UomVxJa6zGYejU4tAaxeh5DT1d+IoIVHw3y/st0wQZHnXHTf22uZoOgEmZm/
CTGUxmtCqz9C8fGj+5eDDX2U4w0WGwb6NrfGNOJodbpqyFs6G7UUfmOxYDIl
qxeJa4lgQaKLdPboba2rQwTmgILdHaL/LM6TOjVT5nYgsIubnYh57OvNPSaQ
9aUW7mhNFFgF1RlpEourCas4VFMeqFlIs/OE7kgMmafJ9HMokjJlIVvyd2qC
dnemedmmUQrNZ2NdhCjTMzvt2lsGgzxmkEPny17AJWmUVVZdvPQEd/Z92SgL
MZvsIyXxwMV8rBy5trDNtW5OIBGmtJQKBVGL5zJji+JT73aVUXk5rttrqY4+
Ql8R69erULon981BUq+Lxnzod9vsTw6YPh8DV1T9/FnGbIQJJaEuJKah2Z8e
dPFHV7nQfs9ms7TnMpqRv4/SmP8macyLQjobUqttjXC/KtebrYBd96sv8WoP
meQ9RWy4z5LhjOytBzejXtFYjDep9SbfpU2D+ZYd6JtuzUrT73TW26GHkfaq
ZuyicVATRlw8fFOmZj3yLaZO09jsKA05cE5W+vV6BV8sJU0zn5kWd59jvHQ9
yJIVDgmLvoBN8H1sVegcWQ/El9HyfH9jNO2h6zjEPGLYd3f2i//8+mBckPET
dmwqrnCKgb2qG1ELdSSdGTEIRUppMxXbGWiZsIDt3v7q37/9Mq6ROnwbO1BP
IgJ/SS8Me4yS5CX0m0VqqMHFtXZuqx/XOrdCgrkNjcBrEfmmHFuPnreU4HvT
IXCj1jRtIdo20vGyuKMXLiSsMPBO6vWwlPzWlVoJ3fAXXF5r/SNNpBdP7Mgg
vuOAWCsrHjW36NHkreBDx1eEPDx8oG4ofWTkBzm30l8o1KjsukXS5YgYOiwx
sVPtCaylX0c86KMqmewSfa9LCK9Z0NWdv46LEF14O8x5+yrT2js0k7yghWEn
wotRlx39+BGfjvkpM57SXlvZfhhZdaxTwd4WDYQBhS/SkO1EnPYb2+eQRdEu
JlTn+3g7ohY9pz5MPHOqr4vQfjmxTgMOyAipx3g4Lw2VbVUz2grNPXCRtCgr
YVSIEwbgUHPoieeMX8BUDKrY0//GHzlG8fsx//w++cw/7nF59b/kk//63Ffd
4/1Xx+PffA+PbH31N1+Wr+NXe2t95mX3VbzW7U9sfDre9vC2x596cvjs08/F
T4anxtsIw2cn20kOBB/h/38bfvv3v//9KPkb/rvxnjze241x/w90MUkOXww+
7e+GTHi0OfZh8p/J4QYx7vFn1nn0Qv56seVVffyf4uQzzzz33Ofu9FMCtPns
03IaPX30t994Nvr26G/+tSNh6m+rIJ848jvu9mwLl7f90Wc7IfvcN/2z8uaR
F6DPeLV71hu5j8fJ77w30FNnf96jnX1xY+X8U/WC9pHNPEcb3VP14Z4AzPdz
1jp7FWyH9VeuI57HyrLGlxjbhUv60Y+F9qiZeHrXKB777cz3IbHfQWvKQGG1
OhHxmpXJWBAXX5l8kZyX7GgVAGqSPW/n91yuq4RXEk/RSN+OpIiZk1oFMhgY
65fyBrvpXQpfDlOwSZkXaAzbub7z87MbMhUaEF/CKQagEgoS/oPt799q56kG
3T1HvAXCSMDT7y/tXuiRNDVb2oI2XrgjfvCZF+lCA8bwrbkdasaoDmL14JSb
7pK50n2fccvzg2crVZLSkmzEhCWSaojIOJcrFXC8PkuYxs/Xh2GFev5s4nnf
sUCaPvJskYUGs4pFsESP7+j5PbtsHByoe9ix/s4j8EFDCNMh4EmlXVRkhxdN
OR8j55YiUXY9xRM9VsNoflVGzbpbGjwQXbIYSLFkQuNYjuI8h2nlvFoINqMm
Tf+WJEG6pjQFd6wyH0lxWrN/vLJG0uLdEaZS4p5U21XSjiSmaXzfy2YjZYi8
XdOzzNYBwi4Cj8WIC0f4zLSZW7XPlcVrl8xszrN33LJVub0iIm3JzGax4GDy
WVlBlF02UQ83hdNlEUyUFCqEklUg9skN37MVEHcaJ+J773YxLEfwR81oDQMy
33Nj+M5XxOmNPNHh+9Ax58rdmY9PNrJbskqTpXK6IDS0Rczq5EBW6xM3UWvk
cO2M9FNXrQspM03aJnJoVLuawslOPxntqQQmfY5RLLneXssdvxkznYx9pAw8
T1Rg6jOkjZIeByXY6V/YEfWyPNnbFYjvyZskj7WSmMuBV8mDQ1PaupGW7NRK
Rq+QagfFJ+urnSSmvdvRZvg5WZX0ROFwI+JjS57WLLVMqGcn1kvHWlpAzTt3
ob3zHWocfO1UixHar9TlzZ4+teVyS+fMs/icsktFdzmmP2rDJaL5aqYs3Xoo
G9Rziq5hlCcxWqfHvk7hcu1RBTY6AkWzEHW71p3tG7wbfpjrMrOqd3Rtd0cP
gdTdIRDyUwu5SqKWGOU9zQY/RufGfZFp2OrQVdk2z0x3Ehmd7fJnz6Wyxdxc
x99D9oVrWF0iAmZ9aCo+YsQUXMgPOuuqTXGDjgFWJa8v1OWGurJmV4LOQCyW
vt2NfKg7U8Y044YxH5RK+20MddNOZDD8JWmypquClY4c5gXcIWX3lW+W1Zo6
n2yXs8qkIYPD86SusBbK35W/pElAw6CAzxeEIPaLgvr6fu0Gsmk4dYuHILTX
F37f6l5Fo3aQUNxWyv9AKQo7lrOO6mWijJCePtH0M5tzedyZp4hpCTsGuPJf
r1J74bqi6yneglyMpJApczmOOEK8oZf5fIGgT7EWZmn9K61Bm9QsvdnxdGi9
a82D7q0ekWIhKcoyp5ZHiNXDu2NWsnscy+3IIsg6RoUzozmorWuknVg9JZ+q
oZ+3MPRjJlaFYYPGzkLAgGdueEqlDpJ0OfwmdOx0RUjp8qVexSd1dndYxw09
2j4XaGZ1tN+uP/q+z0Y5Wi7H6X1bjjZmsUM9so0mZ1F/zYTXBQ96AxRNs16F
ylc9pAFbu+gVh6gcdpl07DKI1gdcdX1OpQ8p1m3dt6pMWTGeUMFhr7hW+ZId
b5C/BzWB5KUu+tT1GMpdZuVd52S9bVSGjJx7CUJG60Tv1LN6XKQcYHZTsTMS
m8T5WQV1/eY/3lzUfpfdMV5WnSjXTOezDmYefJ+DOxVwz0rtRNgi41OL6NGC
LrkSWNfq6jmiRnKORVTaAO/PcnMIllSxKiDzXO924HLI4hmhe1RlEIviRgzn
90KlMDQFVpZGMDrW3PXgekw2UuZr2Yxccu701kL3COTO3F0SLhzpXOqfPnXp
fgkJCG6DuNb+/Wn//S5uEIfQNS1HXWHu6GI0wn02aysHEdWBuu/icHVQOnEY
SNbjQGs5Ea8dYdYwUNdv4otMvUl5ECw8q1h4JF4Sq4Vch9YvV+bBQjqZ+aWc
uHayDnzST/N8MQ3IRvPeBhOZmxfV5XlVV/+Uit0jhMJpMP8Z4ZADHcrxWE/Q
yAGICh5V72fZPzl7Wx/Ii1OzVOCO9biO3pWwyFOyLDFw1rWb+nNj6Uiq3HK2
JOYD2/OYisBDWKSrl/QZ2ANxEWIFAuMJ6drXtSNs64+caVSqVxGEen2HXlYa
QCh2hVCG80FdnGec0ZAWNVEmHqcxa3qmmEgsj9cl1f3d85hOBg9df+FSGNpP
QVhJdq8r71PRFSq3lCtc42tW9SFv1EzpVwyI1VuyO94xN48aPUcEszvM6CJa
ObsuVlIMEE2A0q19HY7g7l31l55hW0qHTwbH3B53j4wc0+tR2+sGSVM1YL59
gdbYZi74sN0Bj45NXT1alqc14bVXOXnQhd0BkayySjq6pblRlynPiTuDgj2a
6VoP8REg9mytwk78rH629/CgqQmqL0Lmcos8WMNWLKJzwk6advFem/ZIEY1n
dK+dSO8ZCKLpcIXW2nU66Xx153r9keYfL9yVRmEzvXWPrgnsleK/3X6iqNs5
BitS7iJsJabpXwywKHUDIL2hgTqu3x+qUET3XcmZrUrO1TjB/UUwxsJaOjXs
hNw30laVg+oOy+l1UE6WNGTsdwqEQqUc3w55LjVt/K470F6/CNPpa+yjYptw
6mxhOEVPNxovWHGv8H7rofIpo1hGa9165HDTvZnS2vILaRjwnU9qtJ84VgYt
cUBGoWIv8oPY6QyB+No32fjLWthZ64IBOYMWN9XEx9IO4w6/Zzg+WHKapcJv
dthpUIt1ZjyLHTEankwPTQ5bSj+DzY6nEe8E34RbvCRPsOXCmOQ3GE4cuV3a
nRNhH4xjYsSy4Ev8rWyhKa8v8tordHX26kUdmpbiE4H9bJrRfub4MgN2tDmD
EfbApVhqdwgTLJDwWkENrVW4XKcL9SvaL305i8iKJIxXrChDpEdDawDlA8dt
l6mkh5x7iGcNbZuuH6YnFc7HZrQY5cifw/fFCW8BIDehpcLy/id3+ojnf5IN
BpnQfRqYFKUirJHA1bWC/9/o0uAajW1apNT+tho54KkZ+P65zERuSP2Lu0SV
1wXqaQhgM9d/XPEO7YKHitVuhfNEeiBwy8nR4JQJyrbfWeY8wMk0dMKqG+mc
wL9rucw6KnirjHLJFA8y8JL3rSbxpXk9LgcEI81IetQuC3cD+nvO9W6QUkOX
WFA9gUs5qfwhOTnmIVjeAcAe2UUGIxBn9r768lO4KbKXywt38/le/O6sanT9
C69jr7LkpHp4KGHtb0y+nCfn2HKQGy5q/9//q7C/jnh15tzA4f8g9zaO4jvQ
dW167TqICVepDxdzegzOs4ADsgb318Zr0ksBv4hpS/Zem1TusONM16FX54zo
lR+9LkdSAeUVLAgpCF72OMaZqXidV3JKISkQy+y9KzPJJPUzHXUyb6umlndO
EddCZc9ylizxhhRinO52VyaIvPpTUMG1IIaVY+4y0E05sRUGqsws40C0OX/N
ZqfYwrO8lesv32aTSq7yJE67uN7Tgyk8XEZbYMlbz/ifwCZwtsRHd7yFySR/
LZsmw7ivTFbN8f/juJ8rd9T4bKuc1pEO/NM2ywVynrRNGd1qJJfz8vMzFyl1
6F7o+rHImOUDFD3XdC6mdhf3XvF6IG7riQ9IoDOcfnjXqDK4WlMzX5oaarXA
KBs3kvqKxeBiVXn7trFLgplXLEMST57AaoAbZ9IPydEaOhtJEN1VrVwlr9AR
H1/MCjlh191frQKlkBZWWqVmLidaEHC95iWLvBSizZKfjQTgs+S9zVaWjL96
JHftShrShNnuJgAi9LRGYKmCcGepHlUqUvC2nGbywnDRT19Nr9LESvz3QJW5
RdSy95NF3JJbdvK5f8pSoo8vivsKLK5aDTLP4ohKh+z9MoZNFd/4RQpk7vXt
lTtUpHuvI8EaAAG9YTPmiJ7h/BSs3dzXO5eSCnfRXiLqCXei6vbaiVHe/2Ds
BJ5vTs2uHkqEgLCyU9Gj4W0e0M6XTOpqxfLpm25dqpAnPPvMPUE0DqiHcX6w
i5KSHc6nSm5q83rHi6Lg1f+c/blfVZDLMYavD7+EnIIvF8n7119+A97IHf++
j7WWcZQQ2LwfMAB2BNJ21hJ/Jm+s3HpJsm5tcfn2WMNd3o7nVFkvVfJptFBe
HPZ36l4hTlmsEXXMkh8yqN/PbTGdtzmkvoRQ/4xvZ7YtIGq8vmLvxtZWLvnF
QmEB5KKOzgqKzHWnX3lPg+vx3+CF984k8CSqGQlNQ9Hbk9HHp5Lg/Z4JQ7mo
w9tbfcc0gGvcMvc7GEC8ASgqkncMYfFPKuwPuUEgBu1rHqzw7zd/rYSErs/+
WgmZ/geDnQII/1XoPYERMTNa02nfCG7ceFk8p+SnMGrr5K3NJgaD9p2kW3Q1
hdUrYa3LtYopW/OVIisvr+nn3sIfYKN4U3Ph2cnF+LsaT64vXEFCWgqExe4y
AxkLSOVBTgqymVZ0jorbSDXo2d9PAXMrd73GaVC9f1fGlVP4r20JLylHp7qD
1rSnr88wMD9wSgYqj2PDhQXsvWcAu+f5uKnKb4CBwbAyhzDfmX9ksHL39xXN
tTqkQYfUlgWcFEIm1K8qV+n4VrLGkW/D1He89IpXlTJAzPXOUp29NBCjgtKQ
ErfIbfqDW+/DEXIhwNtPm9wYaF7TjBLMuFgbSBg4TGXjASIY0yViIYWfougn
p5/xW0Jk9GteFnNjwAPvPO9At1msY4W40iRgLf9ILsBz7QY7d/cUvuqiyLvM
wa4zd4GOvyN/u79/w/sgK8Ah8aSmrQwGLTKbCygqV3LV7ZM2K8ZWbfgNOOqC
xI7QStcQ7FdMxLGcUzR6Y83+7Qk+PdACa1NHBwOdKn2gtMmVj3u34Xc+BeZ6
Md/K31XM31OWLG6znJ1vv9DoXBL3XU3Nw2joY/cG13e9DHcr1s+7LrmDwSnv
a+21jy7CEjLesR8QMQIM4Rt7z8FSszaQQkJZIICfsnqeUZl/sOtnZnrN60EH
Zor3izqdpMseR3bQodxbhEGuonXKizbMYjkReLY3KKJI0RVvMLoji7WI53Gq
CgzsN++bR+wFgUXgLlDzufs7SpdbuCvL/MkhrjOKIfamygR2nruejsuu7rLB
jNPIa73s4+EbYB6W0uH9IM0y4tNMzYrPuYBkLAUhXtarT8swU32ldyfF1cXZ
wZ4ChiKtgEBvgRQAYovYa0S2QmL1nswCUyGGfmAI9yAX9e6pvHuT3b8h6znR
7AyYDwf3tvxKnM2nbvf+n/wmIe8WHwBPUt7IWaYdlH1dtUROnO6tLQFZEQ4C
EzAiNNPcrOqHjA9DSiC0hRjf1yTp1Faz8RmLH3AipcaQ35u5xpA3iMZvq6zq
YpeeIz9O1KY5G/VOj5lQN12Tj/zeAkQBlhWnYKCZNWanTAWBLaGl2FjQkVkG
ri4KdXjozN8HRtmN78LDIHJp8v5ZeXlxsDcIv8+O4YlqIbTXuxSF3l+70Ls/
98/twog/2RpRAxRir0nC0d1fL1wAHen/FbATszYbgfUZy7AyWz+AC58P4ueT
m0ssAPaNXX1fDB3J3burbbFl+I0b26K671sDtzyM0F6X5UwJHmDhl3c3F5uR
2E/ZLMuD4kTBkOmCoS3BVvcr79hNzAtCocj0+VWZrvl7Nhq2dBksc1JvBgbx
20PsLGLnf6fZVph8m3G76g0Ue25bPgAVBUsf+KvqBoi0Y5gYVWyHIWMoAmcm
n5lqvQWj/s/W5EwgDiHqTzC/v7olwE/xl4nA5BRb1j4AoyfcRzPEetHvdtmA
YfK7goYo6/03Z0MY0G195EupV/mGp4sFOzYI7y5u70Taes4nPBXcRRENvGHD
zy/ebbXRZ0Rknis9Y9pb/ZbAfaA8W5JK14iAM3h+nwbyv8aD2fDdnf8DIhqM
yV1zAAA=

-->

</rfc>

<?xml version="1.0" encoding="UTF-8"?> "US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<rfc docName="draft-iab-iotsi-workshop-02" category="info" submissionType="IETF" "IAB" obsoletes="" updates="" {http://www.w3.org/XML/1998/namespace}lang="en" number="8477" consensus="yes" ipr="trust200902">
- <back>
  - <section title="IAB Members at the Time of Approval" numbered="no" toc="default">
    - <?rfc subcompact="yes"?>
    - <t>
      - <list>
        
        <t>
        
        Jari Arkko
        
        </t>
        
        <t>
        
        Alissa Cooper
        
        </t>
        
        <t>
        
        Ted Hardie
        
        </t>
        
        <t>
        
        Christian Huitema
        
        </t>
        
        <t>
        
        Gabriel Montenegro
        
        </t>
        
        <t>
        
        Erik Nordmark
        
        </t>
        
        <t>
        
        Mark Nottingham
        
        </t>
        
        <t>
        
        Melinda Shore
        
        </t>
        
        <t>
        
        Robert Sparks
        
        </t>
        
        <t>
        
        Jeff Tantsura
        
        </t>
        
        <t>
        
        Martin Thomson
        
        </t>
        
        <t>
        
        Brian Trammell
        
        </t>
        
        <t>
        
        Suzanne Woolf
        
        </t>
        
        </list>
      - </t>
    - <?rfc subcompact="no"?>
    - </section>
  - </back>
- <front>
  - <title abbrev="draft-iab-iotsi-workshop" "IOTSI Workshop 2016" >
    - Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
    - </title>
  - <--[rfced] *RJS or Stream Manager - please review and approve the
    split of the boilerplate paragraph in the Intro.
    
    As it appears at https://www.rfc-editor.org/materials/iab-format.txt:
    
      The following boilerplate paragraph SHOULD appear in the introduction:
    
          The Internet Architecture Board (IAB) holds occasional workshops
          designed to consider long-term issues and strategies for the
          Internet, and to suggest future directions for the Internet
          architecture.  This long-term planning function of the IAB is
          complementary to the ongoing engineering efforts performed by working
          groups of the Internet Engineering Task Force (IETF).
    
    How it appears in this document:
    
       The Internet Architecture Board (IAB) holds occasional workshops
       designed to consider long-term issues and strategies for the
       Internet, and to suggest future directions for the Internet
       architecture.  The investigated topics often require coordinated
       efforts of many organizations and industry bodies to improve an
       identified problem.  One of the targets of the workshops is to
       establish communication between relevant organizations, especially
       when the topics are out of the scope for the Internet Engineering
       Task Force (IETF).  This long-term planning function of the IAB is
       complementary to the ongoing engineering efforts performed by working
       groups of the IETF.
    
    -->
  - <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
    - <organization>
      - Ericsson
      - </organization>
    - <address>
      - <email>
        
        jaime.jimenez@ericsson.com
        
        </email>
      - </address>
    - </author>
  - <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
    - <organization>
      - Arm Ltd.
      - </organization>
    - <address>
      - <email>
        
        hannes.tschofenig@arm.com
        
        </email>
      - </address>
    - </author>
  - <author initials="D." surname="Thaler" fullname="Dave Thaler">
    - <organization>
      - Microsoft
      - </organization>
    - <address>
      - <email>
        
        dthaler@microsoft.com
        
        </email>
      - </address>
    - </author>
  - <date year="2018" month="July" "September" day="02"/>
  - <-- [rfced] Please insert any keywords (beyond those that appear in
    the title) for use on https://www.rfc-editor.org/search.
    -->
  - <keyword>
    - example
    - </keyword>
  - <abstract>
    - <t>
      - This document provides a summary of the ‘Workshop "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)’, (IOTSI)", which took place in Santa Clara, California, on California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions, discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and or the Internet Architecture Board (IAB), which organized the workshop.
        <--begin DNE text -->
        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.
        <--end DNE text -->
      - </t>
    - </abstract>
  - </front>
- <middle>
  - <middle>
    - <section anchor="section-1" title="Introduction" numbered="true" toc="default">
      - <--Begin DNE text -->
      - <t>
        
        The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture.
        <--End DNE text -->
        The investigated topics often require coordinated efforts of from many organizations and industry bodies to improve an identified problem. One of the targets of the workshops is to establish communication between relevant organizations, especially when the topics are out of the scope for of the Internet Engineering Task Force (IETF).
        <--Begin DNE text -->
        This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.
        <--End DNE text -->
        
        </t>
      - <t>
        
        With the expansion of the Internet of Things (IoT), interoperability becomes more and more important. Standards Developing Organizations (SDOs) have done a tremendous amount of work to standardize new protocols, protocols and to profile existing protocols.
        
        </t>
      - <t>
        
        At the application layer and at the level of solution frameworks, interoperability is not yet mature. Particularly, the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout SDOs.
        
        </t>
      - <t>
        
        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 between data formats and the underlying communication architecture, such as a design in Remote Procedure Call (RPC) style design or a RESTful design. design (where REST refers to Representational State Transfer). 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 application-layer protocols.
        
        </t>
      - <t>
        
        Thus, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state-of-the-art state of the art and to identify commonality and gaps <xref target="IOTSIAG" format="default" pageno="false"/><xref target="IOTSIWS" format="default" pageno="false"/>. In particular, the IAB was interested to learn about the following aspects:
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        What is the state of the art in data and information models? What should an information model look like?
        
        </t>
        
        <t>
        
        What is the role of formal languages, such as schema languages, in describing information and data models?
        
        </t>
        
        <t>
        
        What is the role of metadata, which is attached to data to make it self-describing?
        
        </t>
        
        <t>
        
        How can we achieve interoperability when different organizations, companies companies, and individuals develop extensions?
        
        </t>
        
        <t>
        
        What is the experience with interworking various data models developed from different groups, or with data models that evolved over time?
        
        </t>
        
        <t>
        
        What functionality should online repositories for sharing schemas have?
        
        </t>
        
        <t>
        
        How can existing data models be mapped against each other to offer interworking?
        
        </t>
        
        <t>
        
        Is there room for harmonization, or are the use cases of different groups and organizations so unique that there is no possibility for cooperation?
        
        </t>
        
        <t>
        
        How can organizations better work together to increase awareness and information sharing?
        
        </t>
        
        </list>
        
        </t>
      - </section>
    - <section anchor="section-2" title="Terminology" numbered="true" toc="default">
      - <t>
        
        The first roadblock to interoperability at the level of data models is the lack of a common vocabulary to start the discussion. <xref target="RFC3444" format="default" pageno="false"/> provides a starting point by separating conceptual models for designers, or “information models”, "information models", from concrete detailed definitions for implementers, or “data models”. "data models". There are concepts that are undefined in that RFC and elsewhere, such as the interaction with the resources of an endpoint, or “interaction model”. Therefore "interaction model". Therefore, the three “main” "main" common models that were identified were:
        
        </t>
      - <t>
        
        <list style="hanging" hangIndent="3">
        
        <t hangText="Information Model">
        
        <vspace blankLines="0"/> An information model defines an environment at the highest level of abstraction and expresses the desired functionality. Information models can be defined informally (e.g., in plain English) prose) or more formally (e.g., UML, Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.). Implementation details are hidden.
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        <list style="hanging" hangIndent="3">
        
        <t hangText="Data Model">
        
        <vspace blankLines="0"/> A data model defines concrete data representations at a lower level of abstraction, including implementation implementation- and protocol-specific details. Some examples are: are SNMP Management Information Base (MIB) modules, W3C World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG models, LWM2M modules, Lightweight Machine-to-Machine (LwM2M) Schemas, OCF Open Connectivity Foundation (OCF) Schemas, and so on.
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        <list style="hanging" hangIndent="3">
        
        <t hangText="Interaction Model">
        
        <vspace blankLines="0"/> An interaction model defines how data is accessed and retrieved from the endpoints, being therefore being, therefore, tied to the specific communication pattern that the system has (e.g., REST methods, Publish/Subscribe operations, or RPC calls).
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        Another identified terminology issue is the semantic meaning overload that some terms have. The meaning can vary depending on the context in which the term is used. Some examples of such terms are: are as follows: semantics, models, encoding, serialization format, media types or types, and encoding types. Due to time constraints, no concrete terminology was agreed upon, but work will continue within each organization to create various terminology documents. The participants agreed to set up a github GitHub repository <xref target="IOTSIGIT" format="default" pageno="false"/> for sharing information.
        
        </t>
      - </section>
    - <section anchor="section-4" title="What Problems to Solve" numbered="true" toc="default">
      - <t>
        
        The participants agreed that there is not simply a single problem to be solved, solved but rather a range. range of problems. During the workshop workshop, the following problems were discussed:
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Formal Languages for Documentation Purposes
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        To simplify review and publication, SDOs need formal descriptions of their data and interaction models. Several of them use a tabular representation found in the specification itself, 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.
        
        </t>
      - <t>
        
        The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML schema Schema <xref target="LWM2M-Schema" format="default" pageno="false"/> to describe their object and resource definitions. The XML files of standardized objects are available for download at <xref target="OMNA" format="default" pageno="false"/>.
        
        </t>
      - <t>
        
        The Bluetooth SIG Special Interest Group (SIG) defined Generic Attributes Attribute Profile (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on the Bluetooth SIG website at <xref target="SIG" format="default" pageno="false"/>, "false"/> and are also defined as XML instance documents.
        
        </t>
      - <t>
        
        The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models, models and RAML RESTful API Modeling Language (RAML) to define interaction models. The standard files are available online at OneIoTa.org. <oneIoTa.org>.
        
        </t>
      - <t>
        
        The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. The standard files are available online on the AllSeen Alliance web site, website, but both standard and vendor-defined model files can be obtained by directly querying a device for them at runtime.
        
        </t>
      - <t>
        
        The World-Wide World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web.
        
        </t>
      - <t>
        
        The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. Other SDOs may use various other formats.
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Formal Languages for Code Generation
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        Code generation Code-generation tools that use formal data and information modelling modeling languages are needed by developers. For example, the AllSeen Visual Studio Plugin <xref target="AllSeen-Plugin" format="default" pageno="false"/> offers a wizard to generate code based on the formal description of the data model. Another example of a data modelling modeling language that can be used for code generation is YANG. A popular tool to help with code generation of YANG modules is pyang <xref target="PYANG" format="default" pageno="false"/>. An example of a tool that can do generate code generation for multiple ecosystems is OpenDOF <xref target="OpenDOF" format="default" pageno="false"/>. Use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests.
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Debugging Support
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        Debugging tools are needed that implement generic object browsers, which use standard data models and/or retrieve formal language descriptions from the devices themselves. As one example, the NRF nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer" format="default" pageno="false"/> can be used to display services and characteristics defined by the Bluetooth SIG. As another example, AllJoyn Explorer <xref target="AllJoynExplorer" format="default" pageno="false"/> 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.
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Translation
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        The working assumption is that devices need to have a common data model with a priori knowledge of data types and actions. However However, that would imply that each consortium/organization will try to define their own, causing own data model. That would cause a major interoperability problem, if not possibly a completely intractable one given the amount number of variations, extensions, compositions compositions, or versioning changes that will happen on a per for each data model basis. model.
        
        </t>
      - <t>
        
        Another potential approach is to have a minimal ammount amount 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.
        
        </t>
      - <t>
        
        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.
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Runtime Discovery
        
        </t>
        
        </list>
        
        </t>
      - <t>
        
        Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the data exchanged itself. In some cases cases, the metadata not only describes data but also the interaction model as well. An example of such an approach has been shown with HATEOAS Hypermedia as the Engine of Application State (HATEOAS) <xref target="HATEOAS" format="default" pageno="false"/>. Another example is that all AllJoyn devices support such runtime discovery using a protocol mechanism called “introspection”, "introspection", where the metadata is queried from the device itself <xref target="AllSeen" format="default" pageno="false"/>.
        
        </t>
      - <t>
        
        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 oneIoTa for OCF models), or looked up via a vendor’s 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, 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.
        
        </t>
      - </section>
    - <section anchor="section-5" title="Translation" numbered="true" toc="default">
      - <t>
        
        In an ideal world where organizations and companies cooperate and agree on a single data model standard, there is no need for gateways that translate from one data model to the other another one. However, this is far from reality today, and there are many proprietary data models in addition to the already standardized ones. As a consequence, gateways are needed to translate between data models. This leads to (n^2)-n combinations, in the worst case.
        
        </t>
      - <t>
        
        There are analogies with gateways back in the 1980s that were used to translate between network layer protocols. Eventually Eventually, IP took over, providing the necessary end-to-end interoperability at the network 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.
        
        </t>
      - <t>
        
        Participants discussed an alternative which that they called a ‘red star’, "red star", shown in <xref target="red-star" format="default" pageno="false"/>, where data models are translated to a common data model shown in the middle. This reduces the number of translations 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 star in the center.
        
        </t>
      - <figure title="The 'Red Star' "Red Star" in Data/Information Models." Models" anchor="red-star" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
           +-----+                                        +-----+
           |     |                                        |     |
           |     |  --                                 -- |     |
           |     |    --                             --   |     |
           +-----+      --                         --     +-----+
                          --                    ---
                            --                --
                              --            --
                                --        --
             ---                  -- A  --                  ---
            /   \                ___/ \___                 /   \
           |     | ---------------',   .'---------------  |     |
            \   /                 /. ^ .\                  \   /
             ---                 /'     '\                  ---
                                --        --
                              --            --
                            --                --
                          --                    --
                        --                        --
               /\     --                            --     /\
              /  \  --                                --  /  \
             /    \                                      /    \
            /      \                                    /      \
           /--------\                                  /--------\
        
        </artwork>
        
        </figure>
      - <t>
        
        While the workshop itself was not a suitable forum to discuss the design of such translation in detail, several questions were raised:
        
        </t>
      - <t>
        
        <list style="symbols">
        
        <t>
        
        Do we need a “red star” "red star" that does everything everything, or could we design something that offers a more restricted functionality?
        
        </t>
        
        <t>
        
        How do we handle loss of data and loss of functionality?
        
        </t>
        
        <t>
        
        Should data be translated between data models models, or should data models themselves be translated?
        
        </t>
        
        <t>
        
        How can interaction models be translated? They need to be dealt with in addition to the data models.
        
        </t>
        
        <t>
        
        Many (if not all) data and interaction models have some bizarre functionality that cannot be translated easily. How can those be handled?
        
        </t>
        
        <t>
        
        What limitations are we going to accept in these translations?
        
        </t>
        
        </list>
        
        </t>
      - <--[rfced] We recently received guidance from Benoit and the YANG
        Doctors that "YANG module" and "YANG data model" are preferred.
        We have updated the document accordingly. Please review and let
        us know if further changes are necessary.
        
        -->
      - <t>
        
        <t>
        
        The participants also addressed the question of when translation should be done. Two use cases were discussed:The participants also addressed the question of when translation should be done. Two use cases were discussed:
        
        </t>
        
        </t>
      - <list style="format (%c)">
        
        <t>
        
        a) Design time: a A translation between data model descriptions, such as translating a YANG model module 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.
        
        </t>
        
        <t>
        
        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”. "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 semantically equivalent vendor-specific data model on the other side of a protocol bridge, as side. This situation is discussed in <xref target="BridgeTaxonomy" format="default" pageno="false"/>.
        
        </t>
        
        </list>
      - <t>
        
        The participants agreed that algorithm translation will generally require custom code, code whenever one is translating to anything other than a derived model.
        
        </t>
      - <t>
        
        Participants concluded that it is typically easier to translate data between systems that follow the same communication architecture.
        
        </t>
      - </section>
    - <section anchor="section-6" title="Dealing with change" Change" numbered="true" toc="default">
      - <t>
        
        A large part of the workshop was dedicated to the evolution of devices and server-side applications. Interactions between devices and services and how their relationship evolves over time is complicated by their respective different interaction models.
        
        </t>
      - <t>
        
        The workshop participants discussed various approaches to deal with change. In the most basic case, a developer might use a description of an API and implement the protocol steps. Sometimes Sometimes, the data or information model can be used to generate code stubs. Subsequent changes to an API require changes on the clients to upgrade to the new version, which requires some development of new code to satisfy the needs of the new API.
        
        </t>
      - <t>
        
        These interactions could be made machine-understandable machine understandable in the first place, enabling for changes to happen at runtime. In that scenario, a machine client could discover the possible interactions with a service, adapting to changes as they occur without specific code being developed to adapt to them.
        
        </t>
      - <t>
        
        The challenge seems to be to code the human-readable specification into a machine-readable format. Machine-readable languages require a shared vocabulary to give meaning to the tags.
        
        </t>
      - <t>
        
        These types of interactions are often based on the REST architectural style. Its principle is that a device or endpoint only needs a single entry point point, with a host providing descriptions of the API in-band by means of web links and forms.
        
        </t>
      - <t>
        
        By defining IoT-specific relation types, it is possible to drive interactions through links instead of hardcoding hard-coding URIs into a RESTful client, thus making the system flexible enough for later changes. The definition of the basic hypermedia formats for IoT is still a work in progress. However, some of the existing mechanisms can be reused, such as resource discovery, forms, or links.
        
        </t>
      - </section>
    - <--[rfced] FYI - we have added an IANA Considerations to match the
      guidance in RFC 8126 stating that no IANA actions are necessary.
      Please let us know any objections. -->
    - <section title="IANA Considerations" numbered="true" toc="default">
      - <t>
        
        This document has no IANA actions.
        
        </t>
      - </section>
    - <section anchor="section-7" title="Security Considerations" numbered="true" toc="default">
      - <t>
        
        There were two types of security considerations discussed: use of formal data models for security configuration, configuration and security of data and data models in general.
        
        </t>
      - <t>
        
        It was observed that the security assumptions and configuration, or “security model”, "security model", varies by ecosystem today, making the job of a translator difficult. For example, the there are different types of security principals (e.g., user vs. device vs. application), the use of access control lists Access Control Lists (ACLs) vs. versus 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.
        
        </t>
      - <t>
        
        One approach discussed was whether two endpoints might be able to use some overlay security model, 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 enables the translator to be able to translate between different data models.
        
        </t>
      - <t>
        
        One suggestion discussed was potentially either adding metadata into either the formal data model language, language or accompanying having it accompany 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.
        
        </t>
      - </section>
    - <section anchor="section-8" title="Collaboration" numbered="true" toc="default">
      - <t>
        
        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’ other's 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 <xref target="IOTSIGIT" format="default" pageno="false"/>.
        
        </t>
      - <t>
        
        Another challenge reported was that organizations did not know how to find each others’ other's published data models, and sharing such information could better facilitate reuse of the same information model. To facilitate this exchange, this the participants discussed whether a common repository might be used by multiple organizations. The OCF’s OneIoTa OCF's oneIoTa repository was discussed as one possibility 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, it, as the restriction was not the intent. Schema.org <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 <xref target="IOTSIGIT" format="default" pageno="false"/>.
        
        </t>
      - <t>
        
        It was also agreed that the iotsi@iab.org mailing list would remain open and available for sharing information between all relevant organizations.
        
        </t>
      - </section>
    - </middle>
  - <section anchor="section-9" title="Acknowledgements" numbered="true" toc="default">
    - <references title="Informative References">
      - <reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3444" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        On the Difference between Information Models and Data Models
        
        </title>
        
        <author initials="A." surname="Pras" fullname="A. Pras" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml"/>
        
        </author>
        
        <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml"/>
        
        </author>
        
        <date year="2003" month="January" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml"/>
        
        <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml">
        
        We would like to thank all paper authors There has been ongoing confusion about the differences between Information Models and participants Data Models for their contributions, defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and Ericsson for hosting other bodies such as the workshop. International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.
        
        </t>
        
        </abstract>
        
        </front>
        
        <seriesInfo name="RFC" value="3444" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml"/>
        
        <seriesInfo name="DOI" value="10.17487/RFC3444" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3444.xml"/>
        
        </reference>
      - <reference anchor="AllSeen-Plugin" quote-title="true">
        
        <front>
        
        <title>
        
        Using the AllJoyn Studio Extension
        
        </title>
        
        <author initials="B." surname="Rockwell" fullname="B. Rockwell">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="August" day="17"/>
        
        </front>
        
        </reference>
      - <reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf" quote-title="true">
        
        <front>
        
        <title>
        
        Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things
        
        </title>
        
        <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
        
        <organization/>
        
        </author>
        
        <author initials="Y.N." surname="Hassan">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Hartke">
        
        <organization/>
        
        </author>
        
        <date/>
        
        </front>
        
        <seriesInfo name="Proceedings of the IAB IoT Semantic Interoperability Workshop" value="2016"/>
        
        </reference>
      - <reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf" quote-title="true">
        
        <front>
        
        <title>
        
        Summary of AllSeen Alliance Work Relevant to Semantic Interoperability
        
        </title>
        
        <author initials="D." surname="Thaler" fullname="D. Thaler">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
        
        </reference>
      - <reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf" quote-title="true">
        
        <front>
        
        <title>
        
        IoT Bridge Taxonomy
        
        </title>
        
        <author initials="D." surname="Thaler" fullname="D. Thaler">
        
        <organization/>
        
        </author>
        
        <date/>
        
        </front>
        
        <seriesInfo name="IAB IOTSI Workshop" value="2016"/>
        
        </reference>
      - <reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/" quote-title="true">
        
        <front>
        
        <title>
        
        IoT Semantic Interoperability Workshop Agenda
        
        </title>
        
        <author>
        
        <organization>
        
        IAB
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
        
        </reference>
      - <--[rfced] Please review our updates to the [IOTSIGIT] and [PYANG]
        reference entries in compliance with
        https://www.rfc-editor.org/styleguide/part2/ and let us know any
        objections. -->
      - <reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi" quote-title="true">
        
        <front>
        
        <title>
        
        Starting place for the IoT Semantic Interoperability Workshop (IOTSI) Information Resource
        
        </title>
        
        <author>
        
        <organization/>
        
        </author>
        
        <date year="2018" month="July"/>
        
        </front>
        
        <seriesInfo name="commit" value="ff21f74"/>
        
        </reference>
      - <reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/" quote-title="true">
        
        <front>
        
        <title>
        
        IoT Semantic Interoperability Workshop 2016
        
        </title>
        
        <author>
        
        <organization>
        
        IAB
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
        
        </reference>
      - <reference anchor="LWM2M-Schema" quote-title="true">
        
        <front>
        
        <title>
        
        LWM2M XML Schema - LWM2M Editor Schema
        
        </title>
        
        <author>
        
        <organization>
        
        OMA
        
        </organization>
        
        </author>
        
        <date year="2018" month="July"/>
        
        </front>
        
        </reference>
      - <reference anchor="OMNA" quote-title="true">
        
        <front>
        
        <title>
        
        OMA LightweightM2M (LwM2M) Object and Resource Registry
        
        </title>
        
        <author>
        
        <organization>
        
        OMA
        
        </organization>
        
        </author>
        
        <date/>
        
        </front>
        
        </reference>
      - <reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt" quote-title="true">
        
        <front>
        
        <title>
        
        GATT Specifications
        
        </title>
        
        <author>
        
        <organization>
        
        Bluetooth SIG
        
        </organization>
        
        </author>
        
        <date/>
        
        </front>
        
        </reference>
      - <reference anchor="PYANG" target="https://github.com/mbj4668/pyang" quote-title="true">
        
        <front>
        
        <title>
        
        An extensible YANG validator and converter in python
        
        </title>
        
        <author>
        
        <organization/>
        
        </author>
        
        <date year="2018" month="September" day="13"/>
        
        </front>
        
        <seriesInfo name="commit" value="15c807f"/>
        
        </reference>
      - <reference anchor="nRF-Sniffer" quote-title="true">
        
        <front>
        
        <title>
        
        nRF Sniffer: Smart/Bluetooth low energy packet sniffer
        
        </title>
        
        <author>
        
        <organization>
        
        Nordic Semiconductor
        
        </organization>
        
        </author>
        
        <date/>
        
        </front>
        
        </reference>
      - <reference anchor="AllJoynExplorer" quote-title="true">
        
        <front>
        
        <title>
        
        AllJoyn
        
        </title>
        
        <author>
        
        <organization>
        
        Microsoft
        
        </organization>
        
        </author>
        
        <date/>
        
        </front>
        
        </reference>
      - <reference anchor="OpenDOF" target="https://opendof.org" quote-title="true">
        
        <front>
        
        <title>
        
        The OpenDOF Project
        
        </title>
        
        <author>
        
        <organization>
        
        OpenDOF
        
        </organization>
        
        </author>
        
        <date/>
        
        </front>
        
        </reference>
      - </references>
    - </section>
  - <section anchor="section-10" title="Appendix A: Program "Program Committee" numbered="true" toc="default">
    - <t>
      - This workshop was organized by the following individuals: Jari Arkko, Ralph Droms, Jaime Jiménez, Jimenez, Michael Koster, Dave Thaler, and Hannes Tschofenig.
      - </t>
    - </section>
  - <section anchor="section-11" title="Appendix B: Accepted "Accepted Position Papers" numbered="true" toc="default">
    - <--[rfced] FYI, we standardized the capitalization of the paper
      titles from the workshop. Please let us know if that creates any
      problems. -->
    - <t>
      - <list style="symbols">
        
        <t>
        
        Jari Arkko, “Gadgets "Gadgets and Protocols Come and Go, Data Is Forever” Forever"
        
        </t>
        
        <t>
        
        Carsten Bormann, “Noise "Noise in specifications hurts” Specifications hurts"
        
        </t>
        
        <t>
        
        Benoit Claise, “YANG "YANG as the Data Modelling Language in the IoT space” space"
        
        </t>
        
        <t>
        
        Robert Cragie, “The "The ZigBee Cluster Library over IP” IP"
        
        </t>
        
        <t>
        
        Dee Denteneer, Michael Verschoor, and Teresa Zotti, “Fairhair: "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems” ecosystems"
        
        </t>
        
        <t>
        
        Universal Devices, “Object "Object Oriented Approach to IoT Interoperability” Interoperability"
        
        </t>
        
        <t>
        
        Bryant Eastham, “Interoperability "Interoperability and the OpenDOF Project” Project"
        
        </t>
        
        <t>
        
        Stephen Farrell, Farrell and Alissa Cooper, “It’s "It's Often True: Security’s Security's Ignored (IOTSI) - and Privacy too” too"
        
        </t>
        
        <t>
        
        Christian Groves, Lui Yan, ang and Yang Weiwei, “Overview "Overview of IoT semantics landscape” landscape"
        
        </t>
        
        <t>
        
        Ted Hardie, “Loci "Loci of Interoperability for the Internet of Things” Things"
        
        </t>
        
        <t>
        
        Russ Housley, “Vehicle-to-Vehicle "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications” Communications"
        
        </t>
        
        <t>
        
        Jaime Jimenez, Michael Koster, and Hannes Tschofenig, “IPSO "IPSO Smart Objects” Objects"
        
        </t>
        
        <t>
        
        David Jones, IOTDB "IOTDB - “Interoperability interoperability Through Semantic Metastandards” Metastandards"
        
        </t>
        
        <t>
        
        Sebastian Kaebisch, Kaebisch and Darko Anicic, “Thing "Thing Description as Enabler of Semantic Interoperability on the Web of Things” Things"
        
        </t>
        
        <t>
        
        Achilleas Kemos, “Alliance "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation” Standardisation"
        
        </t>
        
        <t>
        
        Ari Keraenen, Keraenen and Cullen Jennings, “SenML: "SenML: simple building block for IoT semantic interoperability” interoperability"
        
        </t>
        
        <t>
        
        Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, “Research "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications” Applications"
        
        </t>
        
        <t>
        
        Michael Koster, “Model-Based "Model-Based Hypertext Language” Language"
        
        </t>
        
        <t>
        
        Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, “Semantic "Semantic Interoperability Requires self describing Self-describing Interaction Models” Models"
        
        </t>
        
        <t>
        
        Kai Kreuzer, “A "A Pragmatic Approach to Interoperability in the Internet of Things” Things"
        
        </t>
        
        <t>
        
        Barry Leiba, “Position Paper” "Position Paper"
        
        </t>
        
        <t>
        
        Marcello Lioy, “AllJoyn” "AllJoyn"
        
        </t>
        
        <t>
        
        Kerry Lynn, Lynn and Laird Dornin, “Modeling "Modeling RESTful APIs with JSON Hyper-Schema” Hyper-Schema"
        
        </t>
        
        <t>
        
        Erik Nordmark, “Thoughts "Thoughts on IoT Semantic Interoperability: Scope of security issues” issues"
        
        </t>
        
        <t>
        
        Open Geospatial Consortium, “OGC "OGC SensorThings API: Communicating “Where” "Where" in the Web of Things” Things"
        
        </t>
        
        <t>
        
        Jean Paoli, Paoli and Taqi Jaffri, “IoT "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti” Parti"
        
        </t>
        
        <t>
        
        Joaquin Prado, “OMA "OMA Lightweight M2M Resource Model” Model"
        
        </t>
        
        <t>
        
        Dave Raggett, Raggett and Soumya Kanti Datta, “Input "Input paper for IAB Semantic Interoperability Workshop” Workshop"
        
        </t>
        
        <t>
        
        Pete Rai, Rai and Stephen Tallamy, “Semantic "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability” Interoperability"
        
        </t>
        
        <t>
        
        Jasper Roes, Roes and Laura Daniele, “Towards "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions” extensions"
        
        </t>
        
        <t>
        
        Max Senges, “Submission "Submission for IAB IoT Sematic Interoperability workshop” workshop"
        
        </t>
        
        <t>
        
        Bill Silverajan, Mert Ocak, Ocak and Jaime Jimenez, “Implementation "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management” Management"
        
        </t>
        
        <t>
        
        Ned Smith, Jeff Sedayao, and Claire Vishik, “Key "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models” Meta-Models"
        
        </t>
        
        <t>
        
        Robert Sparks and Ben Campbell, “Considerations "Considerations for certain IoT based services” IoT-based services"
        
        </t>
        
        <t>
        
        J. Clarke Stevens, “Open "Open Connectivity Foundation oneIoTa Tool” Tool"
        
        </t>
        
        <t>
        
        J. Clarke Stevens, Stevens and Piper Merriam, “Derived "Derived Models for Interoperability Between IoT Ecosystems” Ecosystems"
        
        </t>
        
        <t>
        
        Ravi Subramaniam, “Semantic "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)”” (OIC)"
        
        </t>
        
        <t>
        
        Andrew Sullivan, “Position "Position paper for IOTSI workshop” workshop"
        
        </t>
        
        <t>
        
        Darshak Thakore, “IoT "IoT Security in the context of Semantic Interoperability” Interoperability"
        
        </t>
        
        <t>
        
        Dave Thaler, “IoT "IoT Bridge Taxonomy” Taxonomy"
        
        </t>
        
        <t>
        
        Dave Thaler, S”ummary "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability” Interoperability"
        
        </t>
        
        <t>
        
        Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, “Internet "Internet of Things: Toward Smart Networked Systems and Societies” Societies"
        
        </t>
        
        <t>
        
        Peter van der Stok, Stok and Andy Bierman, “YANG-Based "YANG-Based Constrained Management Interface (CoMI)” (CoMI)"
        
        </t>
        
        </list>
      - </t>
    - </section>
  - <section anchor="section-12" title="Appendix C: List "List of Participants" numbered="true" toc="default">
    - <?rfc subcompact="yes"?>
    - <t>
      - <list style="symbols">
        
        <t>
        
        Andy Bierman, YumaWorks
        
        </t>
        
        <t>
        
        Carsten Bormann, Uni Bremen/TZI
        
        </t>
        
        <t>
        
        Ben Campbell, Oracle
        
        </t>
        
        <t>
        
        Benoit Claise, Cisco
        
        </t>
        
        <t>
        
        Alissa Cooper, Cisco
        
        </t>
        
        <t>
        
        Robert Cragie, ARM Limited
        
        </t>
        
        <t>
        
        Laura Daniele, TNO
        
        </t>
        
        <t>
        
        Bryant Eastham, OpenDOF
        
        </t>
        
        <t>
        
        Christian Groves, Huawei
        
        </t>
        
        <t>
        
        Ted Hardie, Google
        
        </t>
        
        <t>
        
        Yonggeun Hong, ETRI
        
        </t>
        
        <t>
        
        Russ Housley, Vigil Security
        
        </t>
        
        <t>
        
        David Janes, IOTDB
        
        </t>
        
        <t>
        
        Jaime Jimenez, Ericsson
        
        </t>
        
        <t>
        
        Shailendra Karody, Catalina Labs
        
        </t>
        
        <t>
        
        Ari Keraenen, Ericsson
        
        </t>
        
        <t>
        
        Michael Koster, SmartThings
        
        </t>
        
        <t>
        
        Matthias Kovatsch, Siemens
        
        </t>
        
        <t>
        
        Kai Kreuzer, Deutsche Telekom
        
        </t>
        
        <t>
        
        Barry Leiba, Huawei
        
        </t>
        
        <t>
        
        Steve Liang, Uni Calgary
        
        </t>
        
        <t>
        
        Marcello Lioy, Qualcomm
        
        </t>
        
        <t>
        
        Kerry Lynn, Verizon
        
        </t>
        
        <t>
        
        Mayan Mathen, Catalina Labs
        
        </t>
        
        <t>
        
        Erik Nordmark, Arista
        
        </t>
        
        <t>
        
        Jean Paoli, Microsoft
        
        </t>
        
        <t>
        
        Joaquin Prado, OMA
        
        </t>
        
        <t>
        
        Dave Raggett, W3C
        
        </t>
        
        <t>
        
        Max Senges, Google
        
        </t>
        
        <t>
        
        Ned Smith, Intel
        
        </t>
        
        <t>
        
        Robert Sparks, Oracle
        
        </t>
        
        <t>
        
        Ram Sriram, NIST
        
        </t>
        
        <t>
        
        Clarke Stevens
        
        </t>
        
        <t>
        
        Ram Subramanian, Intel
        
        </t>
        
        <t>
        
        Andrew Sullivan, DIN
        
        </t>
        
        <t>
        
        Darshak Thakore, CableLabs
        
        </t>
        
        <t>
        
        Dave Thaler, Microsoft
        
        </t>
        
        <t>
        
        Hannes Tschofenig, ARM Limited
        
        </t>
        
        <t>
        
        Michael Verschoor, Philips Lighting
        
        </t>
        
        </list>
      - </t>
    - <?rfc subcompact="no"?>
    - </section>
  - </middle>
- <back>
  - <references title="Informative References">
    - <reference anchor="RFC3444" target="https://www.rfc-editor.org/info/rfc3444" quote-title="true">
      - <front>
        
        <title>
        
        On the Difference between Information Models and Data Models
        
        </title>
        
        <author initials="A." surname="Pras" fullname="A. Pras">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
        
        <organization/>
        
        </author>
        
        <date year="2003" month="January"/>
        
        <abstract>
        
        <section title="Acknowledgements" numbered="no" toc="default">
        
        <t>
        
        There has been ongoing confusion about the differences between Information Models We would like to thank all paper authors and Data Models participants for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF their contributions and other bodies such as Ericsson for hosting the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. workshop.
        
        </t>
        
        </section>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="3444"/>
      - <seriesInfo name="DOI" value="10.17487/RFC3444"/>
      - </reference>
    - <reference anchor="AllSeen-Plugin" quote-title="true">
      - <front>
        
        <title>
        
        Using the AllJoyn Studio Extension
        
        </title>
        
        <author initials="B." surname="Rockwell" fullname="B. Rockwell">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf" quote-title="true">
      - <front>
        
        <title>
        
        Semantic Interoperability Requires Self-describing Interaction Models - HATEOAS for the Internet of Things
        
        </title>
        
        <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - <seriesInfo name="Proceedings" value="of the IoT Semantic Interoperability Workshop 2016"/>
      - </reference>
    - <reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf" quote-title="true">
      - <front>
        
        <title>
        
        Summary of AllSeen Alliance Work Relevant to Semantic Interoperability
        
        </title>
        
        <author initials="D." surname="Thaler" fullname="D. Thaler">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf" quote-title="true">
      - <front>
        
        <title>
        
        IoT Bridge Taxonomy
        
        </title>
        
        <author initials="D." surname="Thaler" fullname="D. Thaler">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/" quote-title="true">
      - <front>
        
        <title>
        
        IoT Workshop for Semantic Interoperability (IOTSI) - Agenda and Slides
        
        </title>
        
        <author>
        
        <organization>
        
        IAB
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi" quote-title="true">
      - <front>
        
        <title>
        
        Github Collaborative Repository
        
        </title>
        
        <author>
        
        <organization>
        
        IOTSI
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/" quote-title="true">
      - <front>
        
        <title>
        
        IoT Workshop for Semantic Interoperability (IOTSI) 2016 - Main Page and Position Papers
        
        </title>
        
        <author>
        
        <organization>
        
        IAB
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="LWM2M-Schema" quote-title="true">
      - <front>
        
        <title>
        
        OMA LWM2M XML Schema
        
        </title>
        
        <author>
        
        <organization>
        
        OMA
        
        </organization>
        
        </author>
        
        <date year="2018"/>
        
        </front>
      - </reference>
    - <reference anchor="OMNA" quote-title="true">
      - <front>
        
        <title>
        
        OMNA Lightweight M2M (LWM2M) Object & Resource Registry
        
        </title>
        
        <author>
        
        <organization>
        
        OMA
        
        </organization>
        
        </author>
        
        <date year="2018"/>
        
        </front>
      - </reference>
    - <reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt" quote-title="true">
      - <front>
        
        <title>
        
        GATT Specifications
        
        </title>
        
        <author>
        
        <organization>
        
        Bluetooth SIG
        
        </organization>
        
        </author>
        
        <date year="2018"/>
        
        </front>
      - </reference>
    - <reference anchor="PYANG" quote-title="true">
      - <front>
        
        <title>
        
        An extensible YANG validator and converter in python
        
        </title>
        
        <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
        
        <organization/>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="nRF-Sniffer" quote-title="true">
      - <front>
        
        <title>
        
        nRF Sniffer - Smart/Bluetooth low energy packet sniffer
        
        </title>
        
        <author>
        
        <organization>
        
        Nordic Semiconductor
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="AllJoynExplorer" quote-title="true">
      - <front>
        
        <title>
        
        AllJoyn Explorer
        
        </title>
        
        <author>
        
        <organization>
        
        Microsoft
        
        </organization>
        
        </author>
        
        <date year="2016"/>
        
        </front>
      - </reference>
    - <reference anchor="OpenDOF" target="https://opendof.org" quote-title="true">
      - <front>
        
        <title>
        
        The OpenDOF Project
        
        </title>
        
        <author>
        
        <organization>
        
        OpenDOF
        
        </organization>
        
        </author>
        
        <date year="2015"/>
        
        </front>
      - </reference>
    - </references>
  - </back>
- <-- ##markdown-source:
  H4sIAKeZOlsAA7V963IbyZXmf0bwHSroiBXZBsi+eOweRjjavEhqqkWRS7Jb
  0w7HOBKoJFDNQhVcF0JojeZ99jn2xfb7zsnMyiqAbHm9K4dbIlCVefLkuXzn
  ksnxeLy7UzemSP9u8rKwx0lTtXZ3Jy2nhVngx7Qy9804M5NxVjZ1Nl6V1UM9
  L5fjL7/e3Zma5jjJivsSY7STRVbXWVk06yXeu3h592p3Z5kd7+4kybRcLM0U
  z75Y2/oFP2nsh2acZ3UzrteLSZnXx0n5xe/H/Aojdc8XpTxel1VT2fs6GgHv
  DT9pqqw/STkNPzVZk4OsG7vEUMl9VS6SZm6Ti6KxVWGbpLxP7uZZMauT/Yvy
  7iC5tQtTNNlUnyiXtjKTLM+aNb6/uru9OOAE7x0zkq+//OqPuztmMqns49M8
  A1tNAyLw9LfjL/8kLDRtMy8rcGkMRmI1bw6TN9nCFvZXTqB78Mbgk/jjspod
  Jy+x2rouC34AYrP8OPmFDx7+og/+xboHDsHOMP73h8ldPZ2X97bIZt0U35ui
  sPXgK5nmpFokb5v0MJpmLg8fNuHhv5hq0ZvlHLPMTW6rboZz82ijD2Xsy2xa
  lXV530SDp40885eF/04HppRVC9Nkj1ZE6ubV2Td/+MMf5N8neX5rbTG+zttZ
  VshH2Hzd8B9rbKpsNZ56U66L5LZp06xMXn5obEF51cfDPvAHt4rTw+SmnD6s
  bJ7r534tW76Q9bx4oT+Gbf4jf/7+5O7l1cmtp8tUMwspnTfNsj4+OlqtVocQ
  lUMMcLRajqdQIFs0Rxcnp+N2mZcmrY840NGX38jfY37hRjxcpve9xT4ttDf2
  H21WYYdvbX4/Tm09rbIJOSNPQtfAiOSyTG1e+xWNPeEJOP+EsjzNu8vD5Ify
  0VBG+rzb8sUzvINWQ4xtze0/9s9fV+XU2pQEHJMWoa28e2b5A0UNIvOv74mX
  vbpdLEy1Hotx2NwY/ZbEuhf4d2aKqRXasD+5fQTxsFlPL+Npbvf0reP1xsfP
  cPq0ytKZvTMfyqJcrP91xpzrzE8whNulMyZ+yv+vqxMqTl5/xrKoC49ZA5k7
  8na7PhI7fmRmtkjN0cZCgnRRUX7TcWBVJzJQAq+b3OYZtHHr2mU5YO2T63l9
  cffEgmZZM28ntJyOdPlvj/DX8khyVua5mZSVWFZxj3XWlNX23VCKOPWTNL3/
  HDv3DI//VeaSGFB6abIiucaGkcnBbnBtNHTXBm/+80x/+/7y68vx7XQOKvpe
  5uryRL9N/uPybaJPPD08nh4M/y1/vrp8dzIc9h3GzWbzZmX534Qz7MtEB8nV
  5Bc7bZL/gU2ry7aacvdmQFTP7d0TM0OUntm1Sd7apiybuchTvbTT7D4D9AMn
  66OZaZq+XJ3cwRL3HnqanlM/NEnYRtn1zyfvXveZclIkVn33JLcJv08eDbTI
  QGxFpWCVHm0F+YD1SJZrzPqMj4c7Ov0FIpa3nZwER7XxzTMWprh5Nb4tsvt7
  W/XpxReJ+wKT3sIPNEfduvNylQCtVbN1Asj7AOda67NPM+1dWaVQAehChqWm
  7RQL30aRAzwvP8AyV0OqPBry3z49XQ+kDee4Wtri/OrVE9IDBS3S8p4635v8
  Dg7bvUlnTjl+Rmb1wcHs/7a7A7Q5HidmApE3HID/AyypEwQvLSBwkyyr8pHm
  NTFJ3XlgwoUXwazAHES4Rkb4J6KAF6PdndU8m87huMuHZJkb6CHE7havmeQs
  N5UZJWcQT1ivIsO/CbNMhee/+tP4q29HwsjDRDgC/AtBnZUm91R645isTE1k
  cF/WFGuTpFk9bSXa4oB8NBWhwaIRUiyxbgMbVCdtbdNkstYArMjICfocxnum
  Suvk3D7avFwSCF5VMzzxq2pssn97flUjxsGkZsq3EavNsbABF0wjk2PG3Cl7
  kpu1rWRF2IlKwi1Gh+R+9isIUGI9+fVIKGIkyKcx04KuUYnA5Hy69uQi4MT3
  bYGZHcseM7vSNS2dba/J/aabOzGVxc9lbR1TsV+eq0uoYjbNwJlGB0nLpCib
  pLBTW9egN19jlPucZrY/hMqpvtRDxifY2qzBCy2mPS1BNSTl5PRglKiUlMpl
  C4sSb/Chl+ZFlqa55U+/46BVSfUmWz/+rrbyr/FXn1TQP2PWZF7m2OVyOjVk
  NgQruFvEokDVswLyATbDjtRQlArmqJiNMeoiQTDfOnmhgjXwLfjRhQK7O35u
  3T8MUbezma0RWrdCRYpoY6obMgwfwL6IXreTGWx23WRwJ0LREqEruA0zjx2Q
  0AU00u4VfGB3x95j1IaPQG2KteerExySlMEy0hkmkzIl5SAxW9AgEBIgnkyh
  K3BRmA0fwpMsQMhV4bfYmbJ6qIkQLw4FAiCVE1EKJ5NO/CcWvlqodoC+R9ko
  seI/TZ6vaTisKq9bL0W1bBs/Zz2Fqm0GXy8LBLkWUVEBo3pn6ofkVUnvv8+U
  y4HXvG4jYZOKghp+3xYqSz5kOjnFakSpllg/+EED6ZQOr5d8yXazJZ7pMAAM
  xtW0kDNCyqwq22VgGIkRqX4PnCmf2A9QtDqe/4ncy2jDzuzuTGgasIsL+CrZ
  XvkHNhQEgcuH/4xNmzMTkZbYa5M0FReeli24vyjbQojhkkSk3ZjQV9iEFQWl
  KadlXsPoO6nHR/dZzsXBgnHK8Iws/uQJ+yhLcMYzJ72cti7zVh65rwBAROJG
  CTMfA6OL3aWVWoNzC6MqdC2WrIW7ydejzsrROcCYmkRzJ2BBpgLHnzmlfLmQ
  sN8pjcuyEDLp5zAiRiesrRPXGuR1ZIvtgF8qphCeOYRgNocQ7+6Q28IEahWV
  BMQ4VRMl4tKBeDiEAaQrpiUj+jH01hI20H93G+BIcpITkTlSisrxFDpleyvQ
  hR0CMAJogefd5Gp8YR0g5dRUFZB5BkfrpRWgz4KZ3NK+gse2a0TPBqtuiDBu
  7KJsrCYnUppAuP082b+5PjvAVGsIiVrchDA1uXl5e3ff5u6zw+RVW5FIivUo
  caqUqiRjEicZ5JpRlwaEu07qbJFhzz0GqNvqnvhjAhuieCCpc8YN8GO68VkV
  C3VKa0O9GmE3TSqJsnKL8jnG1aAS9jeniNV4y5N5bx6xpABAwlaq5QcEEa7u
  7jzCo4qibWhDX2nu5m09ChYqhblM1Ut55wn2BR+Ojytr6FnbRn9QuytZ7QdL
  B4hQj99YRboeUjR2XN6P8cPYECWoOjuvsFakQY8pKAdfzgxW+vGjyyN8+uT+
  +f7206dDWDKHJaiBHelAbU594S10CeBzBRmaCLWiiDkiAHLe0DE09TE58EXy
  nvvstESI9UaTxGZOqwca6xT5O30Z3GlzCVygXRtPwT8ArubZg/1uc8KqzGU+
  eQePmmLWIpTGpnhpryXCjb/JJMaKEovxlIKtOlPzzJQL2xg+6fESvkaASTAr
  7JNB8PcCW5tkNEm9bKYb+HvEVFOsegV2QVmhRZvIVXxvJ7MDLx3wsvJP0ESG
  UKI1eVBLH4XihS0LgrQxcckEn9gUIcD5ysRrQmx+3ahWtkzqEx11qmgjWg4Z
  LH5PLIJ9LPNH6jPMAoKsRW9Xvd9XYVa5gMnI4dcFJEvCx4O7em7E1+sO1wmd
  5YCtwdfFZEwYvyxBfmJmiGMABFUrxfJSd8UcxVxwo14IvyqKANZMEkABVM9t
  hizaOLWlLQGUtYIyhuzxW9WHgnUJU579o7XKKJ1KPChDhjpz4sB5ATApIHxv
  sOL+kIB4jMIcSgBKdEvMiilMEUg0KxBcIITY0FDH3e8U4N/B3mdFmZcI/jt8
  /3XA9/dZBT4ilksneTl92GacN0BEvCdDL+utWvJYTs2EtmrtYE7VDOIyGOKP
  H12N5dOnXiDNpwXpAB82RIC1hfEzjbpKCPyygZp4GshYF2lUxE34cW/TZu2N
  VOT5fmUbusrGZPTnqb3PiqwLJDKPVTlcwsTHXrTkPaaEucNGAgYhpnOauzv0
  6hhPcIJ+jDXKLuFlu+KrnZFTpNGVRzw22N2pXMatDuAlFW6IsO7F7whZexrj
  IJT0/gc4yWKcPYb8ex4cxQq9EjHtYhT+LK7ho5TfZhcCkP784psXnxiLdfyU
  Gs7ujqTJNq2+rr5Wmh8z4B/JkzghmgMrMIQLwuRzK86GS5XuwxKrr30gj52t
  QF7PxEip8GJjj0WTJjbpdkD9C8DJvj2cHY4kXZczcYsQh6HVAdlJRCQmcfDw
  j5dvR3iwwYTjmxjCnWdmBgDNWKuZHh4oNSHCEYJUujTgmiPitiLvx8ljvQR+
  +vOLL198eorX5xS2jsmRvgXmdkLM72BhwTA/Nd0ZlAg+n8G247NYro7VZMQ0
  bwWPZX3CJdPhwNLYZ2L9cmSltwRm9oPhe7LA4+T23eV1cmkKOGrZ7YsY5CfJ
  KU3W/uXF6QHX0eb05u+/OdOQDNEUnetSZt+/Oz9wkdpIE6+6syPNfcv06jZG
  ydXZq+4HSSLAB3w+mzfKkkGkB7oVuD6HrRaGEzJMmcChL8LE2IqKGCDtqv5e
  X2mQEsikKxF7Bc0UbAj2cjx2XQxRHLA09AJFcCtJvQbIW0i05ESUGJ+IZl6m
  OtN1KymDo9t2IpAFkMd7HPXuCBYSBjL1wVZO+UgmMgxN5EMkZRNQo09dLqyR
  8J/YgCU6Bj/EhxQUvq0+3ucg3cPU1Uf6Bw3G5H0NMqTm90FAqEt80iK6lJEk
  HA+HUsjYljZVZxOZ9NRh2U6Gdnd83DCSmi9MiTpcF7ziQZtmQH/rJYesQpih
  n2DSczaucN/YLcGoFAolm0xnH5QyZhjTqjAWFnxsl1S8CQNXceyrDMEb15oV
  rUI4LFghTQQGJHcGp49xHaZTVvgJfCa6duztZxx1ZnpghPLtEnZB63YdKlvT
  DftaH/xwjNAi636oeELQ3rUL1qSSTFQYQYs/BGixlZABQGoYXy5hceH0MSEA
  uo+gMfSEQTcxp2MapHguqekKqgxpOm8r33jRxWq9gMdHlerrHPSwqQuAXmns
  8dZHGLL0c8dO5f11W4FNxOhYU6nEInYD95gWVltJhZs6IMmERFJYImwX2aSd
  cfOJK0TIUWw1MDY0sbcwJVVI0S8Ek0IqFU8NrD2IbguHNTpbol9lDYMXiD2j
  dR1kEG9JWgE2P6ed0frsykgFIwqzSqkC1s7SOVgiC/TDLR2btqnlcEaho5KZ
  daN8RK71GpjiCbNdoXdh/+ry5ID6tZISKMt+UljBslq1v1IQdeHix49xBRXi
  zIjOOkuovNflaHrNLyfGgILvZEym3dS09BIanh1cxCO8omGRUEBouSpo/uCA
  qVQsrSJ096vrFSIDRHnNyhxM6EkDF4J9woT7rG8e0EI9ZlOXH59CIyEmeLSm
  SeulPZLdnWhsKf69BbdeSslPV/PsWFwIlGdF1xfJmSbwikQzWX3qV3YC42GJ
  ND5+xAefPqkHFp7kdRmWh10mJxmtyW521qq36WdlUVit2K+hl62rz2Dzz14d
  cKF18ub26p1391qocmBNp4qjEpc7vTnBzI2nZZuqqcX0u+v2u7+vGsRiwIap
  +4vyzrDUGKjfaLURWn3lU8orknThpP/RI2ebCfAJ0aDOzIIOFGiUEImVAonV
  nY819ReNM1gYdPXJlXmfu7EQbHHCPRbjm0y484FRAtQfmdSuxn6nFSrpRA6G
  lxOQWmgOX4s12C7EyZXkPA3zERBKX35YUJqqtqBvDfyFqufp+D3QSPLespWk
  YJ9m1i6SfQBIJxqkP3QoxGjylc9yJ/s356+01vgM+30U0dZKnzq/Pr/F29jJ
  4UaBLKqZJBslE6VT8OxnkYDhr8TZiUNZwCRT2X1ORxGaS7gfPuPMzjCYWhgH
  xXd35KNZ+Ig1ZR8QcgrvtZ7M/eVcX0jKsc5mxeG5XXYZpoqJXAIodQSjnoj9
  lNWM3rVJcndHWyphR/o9lrDdktBhQmAFLFQJjHGUE3xhHRNDD8CF+YpD3+P6
  jGZnG6AZHuE62iQIlSec9vVWqJxx8iz+RtM4fSZmurccfHdnWS7FfpKzJHlu
  c5f0H76GmX2Iw5iIwyzXmBi8kKYUcR7SixJRqsN6qtJyY1QSuGjzJuMrdlpq
  0FBLTcJ3RMA56b+YWv4xpLwCQtq+SgkZ8aU1tZTj3G5LxEcvCSdjqzGrvEG1
  46B9lEzzzApa1h4agimxNfB6QZDP7aSdzbgHt+1SS/sIicOHKq+R1AkrQgyr
  9MKfqpdOJhUAhuRxJJIQzNDZsUFt6qisQii3gVtiIAeD6uM8XajYoAXQ1iNB
  0AlUtLA94d/deXfzKhm4ad+Ho1Hjtp4bbFTU9AOVUEl00IemJKuXuVk/7+C9
  iZ6skw1XTgnjWz2dGG307qh6xr0+gZjE06K8Vt/rTZoKPsvnAWrZD8SKQo0p
  wkTKxzgvQZfjDg44n5MMXE7s8jmc2zsfFGxB4BsbN/Q5XyR3iC7qPNjLOxdd
  aP2kbhdLr/EieH77CxdmSeHX+HRblLlBzCecQEySlVWWPADQ5pbNqT6jqlGn
  oKipA6Lflysr6XbJ10lSXcMlF2BLsDgNPvGoFzdKeNlo/tV5HAeAV4hUpsZ7
  uYX5BYK2pQjsoifsyb2EakZVFhGuFPskl+SQhE0QV2J31BB3ZW56rNCWEGoZ
  WvwI3TSYHYvkN5IWYKLGKnvJNCxizqy/tCEZNgbEbIUHyMCoOHOxLNkwjOA+
  8V1K2lDh9waRc0a5MItAZuzlFA+JcaN8sDuJUYpYRONlJZlkhS9mmhB1KU3q
  7NT+MKCS3I9AD99mAgALBjcS7UIYIlnAN1oyyK0u6hKqxqzKKGHbCmIzSro0
  NdeuFCFr9lXaoTim68LAnGgvSOMkG6CELsIsD2TnIm5yNY6L+OYQ+IH7/UGK
  WdyIUH6AkvuaSoD8weeEUqsm5Txkp8BqUW2j+gt7lWqBwxXTdPFUxxvH8HO4
  JjJizY/9h6n/UPeolm7eYJFZj1VpCjW/qCyqJcAgLMxBsKElSsHLC36I1EXT
  UomVxJa6zGYejU4tAaxeh5DT1d+IoIVHw3y/st0wQZHnXHTf22uZoOgEmZm/
  CTGUxmtCqz9C8fGj+5eDDX2U4w0WGwb6NrfGNOJodbpqyFs6G7UUfmOxYDIl
  qxeJa4lgQaKLdPboba2rQwTmgILdHaL/LM6TOjVT5nYgsIubnYh57OvNPSaQ
  9aUW7mhNFFgF1RlpEourCas4VFMeqFlIs/OE7kgMmafJ9HMokjJlIVvyd2qC
  dnemedmmUQrNZ2NdhCjTMzvt2lsGgzxmkEPny17AJWmUVVZdvPQEd/Z92SgL
  MZvsIyXxwMV8rBy5trDNtW5OIBGmtJQKBVGL5zJji+JT73aVUXk5rttrqY4+
  Ql8R69erULon981BUq+Lxnzod9vsTw6YPh8DV1T9/FnGbIQJJaEuJKah2Z8e
  dPFHV7nQfs9ms7TnMpqRv4/SmP8macyLQjobUqttjXC/KtebrYBd96sv8WoP
  meQ9RWy4z5LhjOytBzejXtFYjDep9SbfpU2D+ZYd6JtuzUrT73TW26GHkfaq
  ZuyicVATRlw8fFOmZj3yLaZO09jsKA05cE5W+vV6BV8sJU0zn5kWd59jvHQ9
  yJIVDgmLvoBN8H1sVegcWQ/El9HyfH9jNO2h6zjEPGLYd3f2i//8+mBckPET
  dmwqrnCKgb2qG1ELdSSdGTEIRUppMxXbGWiZsIDt3v7q37/9Mq6ROnwbO1BP
  IgJ/SS8Me4yS5CX0m0VqqMHFtXZuqx/XOrdCgrkNjcBrEfmmHFuPnreU4HvT
  IXCj1jRtIdo20vGyuKMXLiSsMPBO6vWwlPzWlVoJ3fAXXF5r/SNNpBdP7Mgg
  vuOAWCsrHjW36NHkreBDx1eEPDx8oG4ofWTkBzm30l8o1KjsukXS5YgYOiwx
  sVPtCaylX0c86KMqmewSfa9LCK9Z0NWdv46LEF14O8x5+yrT2js0k7yghWEn
  wotRlx39+BGfjvkpM57SXlvZfhhZdaxTwd4WDYQBhS/SkO1EnPYb2+eQRdEu
  JlTn+3g7ohY9pz5MPHOqr4vQfjmxTgMOyAipx3g4Lw2VbVUz2grNPXCRtCgr
  YVSIEwbgUHPoieeMX8BUDKrY0//GHzlG8fsx//w++cw/7nF59b/kk//63Ffd
  4/1Xx+PffA+PbH31N1+Wr+NXe2t95mX3VbzW7U9sfDre9vC2x596cvjs08/F
  T4anxtsIw2cn20kOBB/h/38bfvv3v//9KPkb/rvxnjze241x/w90MUkOXww+
  7e+GTHi0OfZh8p/J4QYx7vFn1nn0Qv56seVVffyf4uQzzzz33Ofu9FMCtPns
  03IaPX30t994Nvr26G/+tSNh6m+rIJ848jvu9mwLl7f90Wc7IfvcN/2z8uaR
  F6DPeLV71hu5j8fJ77w30FNnf96jnX1xY+X8U/WC9pHNPEcb3VP14Z4AzPdz
  1jp7FWyH9VeuI57HyrLGlxjbhUv60Y+F9qiZeHrXKB777cz3IbHfQWvKQGG1
  OhHxmpXJWBAXX5l8kZyX7GgVAGqSPW/n91yuq4RXEk/RSN+OpIiZk1oFMhgY
  65fyBrvpXQpfDlOwSZkXaAzbub7z87MbMhUaEF/CKQagEgoS/oPt799q56kG
  3T1HvAXCSMDT7y/tXuiRNDVb2oI2XrgjfvCZF+lCA8bwrbkdasaoDmL14JSb
  7pK50n2fccvzg2crVZLSkmzEhCWSaojIOJcrFXC8PkuYxs/Xh2GFev5s4nnf
  sUCaPvJskYUGs4pFsESP7+j5PbtsHByoe9ix/s4j8EFDCNMh4EmlXVRkhxdN
  OR8j55YiUXY9xRM9VsNoflVGzbpbGjwQXbIYSLFkQuNYjuI8h2nlvFoINqMm
  Tf+WJEG6pjQFd6wyH0lxWrN/vLJG0uLdEaZS4p5U21XSjiSmaXzfy2YjZYi8
  XdOzzNYBwi4Cj8WIC0f4zLSZW7XPlcVrl8xszrN33LJVub0iIm3JzGax4GDy
  WVlBlF02UQ83hdNlEUyUFCqEklUg9skN37MVEHcaJ+J773YxLEfwR81oDQMy
  33Nj+M5XxOmNPNHh+9Ax58rdmY9PNrJbskqTpXK6IDS0Rczq5EBW6xM3UWvk
  cO2M9FNXrQspM03aJnJoVLuawslOPxntqQQmfY5RLLneXssdvxkznYx9pAw8
  T1Rg6jOkjZIeByXY6V/YEfWyPNnbFYjvyZskj7WSmMuBV8mDQ1PaupGW7NRK
  Rq+QagfFJ+urnSSmvdvRZvg5WZX0ROFwI+JjS57WLLVMqGcn1kvHWlpAzTt3
  ob3zHWocfO1UixHar9TlzZ4+teVyS+fMs/icsktFdzmmP2rDJaL5aqYs3Xoo
  G9Rziq5hlCcxWqfHvk7hcu1RBTY6AkWzEHW71p3tG7wbfpjrMrOqd3Rtd0cP
  gdTdIRDyUwu5SqKWGOU9zQY/RufGfZFp2OrQVdk2z0x3Ehmd7fJnz6Wyxdxc
  x99D9oVrWF0iAmZ9aCo+YsQUXMgPOuuqTXGDjgFWJa8v1OWGurJmV4LOQCyW
  vt2NfKg7U8Y044YxH5RK+20MddNOZDD8JWmypquClY4c5gXcIWX3lW+W1Zo6
  n2yXs8qkIYPD86SusBbK35W/pElAw6CAzxeEIPaLgvr6fu0Gsmk4dYuHILTX
  F37f6l5Fo3aQUNxWyv9AKQo7lrOO6mWijJCePtH0M5tzedyZp4hpCTsGuPJf
  r1J74bqi6yneglyMpJApczmOOEK8oZf5fIGgT7EWZmn9K61Bm9QsvdnxdGi9
  a82D7q0ekWIhKcoyp5ZHiNXDu2NWsnscy+3IIsg6RoUzozmorWuknVg9JZ+q
  oZ+3MPRjJlaFYYPGzkLAgGdueEqlDpJ0OfwmdOx0RUjp8qVexSd1dndYxw09
  2j4XaGZ1tN+uP/q+z0Y5Wi7H6X1bjjZmsUM9so0mZ1F/zYTXBQ96AxRNs16F
  ylc9pAFbu+gVh6gcdpl07DKI1gdcdX1OpQ8p1m3dt6pMWTGeUMFhr7hW+ZId
  b5C/BzWB5KUu+tT1GMpdZuVd52S9bVSGjJx7CUJG60Tv1LN6XKQcYHZTsTMS
  m8T5WQV1/eY/3lzUfpfdMV5WnSjXTOezDmYefJ+DOxVwz0rtRNgi41OL6NGC
  LrkSWNfq6jmiRnKORVTaAO/PcnMIllSxKiDzXO924HLI4hmhe1RlEIviRgzn
  90KlMDQFVpZGMDrW3PXgekw2UuZr2Yxccu701kL3COTO3F0SLhzpXOqfPnXp
  fgkJCG6DuNb+/Wn//S5uEIfQNS1HXWHu6GI0wn02aysHEdWBuu/icHVQOnEY
  SNbjQGs5Ea8dYdYwUNdv4otMvUl5ECw8q1h4JF4Sq4Vch9YvV+bBQjqZ+aWc
  uHayDnzST/N8MQ3IRvPeBhOZmxfV5XlVV/+Uit0jhMJpMP8Z4ZADHcrxWE/Q
  yAGICh5V72fZPzl7Wx/Ii1OzVOCO9biO3pWwyFOyLDFw1rWb+nNj6Uiq3HK2
  JOYD2/OYisBDWKSrl/QZ2ANxEWIFAuMJ6drXtSNs64+caVSqVxGEen2HXlYa
  QCh2hVCG80FdnGec0ZAWNVEmHqcxa3qmmEgsj9cl1f3d85hOBg9df+FSGNpP
  QVhJdq8r71PRFSq3lCtc42tW9SFv1EzpVwyI1VuyO94xN48aPUcEszvM6CJa
  ObsuVlIMEE2A0q19HY7g7l31l55hW0qHTwbH3B53j4wc0+tR2+sGSVM1YL59
  gdbYZi74sN0Bj45NXT1alqc14bVXOXnQhd0BkayySjq6pblRlynPiTuDgj2a
  6VoP8REg9mytwk78rH629/CgqQmqL0Lmcos8WMNWLKJzwk6advFem/ZIEY1n
  dK+dSO8ZCKLpcIXW2nU66Xx153r9keYfL9yVRmEzvXWPrgnsleK/3X6iqNs5
  BitS7iJsJabpXwywKHUDIL2hgTqu3x+qUET3XcmZrUrO1TjB/UUwxsJaOjXs
  hNw30laVg+oOy+l1UE6WNGTsdwqEQqUc3w55LjVt/K470F6/CNPpa+yjYptw
  6mxhOEVPNxovWHGv8H7rofIpo1hGa9165HDTvZnS2vILaRjwnU9qtJ84VgYt
  cUBGoWIv8oPY6QyB+No32fjLWthZ64IBOYMWN9XEx9IO4w6/Zzg+WHKapcJv
  dthpUIt1ZjyLHTEankwPTQ5bSj+DzY6nEe8E34RbvCRPsOXCmOQ3GE4cuV3a
  nRNhH4xjYsSy4Ev8rWyhKa8v8tordHX26kUdmpbiE4H9bJrRfub4MgN2tDmD
  EfbApVhqdwgTLJDwWkENrVW4XKcL9SvaL305i8iKJIxXrChDpEdDawDlA8dt
  l6mkh5x7iGcNbZuuH6YnFc7HZrQY5cifw/fFCW8BIDehpcLy/id3+ojnf5IN
  BpnQfRqYFKUirJHA1bWC/9/o0uAajW1apNT+tho54KkZ+P65zERuSP2Lu0SV
  1wXqaQhgM9d/XPEO7YKHitVuhfNEeiBwy8nR4JQJyrbfWeY8wMk0dMKqG+mc
  wL9rucw6KnirjHLJFA8y8JL3rSbxpXk9LgcEI81IetQuC3cD+nvO9W6QUkOX
  WFA9gUs5qfwhOTnmIVjeAcAe2UUGIxBn9r768lO4KbKXywt38/le/O6sanT9
  C69jr7LkpHp4KGHtb0y+nCfn2HKQGy5q/9//q7C/jnh15tzA4f8g9zaO4jvQ
  dW167TqICVepDxdzegzOs4ADsgb318Zr0ksBv4hpS/Zem1TusONM16FX54zo
  lR+9LkdSAeUVLAgpCF72OMaZqXidV3JKISkQy+y9KzPJJPUzHXUyb6umlndO
  EddCZc9ylizxhhRinO52VyaIvPpTUMG1IIaVY+4y0E05sRUGqsws40C0OX/N
  ZqfYwrO8lesv32aTSq7yJE67uN7Tgyk8XEZbYMlbz/ifwCZwtsRHd7yFySR/
  LZsmw7ivTFbN8f/juJ8rd9T4bKuc1pEO/NM2ywVynrRNGd1qJJfz8vMzFyl1
  6F7o+rHImOUDFD3XdC6mdhf3XvF6IG7riQ9IoDOcfnjXqDK4WlMzX5oaarXA
  KBs3kvqKxeBiVXn7trFLgplXLEMST57AaoAbZ9IPydEaOhtJEN1VrVwlr9AR
  H1/MCjlh191frQKlkBZWWqVmLidaEHC95iWLvBSizZKfjQTgs+S9zVaWjL96
  JHftShrShNnuJgAi9LRGYKmCcGepHlUqUvC2nGbywnDRT19Nr9LESvz3QJW5
  RdSy95NF3JJbdvK5f8pSoo8vivsKLK5aDTLP4ohKh+z9MoZNFd/4RQpk7vXt
  lTtUpHuvI8EaAAG9YTPmiJ7h/BSs3dzXO5eSCnfRXiLqCXei6vbaiVHe/2Ds
  BJ5vTs2uHkqEgLCyU9Gj4W0e0M6XTOpqxfLpm25dqpAnPPvMPUE0DqiHcX6w
  i5KSHc6nSm5q83rHi6Lg1f+c/blfVZDLMYavD7+EnIIvF8n7119+A97IHf++
  j7WWcZQQ2LwfMAB2BNJ21hJ/Jm+s3HpJsm5tcfn2WMNd3o7nVFkvVfJptFBe
  HPZ36l4hTlmsEXXMkh8yqN/PbTGdtzmkvoRQ/4xvZ7YtIGq8vmLvxtZWLvnF
  QmEB5KKOzgqKzHWnX3lPg+vx3+CF984k8CSqGQlNQ9Hbk9HHp5Lg/Z4JQ7mo
  w9tbfcc0gGvcMvc7GEC8ASgqkncMYfFPKuwPuUEgBu1rHqzw7zd/rYSErs/+
  WgmZ/geDnQII/1XoPYERMTNa02nfCG7ceFk8p+SnMGrr5K3NJgaD9p2kW3Q1
  hdUrYa3LtYopW/OVIisvr+nn3sIfYKN4U3Ph2cnF+LsaT64vXEFCWgqExe4y
  AxkLSOVBTgqymVZ0jorbSDXo2d9PAXMrd73GaVC9f1fGlVP4r20JLylHp7qD
  1rSnr88wMD9wSgYqj2PDhQXsvWcAu+f5uKnKb4CBwbAyhzDfmX9ksHL39xXN
  tTqkQYfUlgWcFEIm1K8qV+n4VrLGkW/D1He89IpXlTJAzPXOUp29NBCjgtKQ
  ErfIbfqDW+/DEXIhwNtPm9wYaF7TjBLMuFgbSBg4TGXjASIY0yViIYWfougn
  p5/xW0Jk9GteFnNjwAPvPO9At1msY4W40iRgLf9ILsBz7QY7d/cUvuqiyLvM
  wa4zd4GOvyN/u79/w/sgK8Ah8aSmrQwGLTKbCygqV3LV7ZM2K8ZWbfgNOOqC
  xI7QStcQ7FdMxLGcUzR6Y83+7Qk+PdACa1NHBwOdKn2gtMmVj3u34Xc+BeZ6
  Md/K31XM31OWLG6znJ1vv9DoXBL3XU3Nw2joY/cG13e9DHcr1s+7LrmDwSnv
  a+21jy7CEjLesR8QMQIM4Rt7z8FSszaQQkJZIICfsnqeUZl/sOtnZnrN60EH
  Zor3izqdpMseR3bQodxbhEGuonXKizbMYjkReLY3KKJI0RVvMLoji7WI53Gq
  CgzsN++bR+wFgUXgLlDzufs7SpdbuCvL/MkhrjOKIfamygR2nruejsuu7rLB
  jNPIa73s4+EbYB6W0uH9IM0y4tNMzYrPuYBkLAUhXtarT8swU32ldyfF1cXZ
  wZ4ChiKtgEBvgRQAYovYa0S2QmL1nswCUyGGfmAI9yAX9e6pvHuT3b8h6znR
  7AyYDwf3tvxKnM2nbvf+n/wmIe8WHwBPUt7IWaYdlH1dtUROnO6tLQFZEQ4C
  EzAiNNPcrOqHjA9DSiC0hRjf1yTp1Faz8RmLH3AipcaQ35u5xpA3iMZvq6zq
  YpeeIz9O1KY5G/VOj5lQN12Tj/zeAkQBlhWnYKCZNWanTAWBLaGl2FjQkVkG
  ri4KdXjozN8HRtmN78LDIHJp8v5ZeXlxsDcIv8+O4YlqIbTXuxSF3l+70Ls/
  98/twog/2RpRAxRir0nC0d1fL1wAHen/FbATszYbgfUZy7AyWz+AC58P4ueT
  m0ssAPaNXX1fDB3J3burbbFl+I0b26K671sDtzyM0F6X5UwJHmDhl3c3F5uR
  2E/ZLMuD4kTBkOmCoS3BVvcr79hNzAtCocj0+VWZrvl7Nhq2dBksc1JvBgbx
  20PsLGLnf6fZVph8m3G76g0Ue25bPgAVBUsf+KvqBoi0Y5gYVWyHIWMoAmcm
  n5lqvQWj/s/W5EwgDiHqTzC/v7olwE/xl4nA5BRb1j4AoyfcRzPEetHvdtmA
  YfK7goYo6/03Z0MY0G195EupV/mGp4sFOzYI7y5u70Taes4nPBXcRRENvGHD
  zy/ebbXRZ0Rknis9Y9pb/ZbAfaA8W5JK14iAM3h+nwbyv8aD2fDdnf8DIhqM
  yV1zAAA=
  
  -->
- </rfc>

<?xml version="1.0" encoding="US-ASCII"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>

<rfc category="info" submissionType="IAB" number="8477" consensus="yes" ipr="trust200902">

  <front>
    <title abbrev="IOTSI Workshop 2016">Report from the Internet of Things (IoT) Semantic&nbsp;Interoperability&nbsp;(IOTSI)&nbsp;Workshop&nbsp;2016</title>



<!--[rfced] *RJS or Stream Manager - please review and approve the
split of the boilerplate paragraph in the Intro.

As it appears at https://www.rfc-editor.org/materials/iab-format.txt:

  The following boilerplate paragraph SHOULD appear in the introduction: 

      The Internet Architecture Board (IAB) holds occasional workshops 
      designed to consider long-term issues and strategies for the 
      Internet, and to suggest future directions for the Internet 
      architecture.  This long-term planning function of the IAB is 
      complementary to the ongoing engineering efforts performed by working 
      groups of the Internet Engineering Task Force (IETF).

How it appears in this document:


   The Internet Architecture Board (IAB) holds occasional workshops
   designed to consider long-term issues and strategies for the
   Internet, and to suggest future directions for the Internet
   architecture.  The investigated topics often require coordinated
   efforts of many organizations and industry bodies to improve an
   identified problem.  One of the targets of the workshops is to
   establish communication between relevant organizations, especially
   when the topics are out of the scope for the Internet Engineering
   Task Force (IETF).  This long-term planning function of the IAB is
   complementary to the ongoing engineering efforts performed by working
   groups of the IETF.

-->

    <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
      <organization></organization>
      <address>
        <email>jaime.jimenez@ericsson.com</email>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization></organization>
      <address>
        <email>hannes.tschofenig@arm.com</email>
      </address>
    </author>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization></organization>
      <address>
        <email>dthaler@microsoft.com</email>
      </address>
    </author>

    <date year="2018" month="September"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>


       <abstract>

<t>This document provides a summary of the "Workshop on Internet of
Things (IoT) Semantic Interoperability (IOTSI)",
which took place in Santa Clara, California March 17-18, 2016.  The main
goal of the workshop was to foster a discussion on the different
approaches used by companies and Standards Developing Organizations (SDOs)
to accomplish interoperability at the application layer.  This report
summarizes the discussions and lists recommendations to the standards
community.  The views and positions in this report are those of the
workshop participants and do not necessarily reflect those of the
authors or the Internet Architecture Board (IAB), which organized
the workshop.
<!--begin DNE text -->
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.

<!--end DNE text -->
</t>

    </abstract>


  </front>

  <middle>


<section anchor="section-1" title="Introduction">

<!--Begin DNE text -->
<t>The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture.
<!--End DNE text -->
The investigated topics often require coordinated
efforts from many organizations and industry bodies to improve an
identified problem.  One of the targets of the workshops is to
establish communication between relevant organizations, especially
when the topics are out of the scope of the Internet Engineering
Task Force (IETF).
<!--Begin DNE text -->
This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the IETF.
<!--End DNE text -->
</t>

<t>With the expansion of the Internet of Things (IoT), interoperability
becomes more and more important. Standards Developing Organizations (SDOs)
have done a tremendous amount of work to standardize new protocols
and profile existing protocols.</t>

<t>At the application layer and at the level of solution frameworks, 
interoperability is not yet mature. Particularly, the
work on data formats (in the form of data models and information
models) has not seen the same level of consistency throughout
SDOs.</t>

<t>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 between data formats and the underlying communication architecture, 
such as a design in Remote 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 their standardized outcome, leading to interoperability
problems. Finally, some groups favor different encodings for use with
various application-layer protocols.</t>

<t>Thus, the IAB decided to organize a workshop to reach out to relevant
stakeholders to explore the state of the art and identify
commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
interested to learn about the following aspects:</t>

<t><list style="symbols">
  <t>What is the state of the art in data and information models? What should
an information model look like?</t>
  <t>What is the role of formal languages, such as schema languages, in
describing information and data models?</t>
  <t>What is the role of metadata, which is attached to data to make it self-describing?</t>
  <t>How can we achieve interoperability when different organizations, companies,
and individuals develop extensions?</t>
  <t>What is the experience with interworking various data models developed
from different groups, or with data models that evolved over time?</t>
  <t>What functionality should online repositories for sharing schemas have?</t>
  <t>How can existing data models be mapped against each other to offer interworking?</t>
  <t>Is there room for harmonization, or are the use cases of different groups
and organizations so unique that there is no possibility for cooperation?</t>
  <t>How can organizations better work together to increase awareness and information sharing?</t>
</list></t>

</section>
<section anchor="section-2" title="Terminology">

<t>The first roadblock to interoperability at the level of data models is the lack of a
common vocabulary to start the discussion.
<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
or "information models", from concrete detailed definitions for implementers, or
"data models". There are concepts that are
undefined in that RFC and elsewhere, such as the interaction with the
resources of an endpoint, or "interaction model".  Therefore, the three
"main" common models that were identified were:</t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Information Model'><vspace blankLines='0'/>
  An information model defines an environment at the highest level of abstraction and
expresses the desired functionality.
Information models can be defined informally (e.g., in prose) or more
formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.).
Implementation details are hidden.</t>
</list></t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Data Model'><vspace blankLines='0'/>
  

A data model defines concrete data representations at a lower level of
abstraction, including implementation- and protocol-specific details.
Some examples are SNMP Management Information Base (MIB) modules, World Wide
Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.</t>
</list></t>

<t><list style="hanging" hangIndent="3">
  <t hangText='Interaction Model'><vspace blankLines='0'/>
  An interaction model defines how data is accessed and retrieved from the endpoints,
being, therefore, tied to the specific
communication pattern that the system has (e.g., REST methods,
Publish/Subscribe operations, or RPC calls).</t>
</list></t>

<t>Another identified terminology issue is the semantic meaning overload
that some terms have.  The meaning can vary depending on the context in which the
term is used.  Some examples of such terms are as follows: semantics, models,
encoding, serialization format, media types, and encoding types.  Due
to time constraints, no concrete terminology was agreed upon, but
work will continue within each organization to create various
terminology documents.  The participants agreed to set up a GitHub repository
<xref target="IOTSIGIT"/> for sharing information.</t>

</section>
<section anchor="section-4" title="What Problems to Solve">

<t>The participants agreed that there is not simply a single problem to be solved but
rather a range of problems. During the workshop, the following problems were discussed:</t>

<t><list style="symbols">
  <t>Formal Languages for Documentation Purposes</t>
</list></t>

<t>To simplify review and publication, SDOs need
formal descriptions of their data and interaction models.
Several of them use a tabular 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.</t>

<t>The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema <xref
target="LWM2M-Schema"/> to describe their object and resource definitions. The
XML files of standardized objects are available for download at
<xref target="OMNA"/>.</t>

<t>The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with 
Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on 
the Bluetooth SIG website <xref target="SIG"/> and are defined as XML instance documents.</t>

<t>The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define
data models and RESTful API Modeling Language (RAML) to define interaction models.  The standard files are
available online at &lt;oneIoTa.org&gt;.</t>

<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
models in the same formal language, tailored for RPC-style interaction.  The standard
files are available online on the AllSeen Alliance website, but both standard and
vendor-defined model files can be obtained by directly querying a device for them at runtime.</t>

<t>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.</t>

<t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models.
Other SDOs may use various other formats.</t>

<t><list style="symbols">
  <t>Formal Languages for Code Generation</t>
</list></t>

<t>Code-generation tools that use formal data and information modeling languages
are needed by developers. For example, the AllSeen Visual Studio
Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
the formal description of the data model.  Another example of a 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 <xref target="PYANG"/>.
An example of a tool that can generate code for multiple ecosystems is
OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
development of server-side device functionality, clients, and compliance tests.</t>


<t><list style="symbols">
  <t>Debugging Support</t>
</list></t>

<t>Debugging tools are needed that implement generic object browsers, which
use standard data models and/or retrieve formal language descriptions
from the devices themselves. As one example, the
nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
used to display services and characteristics defined by the Bluetooth SIG.
As another example, AllJoyn Explorer <xref target="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.</t>

<t><list style="symbols">
  <t>Translation</t>
</list></t>

<t>The working assumption is that devices need to have a common data model 
with a priori knowledge of data types and actions. However, that would imply 
that each consortium/organization will try to define their own data
model. That would cause a major interoperability problem, possibly a completely
intractable one  given the number of variations, extensions, compositions, or
versioning changes that will happen for each data model.</t>


<t>Another potential approach is to have a minimal amount 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.</t>

<t>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.</t>

<t><list style="symbols">
  <t>Runtime Discovery</t>
</list></t>

<t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the
data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. 
An example of such an approach has been shown with Hypermedia as the Engine of
Application State (HATEOAS) <xref target="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 <xref target="AllSeen"/>.</t>

<t>There are various models, whether deployed or possible, for such discovery.
The metadata might be extracted from a specification, 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 (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 (a) syntax information, (b) end-user descriptions in 
a desired language, and (c) developer-specific comments for implementers.</t>

</section>
<section anchor="section-5" title="Translation">

<t>In an ideal world where organizations and companies cooperate and agree on a
single data model standard, there is no need for gateways that translate from one data model
to another one. However, this is far from reality today, and there are many
proprietary data models in addition to the already standardized ones. As a 
consequence, gateways are needed to translate between data models. This leads to 
(n^2)-n combinations, in the worst case.</t>

<t>There are analogies with gateways back in the 1980s that were used to
translate between network layer protocols.  Eventually, IP took over, providing
the necessary end-to-end interoperability at the network 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.</t>

<t>Participants discussed an alternative that they called a "red star", shown
in <xref target="red-star"/>, where data models are translated to a common
data model shown in the middle. This 
reduces the number of translations 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 star in the center.</t>

<figure title="The &quot;Red Star&quot; in Data/Information Models" anchor="red-star"><artwork><![CDATA[
   +-----+                                        +-----+
   |     |                                        |     |
   |     |  --                                 -- |     |
   |     |    --                             --   |     |
   +-----+      --                         --     +-----+
                  --                    ---
                    --                --
                      --            --
                        --        --
     ---                  -- A  --                  ---
    /   \                ___/ \___                 /   \
   |     | ---------------',   .'---------------  |     |
    \   /                 /. ^ .\                  \   /
     ---                 /'     '\                  ---   
                        --        --
                      --            --
                    --                --
                  --                    --
                --                        --
       /\     --                            --     /\
      /  \  --                                --  /  \
     /    \                                      /    \
    /      \                                    /      \
   /--------\                                  /--------\
]]></artwork></figure>

<t>While the workshop itself was not a suitable forum to discuss the design of 
such translation in detail, several questions were raised:</t>

<t><list style="symbols">
  <t>Do we need a "red star" that does everything, or could we design something that 
offers a more restricted functionality?</t>
  <t>How do we handle loss of data and functionality?</t>
  <t>Should data be translated between data models, or should data models themselves be translated?</t>
  <t>How can interaction models be translated? They need to be dealt with in addition 
 to the data models.</t>
  <t>Many (if not all) data and interaction models have some bizarre functionality 
 that cannot be translated easily. How can those be handled?</t>
  <t>What limitations are we going to accept in these translations?</t>
</list></t>

<!--[rfced] We recently received guidance from Benoit and the YANG
Doctors that "YANG module" and "YANG data model" are preferred.
We have updated the document accordingly.  Please review and let
us know if further changes are necessary.

-->
<t>The participants also addressed the question of when translation should be done.
Two use cases were discussed:
<list style="format (%c)">
<t>Design time: A translation between data model
descriptions, such as translating a YANG module 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.</t>

<t>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. This situation is discussed in <xref target="BridgeTaxonomy"/>.</t>
</list></t>
<t>The participants agreed that algorithm translation will generally require
custom code whenever one is translating to anything other than a derived model.</t>

<t>Participants concluded that it is typically easier to translate data between systems that
follow the same communication architecture.</t>

</section>
<section anchor="section-6" title="Dealing with Change">

<t>A large part of the workshop was dedicated to the evolution of
devices and server-side applications.
Interactions between devices and services and how their relationship
evolves over time is complicated by their respective interaction models.</t>

<t>The workshop participants discussed various approaches to deal with change.  In the most basic case, a
developer might use a description of an API and implement 
the protocol steps.  Sometimes, the data or information model can be used to generate code stubs.  Subsequent changes to an API
require changes on the clients to upgrade to the new version, which
requires some development of new code to satisfy the needs of the new
API.</t>

<t>These interactions could be made machine understandable in the first place,
enabling for changes to happen at runtime.
In that scenario, a machine client could discover the possible interactions with a
service, adapting to changes as they occur without specific code
being developed to adapt to them.</t>

<t>The challenge seems to be to code the human-readable specification into a machine-readable format.  Machine-readable languages require a shared vocabulary to
give meaning to the tags.</t>

<t>These types of interactions are often based on the REST architectural
style. Its principle is that a device or endpoint only needs a
single entry point, with a host providing descriptions of the API
in-band by means of web links and forms.</t>

<t>By defining IoT-specific relation types, it is possible to drive
interactions through links instead of hard-coding URIs into a RESTful
client, thus making the system flexible enough for later changes.
The definition of the basic hypermedia formats for IoT is still a work
in progress. However, some of the existing mechanisms can be reused,
such as resource discovery, forms, or links.</t>

</section>

<!--[rfced] FYI - we have added an IANA Considerations to match the
guidance in RFC 8126 stating that no IANA actions are necessary.
Please let us know any objections.  -->

<section title="IANA Considerations">
  <t>This document has no IANA actions.</t>
</section>

<section anchor="section-7" title="Security Considerations">

<t>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.</t>

<t>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, there are different types of security
principals (e.g., user vs. device vs. application), the use of Access Control Lists (ACLs) versus 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.</t>

<t>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 enables
the translator to translate between different data models.</t>

<t>One suggestion discussed was either adding metadata into the
formal data model language or having it accompany 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.</t>

</section>
<section anchor="section-8" title="Collaboration">

<t>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 other's 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 <xref target="IOTSIGIT"/>.</t>

<t>Another challenge reported was that organizations did not know how to find each other's
published data models, and sharing such information could better facilitate reuse of the
same information model.  To facilitate this exchange, the 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, as the restriction was not
the intent.  &lt;schema.org&gt; 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 <xref target="IOTSIGIT"/>.</t>

<t>It was also agreed that the iotsi@iab.org mailing list would remain open and available
for sharing information between all relevant organizations.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>

<?rfc include="reference.RFC.3444" ?>



<reference anchor="AllSeen-Plugin">
  <front>
    <title>Using the AllJoyn Studio Extension</title>
    <author initials="B." surname="Rockwell" fullname="B. Rockwell">
      <organization></organization>
    </author>
    <date year="2015" month="August" day="17"/>
  </front>
</reference>

<reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf">
  <front>
    <title>Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things</title>
    <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
      <organization></organization>
    </author>
    <author initials="Y.N." surname="Hassan">
      <organization></organization>
    </author>
    <author initials="K." surname="Hartke">
      <organization></organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Proceedings of the IAB IoT Semantic Interoperability Workshop" value="2016"/>
</reference>

<reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf">
  <front>
    <title>Summary of AllSeen Alliance Work Relevant to Semantic Interoperability</title>
    <author initials="D." surname="Thaler" fullname="D. Thaler">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf">
  <front>
    <title>IoT Bridge Taxonomy</title>
    <author initials="D." surname="Thaler" fullname="D. Thaler">
      <organization></organization>
    </author>
    <date />
  </front>
<seriesInfo name="IAB IOTSI Workshop" value="2016" />
</reference>

<reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/">
  <front>
    <title>IoT Semantic Interoperability Workshop Agenda</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<!--[rfced] Please review our updates to the [IOTSIGIT] and [PYANG]
reference entries in compliance with
https://www.rfc-editor.org/styleguide/part2/ and let us know any
objections. -->

<reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi">
  <front>
    <title>Starting place for the IoT Semantic Interoperability Workshop
    (IOTSI) Information Resource</title>
    <author >
      <organization></organization>
    </author>
    <date year="2018" month="July"/>
  </front>
<seriesInfo name='commit' value="ff21f74"/>
</reference>

<reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/">
  <front>
    <title>IoT Semantic Interoperability Workshop 2016</title>
    <author >
      <organization>IAB</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>

<reference anchor="LWM2M-Schema" >
  <front>
    <title>LWM2M XML Schema - LWM2M Editor Schema</title>
    <author >
      <organization>OMA</organization>
    </author>
    <date year="2018" month="July"/>
  </front>
</reference>

<reference anchor="OMNA">
  <front>
    <title>OMA LightweightM2M (LwM2M) Object and Resource Registry</title>
    <author >
      <organization>OMA</organization>
    </author>
    <date />
  </front>
</reference>

<reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt">
  <front>
    <title>GATT Specifications</title>
    <author >
      <organization>Bluetooth SIG</organization>
    </author>
    <date />
  </front>
</reference>

<reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
  <front>
    <title>An extensible YANG validator and converter in python</title>
    <author>
      <organization></organization>
    </author>
    <date year="2018" month="September" day="13"/>
  </front>
<seriesInfo name="commit" value="15c807f" />
</reference>

<reference anchor="nRF-Sniffer">
  <front>
    <title>nRF Sniffer: Smart/Bluetooth low energy packet sniffer</title>
    <author >
      <organization>Nordic Semiconductor</organization>
    </author>
    <date />
  </front>
</reference>

<reference anchor="AllJoynExplorer">
  <front>
    <title>AllJoyn</title>
    <author >
      <organization>Microsoft</organization>
    </author>
    <date />
  </front>
</reference>

<reference anchor="OpenDOF" target="https://opendof.org">
  <front>
    <title>The OpenDOF Project</title>
    <author >
      <organization>OpenDOF</organization>
    </author>
    <date />
  </front>
</reference>


</references>


<section title="Program Committee" >

<t>This workshop was organized by the following individuals: Jari Arkko,
Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
Tschofenig.</t>

</section>
<section title="Accepted Position Papers">

<!--[rfced] FYI, we standardized the capitalization of the paper
titles from the workshop. Please let us know if that creates any
problems.  -->

<t><list style="symbols">
  <t>Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"</t>
  <t>Carsten Bormann, "Noise in Specifications hurts"</t>
  <t>Benoit Claise, "YANG as the Data Modelling Language in the IoT space"</t>
  <t>Robert Cragie, "The ZigBee Cluster Library over IP"</t>
  <t>Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"</t>
  <t>Universal Devices, "Object Oriented Approach to IoT Interoperability"</t>
  <t>Bryant Eastham, "Interoperability and the OpenDOF Project"</t>
  <t>Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"</t>
  <t>Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"</t>
  <t>Ted Hardie, "Loci of Interoperability for the Internet of Things"</t>
  <t>Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"</t>
  <t>Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"</t>
  <t>David Jones, "IOTDB - interoperability Through Semantic Metastandards"</t>
  <t>Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"</t>
  <t>Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"</t>
  <t>Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"</t>
  <t>Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"</t>
  <t>Michael Koster, "Model-Based Hypertext Language"</t>
  <t>Matthias Kovatsch, Yassin N.  Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models"</t>
  <t>Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things"</t>
  <t>Barry Leiba, "Position Paper"</t>
  <t>Marcello Lioy, "AllJoyn"</t>
  <t>Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema"</t>
  <t>Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues"</t>
  <t>Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things"</t>
  <t>Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti"</t>
  <t>Joaquin Prado, "OMA Lightweight M2M Resource Model"</t>
  <t>Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop"</t>
  <t>Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"</t>
  <t>Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"</t>
  <t>Max Senges, "Submission for IAB IoT Sematic Interoperability workshop"</t>
  <t>Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"</t>
  <t>Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"</t>
  <t>Robert Sparks and Ben Campbell, "Considerations for certain IoT-based services"</t>
  <t>J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"</t>
  <t>J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems"</t>
  <t>Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"</t>
  <t>Andrew Sullivan, "Position paper for IOTSI workshop"</t>
  <t>Darshak Thakore, "IoT Security in the context of Semantic Interoperability"</t>
  <t>Dave Thaler, "IoT Bridge Taxonomy"</t>
  <t>Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"</t>
  <t>Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike
  Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"</t>
  <t>Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"</t>
</list></t>

</section>

<section title="List of Participants">
<?rfc subcompact="yes"?>
<t><list>
  <t>Andy Bierman, YumaWorks</t>
  <t>Carsten Bormann, Uni Bremen/TZI</t>
  <t>Ben Campbell, Oracle</t>
  <t>Benoit Claise, Cisco</t>
  <t>Alissa Cooper, Cisco</t>
  <t>Robert Cragie, ARM Limited</t>
  <t>Laura Daniele, TNO</t>
  <t>Bryant Eastham, OpenDOF</t>
  <t>Christian Groves, Huawei</t>
  <t>Ted Hardie, Google</t>
  <t>Yonggeun Hong, ETRI</t>
  <t>Russ Housley, Vigil Security</t>
  <t>David Janes, IOTDB</t>
  <t>Jaime Jimenez, Ericsson</t>
  <t>Shailendra Karody, Catalina Labs</t>
  <t>Ari Keraenen, Ericsson</t>
  <t>Michael Koster, SmartThings</t>
  <t>Matthias Kovatsch, Siemens</t>
  <t>Kai Kreuzer, Deutsche Telekom</t>
  <t>Barry Leiba, Huawei</t>
  <t>Steve Liang, Uni Calgary</t>
  <t>Marcello Lioy, Qualcomm</t>
  <t>Kerry Lynn, Verizon</t>
  <t>Mayan Mathen, Catalina Labs</t>
  <t>Erik Nordmark, Arista</t>
  <t>Jean Paoli, Microsoft</t>
  <t>Joaquin Prado, OMA</t>
  <t>Dave Raggett, W3C</t>
  <t>Max Senges, Google</t>
  <t>Ned Smith, Intel</t>
  <t>Robert Sparks, Oracle</t>
  <t>Ram Sriram, NIST</t>
  <t>Clarke Stevens</t>
  <t>Ram Subramanian, Intel</t>
  <t>Andrew Sullivan, DIN</t>
  <t>Darshak Thakore, CableLabs</t>
  <t>Dave Thaler, Microsoft</t>
  <t>Hannes Tschofenig, ARM Limited</t>
  <t>Michael Verschoor, Philips Lighting</t>
</list></t>
<?rfc subcompact="no"?>

</section>

<section title="IAB Members at the Time of Approval" numbered="no">
<?rfc subcompact="yes"?>
  <t><list>
  <t>Jari Arkko</t>
  <t>Alissa Cooper</t>
  <t>Ted Hardie</t>
  <t>Christian Huitema</t>
  <t>Gabriel Montenegro</t>
  <t>Erik Nordmark</t>
  <t>Mark Nottingham</t>
  <t>Melinda Shore</t>
  <t>Robert Sparks</t>
  <t>Jeff Tantsura</t>
  <t>Martin Thomson</t>
  <t>Brian Trammell</t>
  <t>Suzanne Woolf</t>
  </list></t>
<?rfc subcompact="no"?>
  </section>

<section title="Acknowledgements" numbered="no">

<t>We would like to thank all paper authors and participants for their
contributions and Ericsson for hosting the workshop.</t>

</section>


  </back>


</rfc>

<?xml version='1.0' encoding='UTF-8'?>

<reference  anchor='RFC3444' target='https://www.rfc-editor.org/info/rfc3444'>
<front>
<title>On the Difference between Information Models and Data Models</title>
<author initials='A.' surname='Pras' fullname='A. Pras'><organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author>
<date year='2003' month='January' />
<abstract><t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management.  This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3444'/>
<seriesInfo name='DOI' value='10.17487/RFC3444'/>
</reference>