<!-- [rfced] Please insert any keywords (beyond those that appear in
42
the title) for use on https://www.rfc-editor.org/search.
43
-->
44
45
<keyword>example</keyword>
46
47
48
<abstract>
49
50
<t>This document provides a summary of the "Workshop on Internet of
51
Things (IoT) Semantic Interoperability (IOTSI)",
52
which took place in Santa Clara, California March 17-18, 2016. The main
53
goal of the workshop was to foster a discussion on the different
54
approaches used by companies and Standards Developing Organizations (SDOs)
55
to accomplish interoperability at the application layer. This report
56
summarizes the discussions and lists recommendations to the standards
57
community. The views and positions in this report are those of the
58
workshop participants and do not necessarily reflect those of the
59
authors or the Internet Architecture Board (IAB), which organized
60
the workshop.</t>
61
62
</abstract>
63
64
65
</front>
66
67
<middle>
68
69
70
<section anchor="section-1" title="Introduction">
71
72
<t>The Internet Architecture Board (IAB) holds occasional workshops
73
designed to consider long-term issues and strategies for the
74
Internet, and to suggest future directions for the Internet
75
architecture. The investigated topics often require coordinated
76
efforts from many organizations and industry bodies to improve an
77
identified problem. One of the targets of the workshops is to
78
establish communication between relevant organizations, especially
79
when the topics are out of the scope of the Internet Engineering
80
Task Force (IETF). This long-term planning function of the IAB is
81
complementary to the ongoing engineering efforts performed by working
82
groups of the IETF.</t>
83
84
<t>With the expansion of the Internet of Things (IoT), interoperability
85
becomes more and more important. Standards Developing Organizations (SDOs)
86
have done a tremendous amount of work to standardize new protocols
87
and profile existing protocols.</t>
88
89
<t>At the application layer and at the level of solution frameworks,
90
interoperability is not yet mature. Particularly, the
91
work on data formats (in the form of data models and information
92
models) has not seen the same level of consistency throughout
93
SDOs.</t>
94
95
<!--[rfced] We're having trouble interpreting the following passage. What is
96
it that has a "strong relationship with the underlying communication architecture"?
97
98
ORIGINAL:
99
One common problem is the lack of an encoding-independent
100
standardization of the information, the so-called information model.
101
Another problem is the strong relationship with the underlying
102
communication architecture, such as a design in Remote Procedure Call
103
(RPC) style or a RESTful design.
104
-->
105
<t>One common problem is the lack of an encoding-independent standardization
106
of the information, the so-called information model. Another problem is
107
the strong relationship with the underlying communication architecture,
108
such as a design in Remote Procedure Call (RPC) style 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
109
problems. Finally, some groups favor different encodings for use with
110
various application-layer protocols.</t>
111
112
<t>Thus, the IAB decided to organize a workshop to reach out to relevant
113
stakeholders to explore the state of the art and identify
114
commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
115
interested to learn about the following aspects:</t>
116
117
<t><list style="symbols">
118
<t>What is the state of the art in data and information models? What should
119
an information model look like?</t>
120
<t>What is the role of formal languages, such as schema languages, in
121
describing information and data models?</t>
122
<t>What is the role of metadata, which is attached to data to make it self-describing?</t>
123
<t>How can we achieve interoperability when different organizations, companies,
124
and individuals develop extensions?</t>
125
<t>What is the experience with interworking various data models developed
126
from different groups, or with data models that evolved over time?</t>
127
<t>What functionality should online repositories for sharing schemas have?</t>
128
<t>How can existing data models be mapped against each other to offer interworking?</t>
129
<t>Is there room for harmonization, or are the use cases of different groups
130
and organizations so unique that there is no possibility for cooperation?</t>
131
<t>How can organizations better work together to increase awareness and information sharing?</t>
132
</list></t>
133
134
</section>
135
<section anchor="section-2" title="Terminology">
136
137
<t>The first roadblock to interoperability at the level of data models is the lack of a
138
common vocabulary to start the discussion.
139
<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
140
or "information models", from concrete detailed definitions for implementers, or
141
"data models". There are concepts that are
142
undefined in that RFC and elsewhere, such as the interaction with the
143
resources of an endpoint, or "interaction model". Therefore the three
144
"main" common models that were identified were:</t>
An interaction model defines how data is accessed and retrieved from the endpoints,
178
being therefore tied to the specific
179
communication pattern that the system has (e.g., REST methods,
180
Publish/Subscribe operations, or RPC calls).</t>
181
</list></t>
182
183
<t>Another identified terminology issue is the semantic meaning overload
184
that some terms have. The meaning can vary depending on the context in which the
185
term is used. Some examples of such terms are: semantics, models,
186
encoding, serialization format, media types, and encoding types. Due
187
to time constraints, no concrete terminology was agreed upon, but
188
work will continue within each organization to create various
189
terminology documents. The participants agreed to set up a GitHub repository
190
<xref target="IOTSIGIT"/> for sharing information.</t>
191
192
</section>
193
<section anchor="section-4" title="What Problems to Solve">
194
195
<t>The participants agreed that there is not simply a single problem to be solved but
196
rather a range. During the workshop, the following problems were discussed:</t>
197
198
<t><list style="symbols">
199
<t>Formal Languages for Documentation Purposes</t>
200
</list></t>
201
202
<t>To simplify review and publication, SDOs need
203
formal descriptions of their data and interaction models.
204
Several of them use a tabular representation found in the specification itself
205
but use a formal language as an alternative way of describing objects and resources
206
for formal purposes. Some examples of formal language use are as follows.</t>
207
208
<t>The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema <xref
209
target="LWM2M-Schema"/> to describe their object and resource definitions. The
210
XML files of standardized objects are available for download at
211
<xref target="OMNA"/>.</t>
212
213
<t>The Bluetooth Special Interest Group (SIG) defined Generic Attributes (GATT) services and characteristics for use with
214
Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on
215
the Bluetooth SIG website <xref target="SIG"/> and also defined as XML instance documents.</t>
216
217
<!--[rfced] How should the acronym RAML be expanded?
218
219
Original:
220
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally
221
define data models and RAML to define interaction models.
222
-->
223
<t>The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define
224
data models and RAML to define interaction models. The standard files are
225
available online at oneIoTa.org.</t>
226
227
<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
228
models in the same formal language, tailored for RPC-style interaction. The standard
229
files are available online on the AllSeen Alliance web site, but both standard and
230
vendor-defined model files can be obtained by directly querying a device for them at runtime.</t>
231
232
<t>The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF)
233
to define data and interaction models using a format tailored for the web.</t>
234
235
<t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models.
236
Other SDOs may use various other formats.</t>
237
238
<t><list style="symbols">
239
<t>Formal Languages for Code Generation</t>
240
</list></t>
241
242
<t>Code-generation tools that use formal data and information modeling languages
243
are needed by developers. For example, the AllSeen Visual Studio
244
Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
245
the formal description of the data model. Another example of a data
246
modeling language that can be used for code generation is YANG. A
247
popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>.
248
An example of a tool that can generate code for multiple ecosystems is
249
OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
250
development of server-side device functionality, clients, and compliance tests.</t>
251
252
<t><list style="symbols">
253
<t>Debugging Support</t>
254
</list></t>
255
256
<t>Debugging tools are needed that implement generic object browsers, which
257
use standard data models and/or retrieve formal language descriptions
258
from the devices themselves. As one example, the
259
nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
260
used to display services and characteristics defined by the Bluetooth SIG.
261
As another example, AllJoyn Explorer <xref target="AllJoynExplorer"/> can be used to browse
262
and interact with any resource exposed by an AllJoyn device, including both
263
standard and vendor-defined data models, by retrieving the formal descriptions
264
from the device at runtime.</t>
265
266
<t><list style="symbols">
267
<t>Translation</t>
268
</list></t>
269
270
<t>The working assumption is that devices need to have a common data model
271
with a priori knowledge of data types and actions. However, that would imply
272
that each consortium/organization will try to define their own data
273
model. That would cause a major interoperability problem, possibly a completely
274
intractable one given the number of variations, extensions, compositions, or
275
versioning changes that will happen for each data model.</t>
276
277
<t>Another potential approach is to have a minimal amount of information on the
278
device to allow for a runtime binding to a specific model, the objective being
279
to require as little prior knowledge as possible.</t>
280
281
<t>Moreover, gateways, bridges and other similar devices need to dynamically
282
translate (or map) one data model to another one. Complexity will increase
283
as there are also multiple protocols and schemas that make interoperability
284
harder to achieve.</t>
285
286
<t><list style="symbols">
287
<t>Runtime Discovery</t>
288
</list></t>
289
290
<t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the
291
data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well.
292
An example of such an approach has been shown with Hypermedia as the Engine of
293
Application State (HATEOAS) <xref target="HATEOAS"/>.
294
Another example is that all AllJoyn devices support such runtime discovery
295
using a protocol mechanism called "introspection", where the metadata is
296
queried from the device itself <xref target="AllSeen"/>.</t>
297
298
<t>There are various models, whether deployed or possible, for such discovery.
299
The metadata might be extracted from a specification, looked up on a
300
cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's
301
site, or obtained from the device itself (such as in the AllJoyn case). The
302
relevant metadata might be obtained from the same place, or different
303
pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in
304
a desired language, and (c) developer-specific comments for implementers.</t>
305
306
</section>
307
<section anchor="section-5" title="Translation">
308
309
<t>In an ideal world where organizations and companies cooperate and agree on a
310
single data model standard, there is no need for gateways that translate from one data model
311
<!--[rfced] It might be worth clarfying what "n" stands for in the following
312
passage.
313
314
ORIGINAL:
315
However, this is far from reality today, and there are many proprietary data models
316
in addition to the already standardized ones. As a consequence,
317
gateways are needed to translate between data models. This leads to
318
(n^2)-n combinations, in the worst case.
319
320
PERHAPS:
321
However, this is far from reality today, and there are many proprietary data models
322
in addition to the already standardized ones. As a consequence,
323
gateways are needed to translate between data models. For n data models, this
324
leads to gateways for each of (n^2)-n combinations, in the worst case.
325
-->
326
to the other one. However, this is far from reality today, and there are many
327
proprietary data models in addition to the already standardized ones. As a
328
consequence, gateways are needed to translate between data models. This leads to
329
(n^2)-n combinations, in the worst case.</t>
330
331
<t>There are analogies with gateways back in the 1980s that were used to
332
translate between network layer protocols. Eventually, IP took over, providing
333
the necessary end-to-end interoperability at the network layer. Unfortunately,
334
the introduction of gateways leads to the loss of expressiveness
335
due to the translation between data models. The functionality of IP was so
336
valuable in the market that advanced features of other networking
337
protocols became less attractive and were not used anymore.</t>
338
339
<t>Participants discussed an alternative that they called a "red star", shown
340
in <xref target="red-star"/>, where data models are translated to a common
341
data model shown in the middle. This
342
reduces the number of translations that are needed down to 2n (in the best case).
343
The problem, of course, is that everyone wants their own data model to be the red star in the center.</t>
344
345
<figure title="The "Red Star" in Data/Information Models." anchor="red-star"><artwork><![CDATA[
346
+-----+ +-----+
347
| | | |
348
| | -- -- | |
349
| | -- -- | |
350
+-----+ -- -- +-----+
351
-- ---
352
-- --
353
-- --
354
-- --
355
--- -- A -- ---
356
/ \ ___/ \___ / \
357
| | ---------------', .'--------------- | |
358
\ / /. ^ .\ \ /
359
--- /' '\ ---
360
-- --
361
-- --
362
-- --
363
-- --
364
-- --
365
/\ -- -- /\
366
/ \ -- -- / \
367
/ \ / \
368
/ \ / \
369
/--------\ /--------\
370
]]></artwork></figure>
371
372
<t>While the workshop itself was not a suitable forum to discuss the design of
373
such translation in detail, several questions were raised:</t>
374
375
<t><list style="symbols">
376
<t>Do we need a "red star" that does everything, or could we design something that
377
offers a more restricted functionality?</t>
378
<t>How do we handle loss of data and loss of functionality?</t>
379
<t>Should data be translated between data models, or should data models themselves be translated?</t>
380
<t>How can interaction models be translated? They need to be dealt with in addition
381
to the data models.</t>
382
<t>Many (if not all) data and interaction models have some bizarre functionality
383
that cannot be translated easily. How can those be handled?</t>
384
<t>What limitations are we going to accept in these translations?</t>
385
</list></t>
386
387
<t>The participants also addressed the question of when translation should be done.
388
Two use cases were discussed:</t>
389
390
<t>a) Design time: A translation between data model
391
descriptions, such as translating a YANG model to an RAML/JSON model,
392
can be performed once, during design time.
393
A single information model might be mapped to a number of different data models.</t>
394
395
<t>b) Run time: Runtime translation of values in two standard data models can only be
396
algorithmically done when the data model on one side is algorithmically derived
397
from the data model on the other side. This was called a "derived model".
398
It was discussed that the availability of runtime discovery can aid in
399
semantic translation, such as when a vendor-specific data model on one
400
side of a protocol bridge is resolved and the translator can algorithmically
401
derive the semantically equivalent vendor-specific data model on the other
402
side. This situation is discussed in <xref target="BridgeTaxonomy"/>.</t>
403
404
<t>The participants agreed that algorithm translation will generally require
405
custom code whenever one is translating to anything other than a derived model.</t>
406
407
<t>Participants concluded that it is typically easier to translate data between systems that
408
follow the same communication architecture.</t>
409
410
</section>
411
<section anchor="section-6" title="Dealing with Change">
412
413
<t>A large part of the workshop was dedicated to the evolution of
414
devices and server-side applications.
415
Interactions between devices and services and how their relationship
416
evolves over time is complicated by their respective interaction models.</t>
417
418
<t>The workshop participants discussed various approaches to deal with change. In the most basic case, a
419
developer might use a description of an API and implement
420
the protocol steps. Sometimes, the data or information model can be used to generate code stubs. Subsequent changes to an API
421
require changes on the clients to upgrade to the new version, which
422
requires some development of new code to satisfy the needs of the new
423
API.</t>
424
425
<t>These interactions could be made machine understandable in the first place,
426
enabling for changes to happen at runtime.
427
In that scenario, a machine client could discover the possible interactions with a
428
service, adapting to changes as they occur without specific code
429
being developed to adapt to them.</t>
430
431
<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
432
give meaning to the tags.</t>
433
434
<t>These types of interactions are often based on the REST architectural
435
style. Its principle is that a device or endpoint only needs a
436
single entry point, with a host providing descriptions of the API
437
in-band by means of web links and forms.</t>
438
439
<t>By defining IoT-specific relation types, it is possible to drive
440
interactions through links instead of hard-coding URIs into a RESTful
441
client, thus making the system flexible enough for later changes.
442
The definition of the basic hypermedia formats for IoT is still a work
443
in progress. However, some of the existing mechanisms can be reused,
<t>The participants discussed how best to share information among their various organizations.
474
One discussion was around having joint meetings. One current challenge reported was that
475
organizations were not aware of when and where each others' meetings were scheduled,
476
and sharing such information could help organizations better collocate meetings.
477
To facilitate this exchange, the participants agreed to add links to their respective
478
meeting schedules from a common page in the IOTSI repository <xref target="IOTSIGIT"/>.</t>
479
480
<t>Another challenge reported was that organizations did not know how to find each others'
481
published data models, and sharing such information could better facilitate reuse of the
482
same information model. To facilitate this exchange, the participants discussed whether
483
a common repository might be used by multiple organizations. The OCF's oneIoTa repository
484
was discussed as one possibility, but it was reported that its terms of use at the time
485
of the workshop prevented this. The OCF agreed to take this back and look at updating
486
the terms of use to allow other organizations to use it too, as the restriction was not
487
the intent. Schema.org was discussed as another possibility. In the meantime, the
488
participants agreed to add links to their respective repositories from a common page in
489
the IOTSI repository <xref target="IOTSIGIT"/>.</t>
490
491
<t>It was also agreed that the iotsi@iab.org mailing list would remain open and available
492
for sharing information between all relevant organizations.</t>
493
494
</section>
495
496
<section anchor="section-10" title="Appendix A: Program Committee">
497
498
<t>This workshop was organized by the following individuals: Jari Arkko,
499
Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
500
Tschofenig.</t>
501
502
</section>
503
<section anchor="section-11" title="Appendix B: Accepted Position Papers">
504
505
<!--[rfced] FYI, we standardized the capitalization of the paper
506
titles from the workshop. Please let us know if that creates any problems. -->
507
508
<t><list style="symbols">
509
<t>Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"</t>
510
<t>Carsten Bormann, "Noise in Specifications Hurts"</t>
511
<t>Benoit Claise, "YANG as the Data Modelling Language in the IoT Space"</t>
512
<t>Robert Cragie, "The ZigBee Cluster Library over IP"</t>
513
<t>Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: Interoperable IoT Services for Major Building Automation and Lighting Control Ecosystems"</t>
514
<t>Universal Devices, "Object Oriented Approach to IoT Interoperability"</t>
515
<t>Bryant Eastham, "Interoperability and the OpenDOF Project"</t>
516
<t>Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"</t>
517
<t>Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"</t>
518
<t>Ted Hardie, "Loci of Interoperability for the Internet of Things"</t>
519
<t>Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"</t>
520
<t>Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"</t>
521
<t>David Jones, "IOTDB - Interoperability Through Semantic Metastandards"</t>
522
<t>Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"</t>
523
<t>Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"</t>
524
<t>Ari Keraenen and Cullen Jennings, "SenML: Simple Building Block for IoT Semantic Interoperability"</t>
525
<t>Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"</t>
<t>Dave Raggett and Soumya Kanti Datta, "Input Paper for IAB Semantic Interoperability Workshop"</t>
537
<t>Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"</t>
538
<t>Jasper Roes and Laura Daniele, "Towards Semantic Interoperability in the IoT Using the Smart Appliances REFerence Ontology (SAREF) and Its Extensions"</t>
539
<t>Max Senges, "Submission for IAB IoT Sematic Interoperability Workshop"</t>
540
<t>Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"</t>
541
<t>Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"</t>
542
<t>Robert Sparks and Ben Campbell, "Considerations for Certain IoT-Based Services"</t>
543
<t>J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"</t>
544
<t>J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability between IoT Ecosystems"</t>
545
<t>Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - Formerly Open Interconnect Consortium (OIC)"</t>
546
<t>Andrew Sullivan, "Position Paper for IOTSI Workshop"</t>
547
<t>Darshak Thakore, "IoT Security in the Context of Semantic Interoperability"</t>
548
<t>Dave Thaler, "IoT Bridge Taxonomy"</t>
549
<t>Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"</t>
550
<t>Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike
551
Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"</t>
552
<t>Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"</t>
553
</list></t>
554
555
</section>
556
<section anchor="section-12" title="Appendix C: List of Participants">
557
558
<t><list style="symbols">
559
<t>Andy Bierman, YumaWorks</t>
560
<t>Carsten Bormann, Uni Bremen/TZI</t>
561
<t>Ben Campbell, Oracle</t>
562
<t>Benoit Claise, Cisco</t>
563
<t>Alissa Cooper, Cisco</t>
564
<t>Robert Cragie, ARM Limited</t>
565
<t>Laura Daniele, TNO</t>
566
<t>Bryant Eastham, OpenDOF</t>
567
<t>Christian Groves, Huawei</t>
568
<t>Ted Hardie, Google</t>
569
<t>Yonggeun Hong, ETRI</t>
570
<t>Russ Housley, Vigil Security</t>
571
<t>David Janes, IOTDB</t>
572
<t>Jaime Jimenez, Ericsson</t>
573
<t>Shailendra Karody, Catalina Labs</t>
574
<t>Ari Keraenen, Ericsson</t>
575
<t>Michael Koster, SmartThings</t>
576
<t>Matthias Kovatsch, Siemens</t>
577
<t>Kai Kreuzer, Deutsche Telekom</t>
578
<t>Barry Leiba, Huawei</t>
579
<t>Steve Liang, Uni Calgary</t>
580
<t>Marcello Lioy, Qualcomm</t>
581
<t>Kerry Lynn, Verizon</t>
582
<t>Mayan Mathen, Catalina Labs</t>
583
<t>Erik Nordmark, Arista</t>
584
<t>Jean Paoli, Microsoft</t>
585
<t>Joaquin Prado, OMA</t>
586
<t>Dave Raggett, W3C</t>
587
<t>Max Senges, Google</t>
588
<t>Ned Smith, Intel</t>
589
<t>Robert Sparks, Oracle</t>
590
<t>Ram Sriram, NIST</t>
591
<t>Clarke Stevens</t>
592
<t>Ram Subramanian, Intel</t>
593
<t>Andrew Sullivan, DIN</t>
594
<t>Darshak Thakore, CableLabs</t>
595
<t>Dave Thaler, Microsoft</t>
596
<t>Hannes Tschofenig, ARM Limited</t>
597
<t>Michael Verschoor, Philips Lighting</t>
598
</list></t>
599
600
</section>
601
602
603
</middle>
604
605
<back>
606
607
<!--[rfced] FYI, when the references don't seem to refer to a specific
608
version, we removed the year. Please let us know if that's a problem. -->
<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>
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.
<--[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. -->
Report from the Internet of Things (IoT) SemanticInteroperability(IOTSI)Workshop2016
</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.
<-- [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.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 -->
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>
<--[rfced] We're having trouble interpreting the following passage. What is
it that has a "strong relationship with the underlying communication architecture"?
ORIGINAL:
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 design in Remote Procedure Call
(RPC) style or a RESTful design.
-->
<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 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 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" 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, 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?
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", 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 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) prose) or more <-- [rfced] How should the acronym UML be expanded? As "Unified Modeling Language"?-->
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"/> <-- [rfced] How should the acronym LwM2M be expanded? As "Lightweight Machine-to-Machine"?-->
A data model defines concrete data representations at a lower level of abstraction, including implementation- and protocol-specific details. Some examples are: are SNMP Management Information Base (MIB) modules, World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine models, LwM2M
<--[rfced] How may we expand the acronym OCF below?
Original:
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.
-->
(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, 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" 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 but rather a range. 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" 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 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 <xref target="SIG" format="default" pageno="false"/> and also are defined as XML instance documents.
</t>
<--[rfced] How should the acronym RAML be expanded?
Original:
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally
define data models and RAML to define interaction models.
-->
<t>
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data 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 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" format="default" pageno="false"/> 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" format="default" pageno="false"/>. An example of a tool that can generate code 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 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, 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" format="default" pageno="false"/>. 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" 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, 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, 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.
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 <--[rfced] It might be worth clarfying what "n" stands for in the following
passage.
ORIGINAL:
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.
PERHAPS:
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. For n data models, this
leads to gateways for each of (n^2)-n combinations, in the worst case.
-->
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, 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" 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.
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 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 translation between data model descriptions, such as translating a YANG model module to an 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. 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 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" 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 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. -->
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", 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) 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 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.
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, 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 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-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 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 and Protocols Come and Go, Data Is Forever"
</t>
<t>
Carsten Bormann, "Noise in Specifications Hurts" hurts"
</t>
<t>
Benoit Claise, "YANG as the Data Modelling Language in the IoT Space" space"
</t>
<t>
Robert Cragie, "The ZigBee Cluster Library over IP"
</t>
<t>
Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: Interoperable interoperable IoT Services services for Major major Building Automation and Lighting Control Ecosystems" 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 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 simple building block for IoT Semantic Interoperability" 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 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" security issues"
</t>
<t>
Open Geospatial Consortium, "OGC SensorThings API: Communicating 'Where' "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"
Dave Raggett and Soumya Kanti Datta, "Input Paper 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 semantic interoperability in the IoT Using using the Smart Appliances REFerence Ontology ontology (SAREF) and Its Extensions" its extensions"
</t>
<t>
Max Senges, "Submission for IAB IoT Sematic Interoperability Workshop" 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" 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 Between IoT Ecosystems"
</t>
<t>
Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - Formerly formerly Open Interconnect Consortium (OIC)"
</t>
<t>
Andrew Sullivan, "Position Paper paper for IOTSI Workshop" workshop"
</t>
<t>
Darshak Thakore, "IoT Security in the Context 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 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>
<--[rfced] FYI, when the references don't seem to refer to a specific
version, we removed the year. Please let us know if that's a problem. -->
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. Suzanne Woolf
<title abbrev="IOTSI Workshop 2016">Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016</title>
19
20
21
22
<!--[rfced] *RJS or Stream Manager - please review and approve the
23
split of the boilerplate paragraph in the Intro.
24
25
As it appears at https://www.rfc-editor.org/materials/iab-format.txt:
26
27
The following boilerplate paragraph SHOULD appear in the introduction:
28
29
The Internet Architecture Board (IAB) holds occasional workshops
30
designed to consider long-term issues and strategies for the
31
Internet, and to suggest future directions for the Internet
32
architecture. This long-term planning function of the IAB is
33
complementary to the ongoing engineering efforts performed by working
34
groups of the Internet Engineering Task Force (IETF).
35
36
How it appears in this document:
37
38
39
The Internet Architecture Board (IAB) holds occasional workshops
40
designed to consider long-term issues and strategies for the
41
Internet, and to suggest future directions for the Internet
42
architecture. The investigated topics often require coordinated
43
efforts of many organizations and industry bodies to improve an
44
identified problem. One of the targets of the workshops is to
45
establish communication between relevant organizations, especially
46
when the topics are out of the scope for the Internet Engineering
47
Task Force (IETF). This long-term planning function of the IAB is
48
complementary to the ongoing engineering efforts performed by working
<!-- [rfced] Please insert any keywords (beyond those that appear in
75
the title) for use on https://www.rfc-editor.org/search.
76
-->
77
78
<keyword>example</keyword>
79
80
81
<abstract>
82
83
<t>This document provides a summary of the "Workshop on Internet of
84
Things (IoT) Semantic Interoperability (IOTSI)",
85
which took place in Santa Clara, California March 17-18, 2016. The main
86
goal of the workshop was to foster a discussion on the different
87
approaches used by companies and Standards Developing Organizations (SDOs)
88
to accomplish interoperability at the application layer. This report
89
summarizes the discussions and lists recommendations to the standards
90
community. The views and positions in this report are those of the
91
workshop participants and do not necessarily reflect those of the
92
authors or the Internet Architecture Board (IAB), which organized
93
the workshop.
94
<!--begin DNE text -->
95
Note that this document is a report on the proceedings of the
96
workshop. The views and positions documented in this report are
97
those of the workshop participants and do not necessarily reflect IAB
98
views and positions.
99
100
<!--end DNE text -->
101
</t>
102
103
</abstract>
104
105
106
</front>
107
108
<middle>
109
110
111
<section anchor="section-1" title="Introduction">
112
113
<!--Begin DNE text -->
114
<t>The Internet Architecture Board (IAB) holds occasional workshops
115
designed to consider long-term issues and strategies for the
116
Internet, and to suggest future directions for the Internet
117
architecture.
118
<!--End DNE text -->
119
The investigated topics often require coordinated
120
efforts from many organizations and industry bodies to improve an
121
identified problem. One of the targets of the workshops is to
122
establish communication between relevant organizations, especially
123
when the topics are out of the scope of the Internet Engineering
124
Task Force (IETF).
125
<!--Begin DNE text -->
126
This long-term planning function of the IAB is
127
complementary to the ongoing engineering efforts performed by working
128
groups of the IETF.
129
<!--End DNE text -->
130
</t>
131
132
<t>With the expansion of the Internet of Things (IoT), interoperability
133
becomes more and more important. Standards Developing Organizations (SDOs)
134
have done a tremendous amount of work to standardize new protocols
135
and profile existing protocols.</t>
136
137
<t>At the application layer and at the level of solution frameworks,
138
interoperability is not yet mature. Particularly, the
139
work on data formats (in the form of data models and information
140
models) has not seen the same level of consistency throughout
141
SDOs.</t>
142
143
<t>One common problem is the lack of an encoding-independent standardization
144
of the information, the so-called information model. Another problem is
145
the strong relationship between data formats and the underlying communication architecture,
146
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
147
problems. Finally, some groups favor different encodings for use with
148
various application-layer protocols.</t>
149
150
<t>Thus, the IAB decided to organize a workshop to reach out to relevant
151
stakeholders to explore the state of the art and identify
152
commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
153
interested to learn about the following aspects:</t>
154
155
<t><list style="symbols">
156
<t>What is the state of the art in data and information models? What should
157
an information model look like?</t>
158
<t>What is the role of formal languages, such as schema languages, in
159
describing information and data models?</t>
160
<t>What is the role of metadata, which is attached to data to make it self-describing?</t>
161
<t>How can we achieve interoperability when different organizations, companies,
162
and individuals develop extensions?</t>
163
<t>What is the experience with interworking various data models developed
164
from different groups, or with data models that evolved over time?</t>
165
<t>What functionality should online repositories for sharing schemas have?</t>
166
<t>How can existing data models be mapped against each other to offer interworking?</t>
167
<t>Is there room for harmonization, or are the use cases of different groups
168
and organizations so unique that there is no possibility for cooperation?</t>
169
<t>How can organizations better work together to increase awareness and information sharing?</t>
170
</list></t>
171
172
</section>
173
<section anchor="section-2" title="Terminology">
174
175
<t>The first roadblock to interoperability at the level of data models is the lack of a
176
common vocabulary to start the discussion.
177
<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
178
or "information models", from concrete detailed definitions for implementers, or
179
"data models". There are concepts that are
180
undefined in that RFC and elsewhere, such as the interaction with the
181
resources of an endpoint, or "interaction model". Therefore, the three
182
"main" common models that were identified were:</t>
An information model defines an environment at the highest level of abstraction and
187
expresses the desired functionality.
188
Information models can be defined informally (e.g., in prose) or more
189
formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.).
190
Implementation details are hidden.</t>
191
</list></t>
192
193
<t><list style="hanging" hangIndent="3">
194
<t hangText='Data Model'><vspace blankLines='0'/>
195
196
197
A data model defines concrete data representations at a lower level of
198
abstraction, including implementation- and protocol-specific details.
199
Some examples are SNMP Management Information Base (MIB) modules, World Wide
200
Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.</t>
An interaction model defines how data is accessed and retrieved from the endpoints,
206
being, therefore, tied to the specific
207
communication pattern that the system has (e.g., REST methods,
208
Publish/Subscribe operations, or RPC calls).</t>
209
</list></t>
210
211
<t>Another identified terminology issue is the semantic meaning overload
212
that some terms have. The meaning can vary depending on the context in which the
213
term is used. Some examples of such terms are as follows: semantics, models,
214
encoding, serialization format, media types, and encoding types. Due
215
to time constraints, no concrete terminology was agreed upon, but
216
work will continue within each organization to create various
217
terminology documents. The participants agreed to set up a GitHub repository
218
<xref target="IOTSIGIT"/> for sharing information.</t>
219
220
</section>
221
<section anchor="section-4" title="What Problems to Solve">
222
223
<t>The participants agreed that there is not simply a single problem to be solved but
224
rather a range of problems. During the workshop, the following problems were discussed:</t>
225
226
<t><list style="symbols">
227
<t>Formal Languages for Documentation Purposes</t>
228
</list></t>
229
230
<t>To simplify review and publication, SDOs need
231
formal descriptions of their data and interaction models.
232
Several of them use a tabular representation found in the specification itself
233
but use a formal language as an alternative way of describing objects and resources
234
for formal purposes. Some examples of formal language use are as follows.</t>
235
236
<t>The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema <xref
237
target="LWM2M-Schema"/> to describe their object and resource definitions. The
238
XML files of standardized objects are available for download at
239
<xref target="OMNA"/>.</t>
240
241
<t>The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with
242
Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on
243
the Bluetooth SIG website <xref target="SIG"/> and are defined as XML instance documents.</t>
244
245
<t>The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define
246
data models and RESTful API Modeling Language (RAML) to define interaction models. The standard files are
247
available online at <oneIoTa.org>.</t>
248
249
<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
250
models in the same formal language, tailored for RPC-style interaction. The standard
251
files are available online on the AllSeen Alliance website, but both standard and
252
vendor-defined model files can be obtained by directly querying a device for them at runtime.</t>
253
254
<t>The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF)
255
to define data and interaction models using a format tailored for the web.</t>
256
257
<t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models.
258
Other SDOs may use various other formats.</t>
259
260
<t><list style="symbols">
261
<t>Formal Languages for Code Generation</t>
262
</list></t>
263
264
<t>Code-generation tools that use formal data and information modeling languages
265
are needed by developers. For example, the AllSeen Visual Studio
266
Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
267
the formal description of the data model. Another example of a data
268
modeling language that can be used for code generation is YANG. A
269
popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>.
270
An example of a tool that can generate code for multiple ecosystems is
271
OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
272
development of server-side device functionality, clients, and compliance tests.</t>
273
274
275
<t><list style="symbols">
276
<t>Debugging Support</t>
277
</list></t>
278
279
<t>Debugging tools are needed that implement generic object browsers, which
280
use standard data models and/or retrieve formal language descriptions
281
from the devices themselves. As one example, the
282
nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
283
used to display services and characteristics defined by the Bluetooth SIG.
284
As another example, AllJoyn Explorer <xref target="AllJoynExplorer"/> can be used to browse
285
and interact with any resource exposed by an AllJoyn device, including both
286
standard and vendor-defined data models, by retrieving the formal descriptions
287
from the device at runtime.</t>
288
289
<t><list style="symbols">
290
<t>Translation</t>
291
</list></t>
292
293
<t>The working assumption is that devices need to have a common data model
294
with a priori knowledge of data types and actions. However, that would imply
295
that each consortium/organization will try to define their own data
296
model. That would cause a major interoperability problem, possibly a completely
297
intractable one given the number of variations, extensions, compositions, or
298
versioning changes that will happen for each data model.</t>
299
300
301
<t>Another potential approach is to have a minimal amount of information on the
302
device to allow for a runtime binding to a specific model, the objective being
303
to require as little prior knowledge as possible.</t>
304
305
<t>Moreover, gateways, bridges and other similar devices need to dynamically
306
translate (or map) one data model to another one. Complexity will increase
307
as there are also multiple protocols and schemas that make interoperability
308
harder to achieve.</t>
309
310
<t><list style="symbols">
311
<t>Runtime Discovery</t>
312
</list></t>
313
314
<t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the
315
data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well.
316
An example of such an approach has been shown with Hypermedia as the Engine of
317
Application State (HATEOAS) <xref target="HATEOAS"/>.
318
Another example is that all AllJoyn devices support such runtime discovery
319
using a protocol mechanism called "introspection", where the metadata is
320
queried from the device itself <xref target="AllSeen"/>.</t>
321
322
<t>There are various models, whether deployed or possible, for such discovery.
323
The metadata might be extracted from a specification, looked up on a
324
cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's
325
site, or obtained from the device itself (such as in the AllJoyn case). The
326
relevant metadata might be obtained from the same place or different
327
pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in
328
a desired language, and (c) developer-specific comments for implementers.</t>
329
330
</section>
331
<section anchor="section-5" title="Translation">
332
333
<t>In an ideal world where organizations and companies cooperate and agree on a
334
single data model standard, there is no need for gateways that translate from one data model
335
to another one. However, this is far from reality today, and there are many
336
proprietary data models in addition to the already standardized ones. As a
337
consequence, gateways are needed to translate between data models. This leads to
338
(n^2)-n combinations, in the worst case.</t>
339
340
<t>There are analogies with gateways back in the 1980s that were used to
341
translate between network layer protocols. Eventually, IP took over, providing
342
the necessary end-to-end interoperability at the network layer. Unfortunately,
343
the introduction of gateways leads to the loss of expressiveness
344
due to the translation between data models. The functionality of IP was so
345
valuable in the market that advanced features of other networking
346
protocols became less attractive and were not used anymore.</t>
347
348
<t>Participants discussed an alternative that they called a "red star", shown
349
in <xref target="red-star"/>, where data models are translated to a common
350
data model shown in the middle. This
351
reduces the number of translations that are needed down to 2n (in the best case).
352
The problem, of course, is that everyone wants their own data model to be the red star in the center.</t>
353
354
<figure title="The "Red Star" in Data/Information Models" anchor="red-star"><artwork><![CDATA[
355
+-----+ +-----+
356
| | | |
357
| | -- -- | |
358
| | -- -- | |
359
+-----+ -- -- +-----+
360
-- ---
361
-- --
362
-- --
363
-- --
364
--- -- A -- ---
365
/ \ ___/ \___ / \
366
| | ---------------', .'--------------- | |
367
\ / /. ^ .\ \ /
368
--- /' '\ ---
369
-- --
370
-- --
371
-- --
372
-- --
373
-- --
374
/\ -- -- /\
375
/ \ -- -- / \
376
/ \ / \
377
/ \ / \
378
/--------\ /--------\
379
]]></artwork></figure>
380
381
<t>While the workshop itself was not a suitable forum to discuss the design of
382
such translation in detail, several questions were raised:</t>
383
384
<t><list style="symbols">
385
<t>Do we need a "red star" that does everything, or could we design something that
386
offers a more restricted functionality?</t>
387
<t>How do we handle loss of data and functionality?</t>
388
<t>Should data be translated between data models, or should data models themselves be translated?</t>
389
<t>How can interaction models be translated? They need to be dealt with in addition
390
to the data models.</t>
391
<t>Many (if not all) data and interaction models have some bizarre functionality
392
that cannot be translated easily. How can those be handled?</t>
393
<t>What limitations are we going to accept in these translations?</t>
394
</list></t>
395
396
<!--[rfced] We recently received guidance from Benoit and the YANG
397
Doctors that "YANG module" and "YANG data model" are preferred.
398
We have updated the document accordingly. Please review and let
399
us know if further changes are necessary.
400
401
-->
402
<t>The participants also addressed the question of when translation should be done.
403
Two use cases were discussed:
404
<list style="format (%c)">
405
<t>Design time: A translation between data model
406
descriptions, such as translating a YANG module to a RAML/JSON model,
407
can be performed once, during design time.
408
A single information model might be mapped to a number of different data models.</t>
409
410
<t>Run time: Runtime translation of values in two standard data models can only be
411
algorithmically done when the data model on one side is algorithmically derived
412
from the data model on the other side. This was called a "derived model".
413
It was discussed that the availability of runtime discovery can aid in
414
semantic translation, such as when a vendor-specific data model on one
415
side of a protocol bridge is resolved and the translator can algorithmically
416
derive the semantically equivalent vendor-specific data model on the other
417
side. This situation is discussed in <xref target="BridgeTaxonomy"/>.</t>
418
</list></t>
419
<t>The participants agreed that algorithm translation will generally require
420
custom code whenever one is translating to anything other than a derived model.</t>
421
422
<t>Participants concluded that it is typically easier to translate data between systems that
423
follow the same communication architecture.</t>
424
425
</section>
426
<section anchor="section-6" title="Dealing with Change">
427
428
<t>A large part of the workshop was dedicated to the evolution of
429
devices and server-side applications.
430
Interactions between devices and services and how their relationship
431
evolves over time is complicated by their respective interaction models.</t>
432
433
<t>The workshop participants discussed various approaches to deal with change. In the most basic case, a
434
developer might use a description of an API and implement
435
the protocol steps. Sometimes, the data or information model can be used to generate code stubs. Subsequent changes to an API
436
require changes on the clients to upgrade to the new version, which
437
requires some development of new code to satisfy the needs of the new
438
API.</t>
439
440
<t>These interactions could be made machine understandable in the first place,
441
enabling for changes to happen at runtime.
442
In that scenario, a machine client could discover the possible interactions with a
443
service, adapting to changes as they occur without specific code
444
being developed to adapt to them.</t>
445
446
<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
447
give meaning to the tags.</t>
448
449
<t>These types of interactions are often based on the REST architectural
450
style. Its principle is that a device or endpoint only needs a
451
single entry point, with a host providing descriptions of the API
452
in-band by means of web links and forms.</t>
453
454
<t>By defining IoT-specific relation types, it is possible to drive
455
interactions through links instead of hard-coding URIs into a RESTful
456
client, thus making the system flexible enough for later changes.
457
The definition of the basic hypermedia formats for IoT is still a work
458
in progress. However, some of the existing mechanisms can be reused,
459
such as resource discovery, forms, or links.</t>
460
461
</section>
462
463
<!--[rfced] FYI - we have added an IANA Considerations to match the
464
guidance in RFC 8126 stating that no IANA actions are necessary.
<t>This workshop was organized by the following individuals: Jari Arkko,
695
Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
696
Tschofenig.</t>
697
698
</section>
699
<section title="Accepted Position Papers">
700
701
<!--[rfced] FYI, we standardized the capitalization of the paper
702
titles from the workshop. Please let us know if that creates any
703
problems. -->
704
705
<t><list style="symbols">
706
<t>Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"</t>
707
<t>Carsten Bormann, "Noise in Specifications hurts"</t>
708
<t>Benoit Claise, "YANG as the Data Modelling Language in the IoT space"</t>
709
<t>Robert Cragie, "The ZigBee Cluster Library over IP"</t>
710
<t>Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"</t>
711
<t>Universal Devices, "Object Oriented Approach to IoT Interoperability"</t>
712
<t>Bryant Eastham, "Interoperability and the OpenDOF Project"</t>
713
<t>Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"</t>
714
<t>Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"</t>
715
<t>Ted Hardie, "Loci of Interoperability for the Internet of Things"</t>
716
<t>Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"</t>
717
<t>Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"</t>
718
<t>David Jones, "IOTDB - interoperability Through Semantic Metastandards"</t>
719
<t>Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"</t>
720
<t>Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"</t>
721
<t>Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"</t>
722
<t>Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"</t>
<t>Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop"</t>
734
<t>Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"</t>
735
<t>Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"</t>
736
<t>Max Senges, "Submission for IAB IoT Sematic Interoperability workshop"</t>
737
<t>Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"</t>
738
<t>Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"</t>
739
<t>Robert Sparks and Ben Campbell, "Considerations for certain IoT-based services"</t>
740
<t>J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"</t>
741
<t>J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems"</t>
742
<t>Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"</t>
743
<t>Andrew Sullivan, "Position paper for IOTSI workshop"</t>
744
<t>Darshak Thakore, "IoT Security in the context of Semantic Interoperability"</t>
745
<t>Dave Thaler, "IoT Bridge Taxonomy"</t>
746
<t>Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"</t>
747
<t>Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike
748
Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"</t>
749
<t>Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"</t>
750
</list></t>
751
752
</section>
753
754
<section title="List of Participants">
755
<?rfc subcompact="yes"?>
756
<t><list>
757
<t>Andy Bierman, YumaWorks</t>
758
<t>Carsten Bormann, Uni Bremen/TZI</t>
759
<t>Ben Campbell, Oracle</t>
760
<t>Benoit Claise, Cisco</t>
761
<t>Alissa Cooper, Cisco</t>
762
<t>Robert Cragie, ARM Limited</t>
763
<t>Laura Daniele, TNO</t>
764
<t>Bryant Eastham, OpenDOF</t>
765
<t>Christian Groves, Huawei</t>
766
<t>Ted Hardie, Google</t>
767
<t>Yonggeun Hong, ETRI</t>
768
<t>Russ Housley, Vigil Security</t>
769
<t>David Janes, IOTDB</t>
770
<t>Jaime Jimenez, Ericsson</t>
771
<t>Shailendra Karody, Catalina Labs</t>
772
<t>Ari Keraenen, Ericsson</t>
773
<t>Michael Koster, SmartThings</t>
774
<t>Matthias Kovatsch, Siemens</t>
775
<t>Kai Kreuzer, Deutsche Telekom</t>
776
<t>Barry Leiba, Huawei</t>
777
<t>Steve Liang, Uni Calgary</t>
778
<t>Marcello Lioy, Qualcomm</t>
779
<t>Kerry Lynn, Verizon</t>
780
<t>Mayan Mathen, Catalina Labs</t>
781
<t>Erik Nordmark, Arista</t>
782
<t>Jean Paoli, Microsoft</t>
783
<t>Joaquin Prado, OMA</t>
784
<t>Dave Raggett, W3C</t>
785
<t>Max Senges, Google</t>
786
<t>Ned Smith, Intel</t>
787
<t>Robert Sparks, Oracle</t>
788
<t>Ram Sriram, NIST</t>
789
<t>Clarke Stevens</t>
790
<t>Ram Subramanian, Intel</t>
791
<t>Andrew Sullivan, DIN</t>
792
<t>Darshak Thakore, CableLabs</t>
793
<t>Dave Thaler, Microsoft</t>
794
<t>Hannes Tschofenig, ARM Limited</t>
795
<t>Michael Verschoor, Philips Lighting</t>
796
</list></t>
797
<?rfc subcompact="no"?>
798
799
</section>
800
801
<section title="IAB Members at the Time of Approval" numbered="no">
802
<?rfc subcompact="yes"?>
803
<t><list>
804
<t>Jari Arkko</t>
805
<t>Alissa Cooper</t>
806
<t>Ted Hardie</t>
807
<t>Christian Huitema</t>
808
<t>Gabriel Montenegro</t>
809
<t>Erik Nordmark</t>
810
<t>Mark Nottingham</t>
811
<t>Melinda Shore</t>
812
<t>Robert Sparks</t>
813
<t>Jeff Tantsura</t>
814
<t>Martin Thomson</t>
815
<t>Brian Trammell</t>
816
<t>Suzanne Woolf</t>
817
</list></t>
818
<?rfc subcompact="no"?>
819
</section>
820
821
<section title="Acknowledgements" numbered="no">
822
823
<t>We would like to thank all paper authors and participants for their
824
contributions and Ericsson for hosting the workshop.</t>
<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>