1<?xml version="1.0" encoding="UTF-8"?>
2  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
3  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->
4
5<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
6]>
7
8<?rfc compact="yes"?>
9<?rfc text-list-symbols="o*+-"?>
10<?rfc subcompact="no"?>
11<?rfc sortrefs="yes"?>
12<?rfc symrefs="yes"?>
13<?rfc strict="yes"?>
14<?rfc toc="yes"?>
15
16<rfc docName="draft-iab-iotsi-workshop-02" category="info" submissionType="IETF">
17
18  <front>
19    <title abbrev="draft-iab-iotsi-workshop">Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016</title>
20
21    <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
22      <organization>Ericsson</organization>
23      <address>
24        <email>jaime.jimenez@ericsson.com</email>
25      </address>
26    </author>
27    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
28      <organization>Arm Ltd.</organization>
29      <address>
30        <email>hannes.tschofenig@arm.com</email>
31      </address>
32    </author>
33    <author initials="D." surname="Thaler" fullname="Dave Thaler">
34      <organization>Microsoft</organization>
35      <address>
36        <email>dthaler@microsoft.com</email>
37      </address>
38    </author>
39
40    <date year="2018" month="July" day="02"/>
41
42    
43    
44    
45
46    <abstract>
47
48
49<t>This document provides a summary of the ‘Workshop on Internet of
50Things (IoT) Semantic Interoperability (IOTSI)’,
51which took place in Santa Clara, California, on March 17-18, 2016.  The main
52goal of the workshop was to foster a discussion on the different
53approaches used by companies and Standards Developing Organizations (SDOs)
54to accomplish interoperability at the application layer.  This report
55summarizes the discussions, and lists recommendations to the standards
56community.  The views and positions in this report are those of the
57workshop participants and do not necessarily reflect those of the
58authors and the Internet Architecture Board (IAB), which organized
59the workshop.</t>
60
61
62
63    </abstract>
64
65
66  </front>
67
68  <middle>
69
70
71<section anchor="section-1" title="Introduction">
72
73<t>The Internet Architecture Board (IAB) holds occasional workshops
74designed to consider long-term issues and strategies for the
75Internet, and to suggest future directions for the Internet
76architecture.  The investigated topics often require coordinated
77efforts of many organizations and industry bodies to improve an
78identified problem.  One of the targets of the workshops is to
79establish communication between relevant organizations, especially
80when the topics are out of the scope for the Internet Engineering
81Task Force (IETF).  This long-term planning function of the IAB is
82complementary to the ongoing engineering efforts performed by working
83groups of the IETF.</t>
84
85<t>With the expansion of the Internet of Things (IoT), interoperability
86becomes more and more important. Standards Developing Organizations (SDOs)
87have done a tremendous amount of work to standardize new protocols,
88and to profile existing protocols.</t>
89
90<t>At the application layer and at the level of solution frameworks, 
91interoperability is not yet mature. Particularly, the
92work on data formats (in the form of data models and information
93models) has not seen the same level of consistency throughout
94SDOs.</t>
95
96<t>One common problem is the lack of an encoding-independent standardization
97of the information, the so-called information model. Another problem is
98the strong relationship with the underlying communication architecture,
99such as a Remote Procedure Call (RPC) style design or a RESTful design. Furthermore, groups develop
100solutions that are very similar on the surface but differ slightly in their standardized outcome, leading to interoperability
101problems. Finally, some groups favor different encodings for use with
102various application layer protocols.</t>
103
104<t>Thus, the IAB decided to organize a workshop to reach out to relevant
105stakeholders to explore the state-of-the-art and to identify
106commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
107interested to learn about the following aspects:</t>
108
109<t><list style="symbols">
110  <t>What is the state of the art in data and information models? What should
111an information model look like?</t>
112  <t>What is the role of formal languages, such as schema languages, in
113describing information and data models?</t>
114  <t>What is the role of metadata, which is attached to data to make it self-describing?</t>
115  <t>How can we achieve interoperability when different organizations, companies
116and individuals develop extensions?</t>
117  <t>What is the experience with interworking various data models developed
118from different groups, or with data models that evolved over time?</t>
119  <t>What functionality should online repositories for sharing schemas have?</t>
120  <t>How can existing data models be mapped against each other to offer interworking?</t>
121  <t>Is there room for harmonization, or are the use cases of different groups
122and organizations so unique that there is no possibility for cooperation?</t>
123  <t>How can organizations better work together to increase awareness and information sharing?</t>
124</list></t>
125
126</section>
127<section anchor="section-2" title="Terminology">
128
129<t>The first roadblock to interoperability at the level of data models is the lack of a
130common vocabulary to start the discussion.
131<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
132or “information models”, from concrete detailed definitions for implementers, or
133“data models”. There are concepts that are
134undefined in that RFC and elsewhere, such as the interaction with the
135resources of an endpoint, or “interaction model”.  Therefore the three
136“main” common models that were identified were:</t>
137
138<t><list style="hanging" hangIndent="3">
139  <t hangText='Information Model'><vspace blankLines='0'/>
140  An information model defines an environment at the highest level of abstraction and
141expresses the desired functionality.
142Information models can be defined informally (e.g., in plain English) or more
143formally (e.g., UML, Entity-Relationship Diagrams, etc.).
144Implementation details are hidden.</t>
145</list></t>
146
147<t><list style="hanging" hangIndent="3">
148  <t hangText='Data Model'><vspace blankLines='0'/>
149  A data model defines concrete data representations at a lower level of
150abstraction, including implementation and protocol-specific details.
151Some examples are: SNMP Management Information
152Base (MIB) modules, W3C Thing Description (TD) Things, YANG models, LWM2M
153Schemas, OCF Schemas, and so on.</t>
154</list></t>
155
156<t><list style="hanging" hangIndent="3">
157  <t hangText='Interaction Model'><vspace blankLines='0'/>
158  An interaction model defines how data is accessed and retrieved from the endpoints,
159being therefore tied to the specific
160communication pattern that the system has (e.g., REST methods,
161Publish/Subscribe operations, or RPC calls).</t>
162</list></t>
163
164<t>Another identified terminology issue is the semantic meaning overload
165that some terms have.  The meaning can vary depending on the context in which the
166term is used.  Some examples of such terms are: semantics, models,
167encoding, serialization format, media types or encoding types.  Due
168to time constraints, no concrete terminology was agreed upon, but
169work will continue within each organization to create various
170terminology documents.  The participants agreed to set up a github repository
171<xref target="IOTSIGIT"/> for sharing information.</t>
172
173</section>
174<section anchor="section-4" title="What Problems to Solve">
175
176<t>The participants agreed that there is not simply a single problem to be solved, but
177rather a range. During the workshop the following problems were discussed:</t>
178
179<t><list style="symbols">
180  <t>Formal Languages for Documentation Purposes</t>
181</list></t>
182
183<t>To simplify review and publication, SDOs need
184formal descriptions of their data and interaction models.
185Several of them use a tabular representation found in the specification itself,
186but use a formal language as an alternative way of describing objects and resources
187for formal purposes.  Some examples of formal language use are as follows.</t>
188
189<t>The Open Mobile Alliance (OMA), now OMA SpecWorks,
190used an XML schema <xref target="LWM2M-Schema"/> to describe their object
191and resource definitions. The XML files of standardized objects are available for download at
192<xref target="OMNA"/>.</t>
193
194<t>The Bluetooth SIG defined Generic Attributes (GATT) services and characteristics for use with 
195Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on 
196the Bluetooth SIG website at <xref target="SIG"/>, and are also defined as XML instance documents.</t>
197
198<t>The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models,
199and RAML to define interaction models.  The standard files are available online
200at OneIoTa.org.</t>
201
202<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
203models in the same formal language, tailored for RPC-style interaction.  The standard
204files are available online on the AllSeen Alliance web site, but both standard and
205vendor-defined model files can be obtained by directly querying a device for them at runtime.</t>
206
207<t>The World-Wide Web Consortium (W3C) uses the Resource Description Framework (RDF)
208to define data and interaction models using a format tailored for the web.</t>
209
210<t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models.
211Other SDOs may use various other formats.</t>
212
213<t><list style="symbols">
214  <t>Formal Languages for Code Generation</t>
215</list></t>
216
217<t>Code generation tools that use formal data and information modelling languages
218are needed by developers. For example, the AllSeen Visual Studio
219Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
220the formal description of the data model.  Another example of a data
221modelling language that can be used for code generation is YANG.  A
222popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>.
223An example of a tool that can do code generation for multiple ecosystems is
224OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
225development of server-side device functionality, clients, and compliance tests.</t>
226
227<t><list style="symbols">
228  <t>Debugging Support</t>
229</list></t>
230
231<t>Debugging tools are needed that implement generic object browsers, which
232use standard data models and/or retrieve formal language descriptions
233from the devices themselves. As one example, the
234NRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
235used to display services and characteristics defined by the Bluetooth SIG.
236As another example, AllJoyn Explorer <xref target="AllJoynExplorer"/> can be used to browse
237and interact with any resource exposed by an AllJoyn device, including both
238standard and vendor-defined data models, by retrieving the formal descriptions
239from the device at runtime.</t>
240
241<t><list style="symbols">
242  <t>Translation</t>
243</list></t>
244
245<t>The working assumption is that devices need to have a common data model 
246with a priori knowledge of data types and actions. However that would imply 
247that each consortium/organization will try to define their own, causing a major 
248interoperability problem, if not a completely intractable one  given
249the amount of variations, extensions, compositions or versioning changes that
250will happen on a per data model basis.</t>
251
252<t>Another potential approach is to have a minimal ammount of information on the
253device to allow for a runtime binding to a specific model, the objective being
254to require as little prior knowledge as possible.</t>
255
256<t>Moreover, gateways, bridges  and other similar devices need to dynamically
257translate (or map) one data model to another one. Complexity will increase 
258as there are also multiple protocols and schemas that make interoperability
259harder to achieve.</t>
260
261<t><list style="symbols">
262  <t>Runtime Discovery</t>
263</list></t>
264
265<t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the
266data exchanged itself. In some cases the metadata not only describes data but also the interaction model as well. 
267An example of such an approach has been shown with HATEOAS <xref target="HATEOAS"/>.
268Another example is that all AllJoyn devices support such runtime discovery
269using a protocol mechanism called “introspection”, where the metadata is 
270queried from the device itself <xref target="AllSeen"/>.</t>
271
272<t>There are various models, whether deployed or possible, for such discovery.
273The metadata might be extracted from a specification, or looked up on a 
274cloud repository (e.g., OneIoTa for OCF models), or looked up via a vendor’s
275site, or obtained from the device itself (such as in the AllJoyn case).  The 
276relevant metadata might be obtained from the same place, or different
277pieces might be obtained from different places, such as separately obtaining
278information such as (a) syntax information, (b) end-user descriptions in 
279a desired language, and (c) developer-specific comments for implementers.</t>
280
281</section>
282<section anchor="section-5" title="Translation">
283
284<t>In an ideal world where organizations and companies cooperate and agree on a
285single data model standard, there is no need for gateways that translate from one data model
286to the other one. However, this is far from reality today, and there are many
287proprietary data models in addition to the already standardized ones. As a 
288consequence, gateways are needed to translate between data models. This leads to 
289(n^2)-n combinations, in the worst case.</t>
290
291<t>There are analogies with gateways back in the 1980s that were used to
292translate between network layer protocols.  Eventually IP took over, providing
293the necessary end-to-end interoperability at the network layer. Unfortunately,
294the introduction of gateways leads to the loss of expressiveness
295due to the translation between data models. The functionality of IP was so 
296valuable in the market that advanced features of other networking 
297protocols became less attractive and were not used anymore.</t>
298
299<t>Participants discussed an alternative which they called a ‘red star’, shown in <xref target="red-star"/>, 
300where data models are translated to a common data model shown in the middle. This 
301reduces the number of translations that are needed down to 2n (in the best case). 
302The problem, of course, is that everyone wants their own data model to be the red star in the center.</t>
303
304<figure title="The 'Red Star' in Data/Information Models." anchor="red-star"><artwork><![CDATA[
305   +-----+                                        +-----+
306   |     |                                        |     |
307   |     |  --                                 -- |     |
308   |     |    --                             --   |     |
309   +-----+      --                         --     +-----+
310                  --                    ---
311                    --                --
312                      --            --
313                        --        --
314     ---                  -- A  --                  ---
315    /   \                ___/ \___                 /   \
316   |     | ---------------',   .'---------------  |     |
317    \   /                 /. ^ .\                  \   /
318     ---                 /'     '\                  ---   
319                        --        --
320                      --            --
321                    --                --
322                  --                    --
323                --                        --
324       /\     --                            --     /\
325      /  \  --                                --  /  \
326     /    \                                      /    \
327    /      \                                    /      \
328   /--------\                                  /--------\
329]]></artwork></figure>
330
331<t>While the workshop itself was not a suitable forum to discuss the design of 
332such translation in detail, several questions were raised:</t>
333
334<t><list style="symbols">
335  <t>Do we need a “red star” that does everything or could we design something that 
336offers a more restricted functionality?</t>
337  <t>How do we handle loss of data and loss of functionality?</t>
338  <t>Should data be translated between data models or data models be translated?</t>
339  <t>How can interaction models be translated? They need to be dealt with in addition 
340 to the data models.</t>
341  <t>Many (if not all) data and interaction models have some bizarre functionality 
342 that cannot be translated easily. How can those be handled?</t>
343  <t>What limitations are we going to accept in these translations?</t>
344</list></t>
345
346<t>The participants also addressed the question of when translation should be done.
347Two use cases were discussed:</t>
348
349<t>a)  Design time: a translation between data model
350descriptions, such as translating a YANG model to a RAML/JSON model,
351can be performed once, during design time.
352A single information model might be mapped to a number of different data models.</t>
353
354<t>b)  Run time: Runtime translation of values in two standard data models can only be
355algorithmically done when the data model on one side is algorithmically derived
356from the data model on the other side.  This was called a “derived model”.
357It was discussed that the availability of runtime discovery can aid in
358semantic translation, such as when a vendor-specific data model on one
359side of a protocol bridge is resolved and the translator can algorithmically 
360derive the semantically-equivalent vendor-specific data model on the other
361side of a protocol bridge, as discussed in <xref target="BridgeTaxonomy"/>.</t>
362
363<t>The participants agreed that algorithm translation will generally require
364custom code, whenever one is translating to anything other than a derived model.</t>
365
366<t>Participants concluded that it is typically easier to translate data between systems that
367follow the same communication architecture.</t>
368
369</section>
370<section anchor="section-6" title="Dealing with change">
371
372<t>A large part of the workshop was dedicated to the evolution of
373devices and server-side applications.
374Interactions between devices and services and how their relationship
375evolves over time is complicated by their respective different 
376interaction models.</t>
377
378<t>The workshop participants discussed various approaches to deal with change.  In the most basic case, a
379developer might use a description of an API and implement 
380the protocol steps.  Sometimes the data or information model can be used to generate code stubs.  Subsequent changes to an API
381require changes on the clients to upgrade to the new version, which
382requires some development of new code to satisfy the needs of the new
383API.</t>
384
385<t>These interactions could be made machine-understandable in the first place,
386enabling for changes to happen at runtime.
387In that scenario, a machine client could discover the possible interactions with a
388service, adapting to changes as they occur without specific code
389being developed to adapt to them.</t>
390
391<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
392give meaning to the tags.</t>
393
394<t>These types of interactions are often based on the REST architectural
395style. Its principle is that a device or endpoint only needs a
396single entry point with a host providing descriptions of the API
397in-band by means of web links and forms.</t>
398
399<t>By defining IoT-specific relation types, it is possible to drive
400interactions through links instead of hardcoding URIs into a RESTful
401client, thus making the system flexible enough for later changes.
402The definition of the basic hypermedia formats for IoT is still work
403in progress. However, some of the existing mechanisms can be reused,
404such as resource discovery, forms, or links.</t>
405
406</section>
407<section anchor="section-7" title="Security Considerations">
408
409<t>There were two types of security considerations discussed: use of formal data
410models for security configuration, and security of data and data models in general.</t>
411
412<t>It was observed that the security assumptions and configuration, or “security model”, varies by ecosystem today,
413making the job of a translator difficult.  For example, the types of security
414principals (e.g., user vs. device vs. application), the use of access control lists (ACLs) vs. capabilities,
415and what types of policies can be expressed, all vary by ecosystem.  As a result,
416the security model architecture generally dictates where translation can be done.</t>
417
418<t>One approach discussed was whether two endpoints might be able to use some overlay
419security model, across a translator between two ecosystems, which only works if
420the two endpoints agree on a common data model for their communication.  Another approach
421discussed was simply having a translator act as a trusted intermediary, which allows
422the translator to be able to translate between different data models.</t>
423
424<t>One suggestion discussed was potentially adding metadata into either the
425formal data model language, or accompanying the data values over the wire, tagging
426the data with privacy levels.  However, sometimes even the privacy level of information
427might itself be sensitive.  Still, it was observed that being able to dynamically
428learn security requirements might help provide better UIs and translators.</t>
429
430</section>
431<section anchor="section-8" title="Collaboration">
432
433<t>The participants discussed how best to share information among their various organizations.
434One discussion was around having joint meetings. One current challenge reported was that
435organizations were not aware of when and where each others’ meetings were scheduled,
436and sharing such information could help organizations better collocate meetings.
437To facilitate this exchange, the participants agreed to add links to their respective
438meeting schedules from a common page in the IOTSI repository <xref target="IOTSIGIT"/>.</t>
439
440<t>Another challenge reported was that organizations did not know how to find each others’
441published data models, and sharing such information could better facilitate reuse of the
442same information model.  To facilitate this exchange, this participants discussed whether
443a common repository might be used by multiple organizations.  The OCF’s OneIoTa repository
444was discussed as one possibility but it was reported that its terms of use at the time
445of the workshop prevented this.  The OCF agreed to take this back and look at updating
446the terms of use to allow other organizations to use it too, as the restriction was not
447the intent.  Schema.org was discussed as another possibility.  In the meantime, the
448participants agreed to add links to their respective repositories from a common page in
449the IOTSI repository <xref target="IOTSIGIT"/>.</t>
450
451<t>It was also agreed that the iotsi@iab.org mailing list would remain open and available
452for sharing information between all relevant organizations.</t>
453
454</section>
455<section anchor="section-9" title="Acknowledgements">
456
457<t>We would like to thank all paper authors and participants for their
458contributions, and Ericsson for hosting the workshop.</t>
459
460</section>
461<section anchor="section-10" title="Appendix A: Program Committee">
462
463<t>This workshop was organized by the following individuals: Jari Arkko,
464Ralph Droms, Jaime Jiménez, Michael Koster, Dave Thaler, and Hannes
465Tschofenig.</t>
466
467</section>
468<section anchor="section-11" title="Appendix B: Accepted Position Papers">
469
470<t><list style="symbols">
471  <t>Jari Arkko, “Gadgets and Protocols Come and Go, Data Is Forever”</t>
472  <t>Carsten Bormann, “Noise in specifications hurts”</t>
473  <t>Benoit Claise, “YANG as the Data Modelling Language in the IoT space”</t>
474  <t>Robert Cragie, “The ZigBee Cluster Library over IP”</t>
475  <t>Dee Denteneer, Michael Verschoor, Teresa Zotti, “Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems”</t>
476  <t>Universal Devices, “Object Oriented Approach to IoT Interoperability”</t>
477  <t>Bryant Eastham, “Interoperability and the OpenDOF Project”</t>
478  <t>Stephen Farrell, Alissa Cooper, “It’s Often True: Security’s Ignored (IOTSI) - and Privacy too”</t>
479  <t>Christian Groves, Lui Yan, ang Weiwei, “Overview of IoT semantics landscape”</t>
480  <t>Ted Hardie, “Loci of Interoperability for the Internet of Things”</t>
481  <t>Russ Housley, “Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications”</t>
482  <t>Jaime Jimenez, Michael Koster, Hannes Tschofenig, “IPSO Smart Objects”</t>
483  <t>David Jones, IOTDB - “Interoperability Through Semantic Metastandards”</t>
484  <t>Sebastian Kaebisch, Darko Anicic, “Thing Description as Enabler of Semantic Interoperability on the Web of Things”</t>
485  <t>Achilleas Kemos, “Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation”</t>
486  <t>Ari Keraenen, Cullen Jennings, “SenML: simple building block for IoT semantic interoperability”</t>
487  <t>Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, “Research on Unified Data Model and Framework to Support Interoperability between IoT Applications”</t>
488  <t>Michael Koster, “Model-Based Hypertext Language”</t>
489  <t>Matthias Kovatsch, Yassin N.  Hassan, Klaus Hartke, “Semantic Interoperability Requires self describing Interaction Models”</t>
490  <t>Kai Kreuzer, “A Pragmatic Approach to Interoperability in the Internet of Things”</t>
491  <t>Barry Leiba, “Position Paper”</t>
492  <t>Marcello Lioy, “AllJoyn”</t>
493  <t>Kerry Lynn, Laird Dornin, “Modeling RESTful APIs with JSON Hyper-Schema”</t>
494  <t>Erik Nordmark, “Thoughts on IoT Semantic Interoperability: Scope of security issues”</t>
495  <t>Open Geospatial Consortium, “OGC SensorThings API: Communicating “Where” in the Web of Things”</t>
496  <t>Jean Paoli, Taqi Jaffri, “IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti”</t>
497  <t>Joaquin Prado, “OMA Lightweight M2M Resource Model”</t>
498  <t>Dave Raggett, Soumya Kanti Datta, “Input paper for IAB Semantic Interoperability Workshop”</t>
499  <t>Pete Rai, Stephen Tallamy, “Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability”</t>
500  <t>Jasper Roes, Laura Daniele, “Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions”</t>
501  <t>Max Senges, “Submission for IAB IoT Sematic Interoperability workshop”</t>
502  <t>Bill Silverajan, Mert Ocak, Jaime Jimenez, “Implementation Experiences of Semantic Interoperability for RESTful Gateway Management”</t>
503  <t>Ned Smith, Jeff Sedayao, Claire Vishik, “Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models”</t>
504  <t>Robert Sparks and Ben Campbell, “Considerations for certain IoT based services”</t>
505  <t>J.  Clarke Stevens, “Open Connectivity Foundation oneIoTa Tool”</t>
506  <t>J.  Clarke Stevens, Piper Merriam, “Derived Models for Interoperability Between IoT Ecosystems”</t>
507  <t>Ravi Subramaniam, “Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)””</t>
508  <t>Andrew Sullivan, “Position paper for IOTSI workshop”</t>
509  <t>Darshak Thakore, “IoT Security in the context of Semantic Interoperability”</t>
510  <t>Dave Thaler, “IoT Bridge Taxonomy”</t>
511  <t>Dave Thaler, S”ummary of AllSeen Alliance Work Relevant to Semantic Interoperability”</t>
512  <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>
513  <t>Peter van der Stok, Andy Bierman, “YANG-Based Constrained Management Interface (CoMI)”</t>
514</list></t>
515
516</section>
517<section anchor="section-12" title="Appendix C: List of Participants">
518
519<t><list style="symbols">
520  <t>Andy Bierman, YumaWorks</t>
521  <t>Carsten Bormann, Uni Bremen/TZI</t>
522  <t>Ben Campbell, Oracle</t>
523  <t>Benoit Claise, Cisco</t>
524  <t>Alissa Cooper, Cisco</t>
525  <t>Robert Cragie, ARM Limited</t>
526  <t>Laura Daniele, TNO</t>
527  <t>Bryant Eastham, OpenDOF</t>
528  <t>Christian Groves, Huawei</t>
529  <t>Ted Hardie, Google</t>
530  <t>Yonggeun Hong, ETRI</t>
531  <t>Russ Housley, Vigil Security</t>
532  <t>David Janes, IOTDB</t>
533  <t>Jaime Jimenez, Ericsson</t>
534  <t>Shailendra Karody, Catalina Labs</t>
535  <t>Ari Keraenen, Ericsson</t>
536  <t>Michael Koster, SmartThings</t>
537  <t>Matthias Kovatsch, Siemens</t>
538  <t>Kai Kreuzer, Deutsche Telekom</t>
539  <t>Barry Leiba, Huawei</t>
540  <t>Steve Liang, Uni Calgary</t>
541  <t>Marcello Lioy, Qualcomm</t>
542  <t>Kerry Lynn, Verizon</t>
543  <t>Mayan Mathen, Catalina Labs</t>
544  <t>Erik Nordmark, Arista</t>
545  <t>Jean Paoli, Microsoft</t>
546  <t>Joaquin Prado, OMA</t>
547  <t>Dave Raggett, W3C</t>
548  <t>Max Senges, Google</t>
549  <t>Ned Smith, Intel</t>
550  <t>Robert Sparks, Oracle</t>
551  <t>Ram Sriram, NIST</t>
552  <t>Clarke Stevens</t>
553  <t>Ram Subramanian, Intel</t>
554  <t>Andrew Sullivan, DIN</t>
555  <t>Darshak Thakore, CableLabs</t>
556  <t>Dave Thaler, Microsoft</t>
557  <t>Hannes Tschofenig, ARM Limited</t>
558  <t>Michael Verschoor, Philips Lighting</t>
559</list></t>
560
561</section>
562
563
564  </middle>
565
566  <back>
567
568
569    <references title='Informative References'>
570
571
572
573
574
575<reference  anchor="RFC3444" target='https://www.rfc-editor.org/info/rfc3444'>
576<front>
577<title>On the Difference between Information Models and Data Models</title>
578<author initials='A.' surname='Pras' fullname='A. Pras'><organization /></author>
579<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author>
580<date year='2003' month='January' />
581<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>
582</front>
583<seriesInfo name='RFC' value='3444'/>
584<seriesInfo name='DOI' value='10.17487/RFC3444'/>
585</reference>
586
587
588<reference anchor="AllSeen-Plugin" >
589  <front>
590    <title>Using the AllJoyn Studio Extension</title>
591    <author initials="B." surname="Rockwell" fullname="B. Rockwell">
592      <organization></organization>
593    </author>
594    <date year="2016"/>
595  </front>
596</reference>
597<reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf">
598  <front>
599    <title>Semantic Interoperability Requires Self-describing Interaction Models - HATEOAS for the Internet of Things</title>
600    <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
601      <organization></organization>
602    </author>
603    <date year="2016"/>
604  </front>
605  <seriesInfo name="Proceedings" value="of the IoT Semantic Interoperability Workshop 2016"/>
606</reference>
607<reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf">
608  <front>
609    <title>Summary of AllSeen Alliance Work Relevant to Semantic Interoperability</title>
610    <author initials="D." surname="Thaler" fullname="D. Thaler">
611      <organization></organization>
612    </author>
613    <date year="2016"/>
614  </front>
615</reference>
616<reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf">
617  <front>
618    <title>IoT Bridge Taxonomy</title>
619    <author initials="D." surname="Thaler" fullname="D. Thaler">
620      <organization></organization>
621    </author>
622    <date year="2016"/>
623  </front>
624</reference>
625<reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/">
626  <front>
627    <title>IoT Workshop for Semantic Interoperability (IOTSI) - Agenda and Slides</title>
628    <author >
629      <organization>IAB</organization>
630    </author>
631    <date year="2016"/>
632  </front>
633</reference>
634<reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi">
635  <front>
636    <title>Github Collaborative Repository</title>
637    <author >
638      <organization>IOTSI</organization>
639    </author>
640    <date year="2016"/>
641  </front>
642</reference>
643<reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/">
644  <front>
645    <title>IoT Workshop for Semantic Interoperability (IOTSI) 2016 - Main Page and Position Papers</title>
646    <author >
647      <organization>IAB</organization>
648    </author>
649    <date year="2016"/>
650  </front>
651</reference>
652<reference anchor="LWM2M-Schema" >
653  <front>
654    <title>OMA LWM2M XML Schema</title>
655    <author >
656      <organization>OMA</organization>
657    </author>
658    <date year="2018"/>
659  </front>
660</reference>
661<reference anchor="OMNA" >
662  <front>
663    <title>OMNA Lightweight M2M (LWM2M) Object &amp; Resource Registry</title>
664    <author >
665      <organization>OMA</organization>
666    </author>
667    <date year="2018"/>
668  </front>
669</reference>
670<reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt">
671  <front>
672    <title>GATT Specifications</title>
673    <author >
674      <organization>Bluetooth SIG</organization>
675    </author>
676    <date year="2018"/>
677  </front>
678</reference>
679<reference anchor="PYANG" >
680  <front>
681    <title>An extensible YANG validator and converter in python</title>
682    <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
683      <organization></organization>
684    </author>
685    <date year="2016"/>
686  </front>
687</reference>
688<reference anchor="nRF-Sniffer" >
689  <front>
690    <title>nRF Sniffer - Smart/Bluetooth low energy packet sniffer</title>
691    <author >
692      <organization>Nordic Semiconductor</organization>
693    </author>
694    <date year="2016"/>
695  </front>
696</reference>
697<reference anchor="AllJoynExplorer" >
698  <front>
699    <title>AllJoyn Explorer</title>
700    <author >
701      <organization>Microsoft</organization>
702    </author>
703    <date year="2016"/>
704  </front>
705</reference>
706<reference anchor="OpenDOF" target="https://opendof.org">
707  <front>
708    <title>The OpenDOF Project</title>
709    <author >
710      <organization>OpenDOF</organization>
711    </author>
712    <date year="2015"/>
713  </front>
714</reference>
715
716
717    </references>
718
719
720
721
722  </back>
723
724<!-- ##markdown-source:
725H4sIAKeZOlsAA7V963IbyZXmf0bwHSroiBXZBsi+eOweRjjavEhqqkWRS7Jb
7260w7HOBKoJFDNQhVcF0JojeZ99jn2xfb7zsnMyiqAbHm9K4dbIlCVefLkuXzn
727ksnxeLy7UzemSP9u8rKwx0lTtXZ3Jy2nhVngx7Qy9804M5NxVjZ1Nl6V1UM9
728L5fjL7/e3Zma5jjJivsSY7STRVbXWVk06yXeu3h592p3Z5kd7+4kybRcLM0U
729z75Y2/oFP2nsh2acZ3UzrteLSZnXx0n5xe/H/Aojdc8XpTxel1VT2fs6GgHv
730DT9pqqw/STkNPzVZk4OsG7vEUMl9VS6SZm6Ti6KxVWGbpLxP7uZZMauT/Yvy
7317iC5tQtTNNlUnyiXtjKTLM+aNb6/uru9OOAE7x0zkq+//OqPuztmMqns49M8
732A1tNAyLw9LfjL/8kLDRtMy8rcGkMRmI1bw6TN9nCFvZXTqB78Mbgk/jjspod
733Jy+x2rouC34AYrP8OPmFDx7+og/+xboHDsHOMP73h8ldPZ2X97bIZt0U35ui
734sPXgK5nmpFokb5v0MJpmLg8fNuHhv5hq0ZvlHLPMTW6rboZz82ijD2Xsy2xa
735lXV530SDp40885eF/04HppRVC9Nkj1ZE6ubV2Td/+MMf5N8neX5rbTG+zttZ
736VshH2Hzd8B9rbKpsNZ56U66L5LZp06xMXn5obEF51cfDPvAHt4rTw+SmnD6s
737bJ7r534tW76Q9bx4oT+Gbf4jf/7+5O7l1cmtp8tUMwspnTfNsj4+OlqtVocQ
738lUMMcLRajqdQIFs0Rxcnp+N2mZcmrY840NGX38jfY37hRjxcpve9xT4ttDf2
739H21WYYdvbX4/Tm09rbIJOSNPQtfAiOSyTG1e+xWNPeEJOP+EsjzNu8vD5Ify
7400VBG+rzb8sUzvINWQ4xtze0/9s9fV+XU2pQEHJMWoa28e2b5A0UNIvOv74mX
741vbpdLEy1Hotx2NwY/ZbEuhf4d2aKqRXasD+5fQTxsFlPL+Npbvf0reP1xsfP
742cPq0ytKZvTMfyqJcrP91xpzrzE8whNulMyZ+yv+vqxMqTl5/xrKoC49ZA5k7
7438na7PhI7fmRmtkjN0cZCgnRRUX7TcWBVJzJQAq+b3OYZtHHr2mU5YO2T63l9
744cffEgmZZM28ntJyOdPlvj/DX8khyVua5mZSVWFZxj3XWlNX23VCKOPWTNL3/
745HDv3DI//VeaSGFB6abIiucaGkcnBbnBtNHTXBm/+80x/+/7y68vx7XQOKvpe
7465uryRL9N/uPybaJPPD08nh4M/y1/vrp8dzIc9h3GzWbzZmX534Qz7MtEB8nV
7475Bc7bZL/gU2ry7aacvdmQFTP7d0TM0OUntm1Sd7apiybuchTvbTT7D4D9AMn
74866OZaZq+XJ3cwRL3HnqanlM/NEnYRtn1zyfvXveZclIkVn33JLcJv08eDbTI
749QGxFpWCVHm0F+YD1SJZrzPqMj4c7Ov0FIpa3nZwER7XxzTMWprh5Nb4tsvt7
750W/XpxReJ+wKT3sIPNEfduvNylQCtVbN1Asj7AOda67NPM+1dWaVQAehChqWm
7517RQL30aRAzwvP8AyV0OqPBry3z49XQ+kDee4Wtri/OrVE9IDBS3S8p4635v8
752Dg7bvUlnTjl+Rmb1wcHs/7a7A7Q5HidmApE3HID/AyypEwQvLSBwkyyr8pHm
753NTFJ3XlgwoUXwazAHES4Rkb4J6KAF6PdndU8m87huMuHZJkb6CHE7havmeQs
754N5UZJWcQT1ivIsO/CbNMhee/+tP4q29HwsjDRDgC/AtBnZUm91R645isTE1k
755cF/WFGuTpFk9bSXa4oB8NBWhwaIRUiyxbgMbVCdtbdNkstYArMjICfocxnum
756Suvk3D7avFwSCF5VMzzxq2pssn97flUjxsGkZsq3EavNsbABF0wjk2PG3Cl7
757kpu1rWRF2IlKwi1Gh+R+9isIUGI9+fVIKGIkyKcx04KuUYnA5Hy69uQi4MT3
758bYGZHcseM7vSNS2dba/J/aabOzGVxc9lbR1TsV+eq0uoYjbNwJlGB0nLpCib
759pLBTW9egN19jlPucZrY/hMqpvtRDxifY2qzBCy2mPS1BNSTl5PRglKiUlMpl
760C4sSb/Chl+ZFlqa55U+/46BVSfUmWz/+rrbyr/FXn1TQP2PWZF7m2OVyOjVk
761NgQruFvEokDVswLyATbDjtRQlArmqJiNMeoiQTDfOnmhgjXwLfjRhQK7O35u
7623T8MUbezma0RWrdCRYpoY6obMgwfwL6IXreTGWx23WRwJ0LREqEruA0zjx2Q
7630AU00u4VfGB3x95j1IaPQG2KteerExySlMEy0hkmkzIl5SAxW9AgEBIgnkyh
764K3BRmA0fwpMsQMhV4bfYmbJ6qIkQLw4FAiCVE1EKJ5NO/CcWvlqodoC+R9ko
765seI/TZ6vaTisKq9bL0W1bBs/Zz2Fqm0GXy8LBLkWUVEBo3pn6ofkVUnvv8+U
766y4HXvG4jYZOKghp+3xYqSz5kOjnFakSpllg/+EED6ZQOr5d8yXazJZ7pMAAM
767xtW0kDNCyqwq22VgGIkRqX4PnCmf2A9QtDqe/4ncy2jDzuzuTGgasIsL+CrZ
768XvkHNhQEgcuH/4xNmzMTkZbYa5M0FReeli24vyjbQojhkkSk3ZjQV9iEFQWl
769KadlXsPoO6nHR/dZzsXBgnHK8Iws/uQJ+yhLcMYzJ72cti7zVh65rwBAROJG
770CTMfA6OL3aWVWoNzC6MqdC2WrIW7ydejzsrROcCYmkRzJ2BBpgLHnzmlfLmQ
771sN8pjcuyEDLp5zAiRiesrRPXGuR1ZIvtgF8qphCeOYRgNocQ7+6Q28IEahWV
772BMQ4VRMl4tKBeDiEAaQrpiUj+jH01hI20H93G+BIcpITkTlSisrxFDpleyvQ
773hR0CMAJogefd5Gp8YR0g5dRUFZB5BkfrpRWgz4KZ3NK+gse2a0TPBqtuiDBu
7747KJsrCYnUppAuP082b+5PjvAVGsIiVrchDA1uXl5e3ff5u6zw+RVW5FIivUo
775caqUqiRjEicZ5JpRlwaEu07qbJFhzz0GqNvqnvhjAhuieCCpc8YN8GO68VkV
776C3VKa0O9GmE3TSqJsnKL8jnG1aAS9jeniNV4y5N5bx6xpABAwlaq5QcEEa7u
7777jzCo4qibWhDX2nu5m09ChYqhblM1Ut55wn2BR+Ojytr6FnbRn9QuytZ7QdL
778B4hQj99YRboeUjR2XN6P8cPYECWoOjuvsFakQY8pKAdfzgxW+vGjyyN8+uT+
779+f7206dDWDKHJaiBHelAbU594S10CeBzBRmaCLWiiDkiAHLe0DE09TE58EXy
780nvvstESI9UaTxGZOqwca6xT5O30Z3GlzCVygXRtPwT8ArubZg/1uc8KqzGU+
781eQePmmLWIpTGpnhpryXCjb/JJMaKEovxlIKtOlPzzJQL2xg+6fESvkaASTAr
7827JNB8PcCW5tkNEm9bKYb+HvEVFOsegV2QVmhRZvIVXxvJ7MDLx3wsvJP0ESG
783UKI1eVBLH4XihS0LgrQxcckEn9gUIcD5ysRrQmx+3ahWtkzqEx11qmgjWg4Z
784LH5PLIJ9LPNH6jPMAoKsRW9Xvd9XYVa5gMnI4dcFJEvCx4O7em7E1+sO1wmd
7855YCtwdfFZEwYvyxBfmJmiGMABFUrxfJSd8UcxVxwo14IvyqKANZMEkABVM9t
786hizaOLWlLQGUtYIyhuzxW9WHgnUJU579o7XKKJ1KPChDhjpz4sB5ATApIHxv
787sOL+kIB4jMIcSgBKdEvMiilMEUg0KxBcIITY0FDH3e8U4N/B3mdFmZcI/jt8
788/3XA9/dZBT4ilksneTl92GacN0BEvCdDL+utWvJYTs2EtmrtYE7VDOIyGOKP
789H12N5dOnXiDNpwXpAB82RIC1hfEzjbpKCPyygZp4GshYF2lUxE34cW/TZu2N
790VOT5fmUbusrGZPTnqb3PiqwLJDKPVTlcwsTHXrTkPaaEucNGAgYhpnOauzv0
7916hhPcIJ+jDXKLuFlu+KrnZFTpNGVRzw22N2pXMatDuAlFW6IsO7F7whZexrj
792IJT0/gc4yWKcPYb8ex4cxQq9EjHtYhT+LK7ho5TfZhcCkP784psXnxiLdfyU
793Gs7ujqTJNq2+rr5Wmh8z4B/JkzghmgMrMIQLwuRzK86GS5XuwxKrr30gj52t
794QF7PxEip8GJjj0WTJjbpdkD9C8DJvj2cHY4kXZczcYsQh6HVAdlJRCQmcfDw
795j5dvR3iwwYTjmxjCnWdmBgDNWKuZHh4oNSHCEYJUujTgmiPitiLvx8ljvQR+
796+vOLL198eorX5xS2jsmRvgXmdkLM72BhwTA/Nd0ZlAg+n8G247NYro7VZMQ0
797bwWPZX3CJdPhwNLYZ2L9cmSltwRm9oPhe7LA4+T23eV1cmkKOGrZ7YsY5CfJ
798KU3W/uXF6QHX0eb05u+/OdOQDNEUnetSZt+/Oz9wkdpIE6+6syPNfcv06jZG
799ydXZq+4HSSLAB3w+mzfKkkGkB7oVuD6HrRaGEzJMmcChL8LE2IqKGCDtqv5e
800X2mQEsikKxF7Bc0UbAj2cjx2XQxRHLA09AJFcCtJvQbIW0i05ESUGJ+IZl6m
801OtN1KymDo9t2IpAFkMd7HPXuCBYSBjL1wVZO+UgmMgxN5EMkZRNQo09dLqyR
8028J/YgCU6Bj/EhxQUvq0+3ucg3cPU1Uf6Bw3G5H0NMqTm90FAqEt80iK6lJEk
803HA+HUsjYljZVZxOZ9NRh2U6Gdnd83DCSmi9MiTpcF7ziQZtmQH/rJYesQpih
804n2DSczaucN/YLcGoFAolm0xnH5QyZhjTqjAWFnxsl1S8CQNXceyrDMEb15oV
805rUI4LFghTQQGJHcGp49xHaZTVvgJfCa6duztZxx1ZnpghPLtEnZB63YdKlvT
806DftaH/xwjNAi636oeELQ3rUL1qSSTFQYQYs/BGixlZABQGoYXy5hceH0MSEA
807uo+gMfSEQTcxp2MapHguqekKqgxpOm8r33jRxWq9gMdHlerrHPSwqQuAXmns
8088dZHGLL0c8dO5f11W4FNxOhYU6nEInYD95gWVltJhZs6IMmERFJYImwX2aSd
809cfOJK0TIUWw1MDY0sbcwJVVI0S8Ek0IqFU8NrD2IbguHNTpbol9lDYMXiD2j
810dR1kEG9JWgE2P6ed0frsykgFIwqzSqkC1s7SOVgiC/TDLR2btqnlcEaho5KZ
811daN8RK71GpjiCbNdoXdh/+ry5ID6tZISKMt+UljBslq1v1IQdeHix49xBRXi
812zIjOOkuovNflaHrNLyfGgILvZEym3dS09BIanh1cxCO8omGRUEBouSpo/uCA
813qVQsrSJ096vrFSIDRHnNyhxM6EkDF4J9woT7rG8e0EI9ZlOXH59CIyEmeLSm
814SeulPZLdnWhsKf69BbdeSslPV/PsWFwIlGdF1xfJmSbwikQzWX3qV3YC42GJ
815ND5+xAefPqkHFp7kdRmWh10mJxmtyW521qq36WdlUVit2K+hl62rz2Dzz14d
816cKF18ub26p1391qocmBNp4qjEpc7vTnBzI2nZZuqqcX0u+v2u7+vGsRiwIap
817+4vyzrDUGKjfaLURWn3lU8orknThpP/RI2ebCfAJ0aDOzIIOFGiUEImVAonV
818nY819ReNM1gYdPXJlXmfu7EQbHHCPRbjm0y484FRAtQfmdSuxn6nFSrpRA6G
819lxOQWmgOX4s12C7EyZXkPA3zERBKX35YUJqqtqBvDfyFqufp+D3QSPLespWk
820YJ9m1i6SfQBIJxqkP3QoxGjylc9yJ/s356+01vgM+30U0dZKnzq/Pr/F29jJ
8214UaBLKqZJBslE6VT8OxnkYDhr8TZiUNZwCRT2X1ORxGaS7gfPuPMzjCYWhgH
822xXd35KNZ+Ig1ZR8QcgrvtZ7M/eVcX0jKsc5mxeG5XXYZpoqJXAIodQSjnoj9
823lNWM3rVJcndHWyphR/o9lrDdktBhQmAFLFQJjHGUE3xhHRNDD8CF+YpD3+P6
824jGZnG6AZHuE62iQIlSec9vVWqJxx8iz+RtM4fSZmurccfHdnWS7FfpKzJHlu
825c5f0H76GmX2Iw5iIwyzXmBi8kKYUcR7SixJRqsN6qtJyY1QSuGjzJuMrdlpq
8260FBLTcJ3RMA56b+YWv4xpLwCQtq+SgkZ8aU1tZTj3G5LxEcvCSdjqzGrvEG1
82746B9lEzzzApa1h4agimxNfB6QZDP7aSdzbgHt+1SS/sIicOHKq+R1AkrQgyr
8289MKfqpdOJhUAhuRxJJIQzNDZsUFt6qisQii3gVtiIAeD6uM8XajYoAXQ1iNB
8290AlUtLA94d/deXfzKhm4ad+Ho1Hjtp4bbFTU9AOVUEl00IemJKuXuVk/7+C9
830iZ6skw1XTgnjWz2dGG307qh6xr0+gZjE06K8Vt/rTZoKPsvnAWrZD8SKQo0p
831wkTKxzgvQZfjDg44n5MMXE7s8jmc2zsfFGxB4BsbN/Q5XyR3iC7qPNjLOxdd
832aP2kbhdLr/EieH77CxdmSeHX+HRblLlBzCecQEySlVWWPADQ5pbNqT6jqlGn
833oKipA6Lflysr6XbJ10lSXcMlF2BLsDgNPvGoFzdKeNlo/tV5HAeAV4hUpsZ7
834uYX5BYK2pQjsoifsyb2EakZVFhGuFPskl+SQhE0QV2J31BB3ZW56rNCWEGoZ
835WvwI3TSYHYvkN5IWYKLGKnvJNCxizqy/tCEZNgbEbIUHyMCoOHOxLNkwjOA+
8368V1K2lDh9waRc0a5MItAZuzlFA+JcaN8sDuJUYpYRONlJZlkhS9mmhB1KU3q
8377NT+MKCS3I9AD99mAgALBjcS7UIYIlnAN1oyyK0u6hKqxqzKKGHbCmIzSro0
838NdeuFCFr9lXaoTim68LAnGgvSOMkG6CELsIsD2TnIm5yNY6L+OYQ+IH7/UGK
839WdyIUH6AkvuaSoD8weeEUqsm5Txkp8BqUW2j+gt7lWqBwxXTdPFUxxvH8HO4
840JjJizY/9h6n/UPeolm7eYJFZj1VpCjW/qCyqJcAgLMxBsKElSsHLC36I1EXT
841UomVxJa6zGYejU4tAaxeh5DT1d+IoIVHw3y/st0wQZHnXHTf22uZoOgEmZm/
842CTGUxmtCqz9C8fGj+5eDDX2U4w0WGwb6NrfGNOJodbpqyFs6G7UUfmOxYDIl
843qxeJa4lgQaKLdPboba2rQwTmgILdHaL/LM6TOjVT5nYgsIubnYh57OvNPSaQ
8449aUW7mhNFFgF1RlpEourCas4VFMeqFlIs/OE7kgMmafJ9HMokjJlIVvyd2qC
845dnemedmmUQrNZ2NdhCjTMzvt2lsGgzxmkEPny17AJWmUVVZdvPQEd/Z92SgL
846MZvsIyXxwMV8rBy5trDNtW5OIBGmtJQKBVGL5zJji+JT73aVUXk5rttrqY4+
847Ql8R69erULon981BUq+Lxnzod9vsTw6YPh8DV1T9/FnGbIQJJaEuJKah2Z8e
848dPFHV7nQfs9ms7TnMpqRv4/SmP8macyLQjobUqttjXC/KtebrYBd96sv8WoP
849meQ9RWy4z5LhjOytBzejXtFYjDep9SbfpU2D+ZYd6JtuzUrT73TW26GHkfaq
850ZuyicVATRlw8fFOmZj3yLaZO09jsKA05cE5W+vV6BV8sJU0zn5kWd59jvHQ9
851yJIVDgmLvoBN8H1sVegcWQ/El9HyfH9jNO2h6zjEPGLYd3f2i//8+mBckPET
852dmwqrnCKgb2qG1ELdSSdGTEIRUppMxXbGWiZsIDt3v7q37/9Mq6ROnwbO1BP
853IgJ/SS8Me4yS5CX0m0VqqMHFtXZuqx/XOrdCgrkNjcBrEfmmHFuPnreU4HvT
854IXCj1jRtIdo20vGyuKMXLiSsMPBO6vWwlPzWlVoJ3fAXXF5r/SNNpBdP7Mgg
855vuOAWCsrHjW36NHkreBDx1eEPDx8oG4ofWTkBzm30l8o1KjsukXS5YgYOiwx
856sVPtCaylX0c86KMqmewSfa9LCK9Z0NWdv46LEF14O8x5+yrT2js0k7yghWEn
857wotRlx39+BGfjvkpM57SXlvZfhhZdaxTwd4WDYQBhS/SkO1EnPYb2+eQRdEu
858JlTn+3g7ohY9pz5MPHOqr4vQfjmxTgMOyAipx3g4Lw2VbVUz2grNPXCRtCgr
859YVSIEwbgUHPoieeMX8BUDKrY0//GHzlG8fsx//w++cw/7nF59b/kk//63Ffd
8604/1Xx+PffA+PbH31N1+Wr+NXe2t95mX3VbzW7U9sfDre9vC2x596cvjs08/F
861T4anxtsIw2cn20kOBB/h/38bfvv3v//9KPkb/rvxnjze241x/w90MUkOXww+
8627e+GTHi0OfZh8p/J4QYx7vFn1nn0Qv56seVVffyf4uQzzzz33Ofu9FMCtPns
86303IaPX30t994Nvr26G/+tSNh6m+rIJ848jvu9mwLl7f90Wc7IfvcN/2z8uaR
864F6DPeLV71hu5j8fJ77w30FNnf96jnX1xY+X8U/WC9pHNPEcb3VP14Z4AzPdz
8651jp7FWyH9VeuI57HyrLGlxjbhUv60Y+F9qiZeHrXKB777cz3IbHfQWvKQGG1
866OhHxmpXJWBAXX5l8kZyX7GgVAGqSPW/n91yuq4RXEk/RSN+OpIiZk1oFMhgY
86765fyBrvpXQpfDlOwSZkXaAzbub7z87MbMhUaEF/CKQagEgoS/oPt799q56kG
8683T1HvAXCSMDT7y/tXuiRNDVb2oI2XrgjfvCZF+lCA8bwrbkdasaoDmL14JSb
8697pK50n2fccvzg2crVZLSkmzEhCWSaojIOJcrFXC8PkuYxs/Xh2GFev5s4nnf
870sUCaPvJskYUGs4pFsESP7+j5PbtsHByoe9ix/s4j8EFDCNMh4EmlXVRkhxdN
871OR8j55YiUXY9xRM9VsNoflVGzbpbGjwQXbIYSLFkQuNYjuI8h2nlvFoINqMm
872Tf+WJEG6pjQFd6wyH0lxWrN/vLJG0uLdEaZS4p5U21XSjiSmaXzfy2YjZYi8
873XdOzzNYBwi4Cj8WIC0f4zLSZW7XPlcVrl8xszrN33LJVub0iIm3JzGax4GDy
874WVlBlF02UQ83hdNlEUyUFCqEklUg9skN37MVEHcaJ+J773YxLEfwR81oDQMy
87533Nj+M5XxOmNPNHh+9Ax58rdmY9PNrJbskqTpXK6IDS0Rczq5EBW6xM3UWvk
876cO2M9FNXrQspM03aJnJoVLuawslOPxntqQQmfY5RLLneXssdvxkznYx9pAw8
877T1Rg6jOkjZIeByXY6V/YEfWyPNnbFYjvyZskj7WSmMuBV8mDQ1PaupGW7NRK
878Rq+QagfFJ+urnSSmvdvRZvg5WZX0ROFwI+JjS57WLLVMqGcn1kvHWlpAzTt3
879ob3zHWocfO1UixHar9TlzZ4+teVyS+fMs/icsktFdzmmP2rDJaL5aqYs3Xoo
880G9Rziq5hlCcxWqfHvk7hcu1RBTY6AkWzEHW71p3tG7wbfpjrMrOqd3Rtd0cP
881gdTdIRDyUwu5SqKWGOU9zQY/RufGfZFp2OrQVdk2z0x3Ehmd7fJnz6Wyxdxc
882x99D9oVrWF0iAmZ9aCo+YsQUXMgPOuuqTXGDjgFWJa8v1OWGurJmV4LOQCyW
883vt2NfKg7U8Y044YxH5RK+20MddNOZDD8JWmypquClY4c5gXcIWX3lW+W1Zo6
884n2yXs8qkIYPD86SusBbK35W/pElAw6CAzxeEIPaLgvr6fu0Gsmk4dYuHILTX
885F37f6l5Fo3aQUNxWyv9AKQo7lrOO6mWijJCePtH0M5tzedyZp4hpCTsGuPJf
886r1J74bqi6yneglyMpJApczmOOEK8oZf5fIGgT7EWZmn9K61Bm9QsvdnxdGi9
887a82D7q0ekWIhKcoyp5ZHiNXDu2NWsnscy+3IIsg6RoUzozmorWuknVg9JZ+q
888oZ+3MPRjJlaFYYPGzkLAgGdueEqlDpJ0OfwmdOx0RUjp8qVexSd1dndYxw09
8892j4XaGZ1tN+uP/q+z0Y5Wi7H6X1bjjZmsUM9so0mZ1F/zYTXBQ96AxRNs16F
890ylc9pAFbu+gVh6gcdpl07DKI1gdcdX1OpQ8p1m3dt6pMWTGeUMFhr7hW+ZId
891b5C/BzWB5KUu+tT1GMpdZuVd52S9bVSGjJx7CUJG60Tv1LN6XKQcYHZTsTMS
892m8T5WQV1/eY/3lzUfpfdMV5WnSjXTOezDmYefJ+DOxVwz0rtRNgi41OL6NGC
893LrkSWNfq6jmiRnKORVTaAO/PcnMIllSxKiDzXO924HLI4hmhe1RlEIviRgzn
89490KlMDQFVpZGMDrW3PXgekw2UuZr2Yxccu701kL3COTO3F0SLhzpXOqfPnXp
895fgkJCG6DuNb+/Wn//S5uEIfQNS1HXWHu6GI0wn02aysHEdWBuu/icHVQOnEY
896SNbjQGs5Ea8dYdYwUNdv4otMvUl5ECw8q1h4JF4Sq4Vch9YvV+bBQjqZ+aWc
897uHayDnzST/N8MQ3IRvPeBhOZmxfV5XlVV/+Uit0jhMJpMP8Z4ZADHcrxWE/Q
898yAGICh5V72fZPzl7Wx/Ii1OzVOCO9biO3pWwyFOyLDFw1rWb+nNj6Uiq3HK2
899JOYD2/OYisBDWKSrl/QZ2ANxEWIFAuMJ6drXtSNs64+caVSqVxGEen2HXlYa
900QCh2hVCG80FdnGec0ZAWNVEmHqcxa3qmmEgsj9cl1f3d85hOBg9df+FSGNpP
901QVhJdq8r71PRFSq3lCtc42tW9SFv1EzpVwyI1VuyO94xN48aPUcEszvM6CJa
902ObsuVlIMEE2A0q19HY7g7l31l55hW0qHTwbH3B53j4wc0+tR2+sGSVM1YL59
903gdbYZi74sN0Bj45NXT1alqc14bVXOXnQhd0BkayySjq6pblRlynPiTuDgj2a
9046VoP8REg9mytwk78rH629/CgqQmqL0Lmcos8WMNWLKJzwk6advFem/ZIEY1n
905dK+dSO8ZCKLpcIXW2nU66Xx153r9keYfL9yVRmEzvXWPrgnsleK/3X6iqNs5
906BitS7iJsJabpXwywKHUDIL2hgTqu3x+qUET3XcmZrUrO1TjB/UUwxsJaOjXs
907hNw30laVg+oOy+l1UE6WNGTsdwqEQqUc3w55LjVt/K470F6/CNPpa+yjYptw
9086mxhOEVPNxovWHGv8H7rofIpo1hGa9165HDTvZnS2vILaRjwnU9qtJ84VgYt
909cUBGoWIv8oPY6QyB+No32fjLWthZ64IBOYMWN9XEx9IO4w6/Zzg+WHKapcJv
910dthpUIt1ZjyLHTEankwPTQ5bSj+DzY6nEe8E34RbvCRPsOXCmOQ3GE4cuV3a
911nRNhH4xjYsSy4Ev8rWyhKa8v8tordHX26kUdmpbiE4H9bJrRfub4MgN2tDmD
912EfbApVhqdwgTLJDwWkENrVW4XKcL9SvaL305i8iKJIxXrChDpEdDawDlA8dt
913l6mkh5x7iGcNbZuuH6YnFc7HZrQY5cifw/fFCW8BIDehpcLy/id3+ojnf5IN
914BpnQfRqYFKUirJHA1bWC/9/o0uAajW1apNT+tho54KkZ+P65zERuSP2Lu0SV
9151wXqaQhgM9d/XPEO7YKHitVuhfNEeiBwy8nR4JQJyrbfWeY8wMk0dMKqG+mc
916wL9rucw6KnirjHLJFA8y8JL3rSbxpXk9LgcEI81IetQuC3cD+nvO9W6QUkOX
917WFA9gUs5qfwhOTnmIVjeAcAe2UUGIxBn9r768lO4KbKXywt38/le/O6sanT9
918C69jr7LkpHp4KGHtb0y+nCfn2HKQGy5q/9//q7C/jnh15tzA4f8g9zaO4jvQ
919dW167TqICVepDxdzegzOs4ADsgb318Zr0ksBv4hpS/Zem1TusONM16FX54zo
920lR+9LkdSAeUVLAgpCF72OMaZqXidV3JKISkQy+y9KzPJJPUzHXUyb6umlndO
921EddCZc9ylizxhhRinO52VyaIvPpTUMG1IIaVY+4y0E05sRUGqsws40C0OX/N
922ZqfYwrO8lesv32aTSq7yJE67uN7Tgyk8XEZbYMlbz/ifwCZwtsRHd7yFySR/
923LZsmw7ivTFbN8f/juJ8rd9T4bKuc1pEO/NM2ywVynrRNGd1qJJfz8vMzFyl1
9246F7o+rHImOUDFD3XdC6mdhf3XvF6IG7riQ9IoDOcfnjXqDK4WlMzX5oaarXA
925KBs3kvqKxeBiVXn7trFLgplXLEMST57AaoAbZ9IPydEaOhtJEN1VrVwlr9AR
926H1/MCjlh191frQKlkBZWWqVmLidaEHC95iWLvBSizZKfjQTgs+S9zVaWjL96
927JHftShrShNnuJgAi9LRGYKmCcGepHlUqUvC2nGbywnDRT19Nr9LESvz3QJW5
928RdSy95NF3JJbdvK5f8pSoo8vivsKLK5aDTLP4ohKh+z9MoZNFd/4RQpk7vXt
929lTtUpHuvI8EaAAG9YTPmiJ7h/BSs3dzXO5eSCnfRXiLqCXei6vbaiVHe/2Ds
930BJ5vTs2uHkqEgLCyU9Gj4W0e0M6XTOpqxfLpm25dqpAnPPvMPUE0DqiHcX6w
931i5KSHc6nSm5q83rHi6Lg1f+c/blfVZDLMYavD7+EnIIvF8n7119+A97IHf++
932j7WWcZQQ2LwfMAB2BNJ21hJ/Jm+s3HpJsm5tcfn2WMNd3o7nVFkvVfJptFBe
933HPZ36l4hTlmsEXXMkh8yqN/PbTGdtzmkvoRQ/4xvZ7YtIGq8vmLvxtZWLvnF
934QmEB5KKOzgqKzHWnX3lPg+vx3+CF984k8CSqGQlNQ9Hbk9HHp5Lg/Z4JQ7mo
935w9tbfcc0gGvcMvc7GEC8ASgqkncMYfFPKuwPuUEgBu1rHqzw7zd/rYSErs/+
936WgmZ/geDnQII/1XoPYERMTNa02nfCG7ceFk8p+SnMGrr5K3NJgaD9p2kW3Q1
937hdUrYa3LtYopW/OVIisvr+nn3sIfYKN4U3Ph2cnF+LsaT64vXEFCWgqExe4y
938AxkLSOVBTgqymVZ0jorbSDXo2d9PAXMrd73GaVC9f1fGlVP4r20JLylHp7qD
9391rSnr88wMD9wSgYqj2PDhQXsvWcAu+f5uKnKb4CBwbAyhzDfmX9ksHL39xXN
940tTqkQYfUlgWcFEIm1K8qV+n4VrLGkW/D1He89IpXlTJAzPXOUp29NBCjgtKQ
941ErfIbfqDW+/DEXIhwNtPm9wYaF7TjBLMuFgbSBg4TGXjASIY0yViIYWfougn
942p5/xW0Jk9GteFnNjwAPvPO9At1msY4W40iRgLf9ILsBz7QY7d/cUvuqiyLvM
943wa4zd4GOvyN/u79/w/sgK8Ah8aSmrQwGLTKbCygqV3LV7ZM2K8ZWbfgNOOqC
944xI7QStcQ7FdMxLGcUzR6Y83+7Qk+PdACa1NHBwOdKn2gtMmVj3u34Xc+BeZ6
945Md/K31XM31OWLG6znJ1vv9DoXBL3XU3Nw2joY/cG13e9DHcr1s+7LrmDwSnv
946a+21jy7CEjLesR8QMQIM4Rt7z8FSszaQQkJZIICfsnqeUZl/sOtnZnrN60EH
947Zor3izqdpMseR3bQodxbhEGuonXKizbMYjkReLY3KKJI0RVvMLoji7WI53Gq
948CgzsN++bR+wFgUXgLlDzufs7SpdbuCvL/MkhrjOKIfamygR2nruejsuu7rLB
949jNPIa73s4+EbYB6W0uH9IM0y4tNMzYrPuYBkLAUhXtarT8swU32ldyfF1cXZ
950wZ4ChiKtgEBvgRQAYovYa0S2QmL1nswCUyGGfmAI9yAX9e6pvHuT3b8h6znR
9517AyYDwf3tvxKnM2nbvf+n/wmIe8WHwBPUt7IWaYdlH1dtUROnO6tLQFZEQ4C
952EzAiNNPcrOqHjA9DSiC0hRjf1yTp1Faz8RmLH3AipcaQ35u5xpA3iMZvq6zq
953YpeeIz9O1KY5G/VOj5lQN12Tj/zeAkQBlhWnYKCZNWanTAWBLaGl2FjQkVkG
954ri4KdXjozN8HRtmN78LDIHJp8v5ZeXlxsDcIv8+O4YlqIbTXuxSF3l+70Ls/
95598/twog/2RpRAxRir0nC0d1fL1wAHen/FbATszYbgfUZy7AyWz+AC58P4ueT
956m0ssAPaNXX1fDB3J3burbbFl+I0b26K671sDtzyM0F6X5UwJHmDhl3c3F5uR
9572E/ZLMuD4kTBkOmCoS3BVvcr79hNzAtCocj0+VWZrvl7Nhq2dBksc1JvBgbx
95820PsLGLnf6fZVph8m3G76g0Ue25bPgAVBUsf+KvqBoi0Y5gYVWyHIWMoAmcm
959n5lqvQWj/s/W5EwgDiHqTzC/v7olwE/xl4nA5BRb1j4AoyfcRzPEetHvdtmA
960YfK7goYo6/03Z0MY0G195EupV/mGp4sFOzYI7y5u70Taes4nPBXcRRENvGHD
961zy/ebbXRZ0Rknis9Y9pb/ZbAfaA8W5JK14iAM3h+nwbyv8aD2fDdnf8DIhqM
962yV1zAAA=
963
964-->
965
966</rfc>
967
  • <?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>
1<?xml version="1.0" encoding="US-ASCII"?>
2  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
3
4<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
5]>
6
7<?rfc compact="yes"?>
8<?rfc text-list-symbols="o*+-"?>
9<?rfc subcompact="no"?>
10<?rfc sortrefs="yes"?>
11<?rfc symrefs="yes"?>
12<?rfc strict="yes"?>
13<?rfc toc="yes"?>
14
15<rfc category="info" submissionType="IAB" number="8477" consensus="yes" ipr="trust200902">
16
17  <front>
18    <title abbrev="IOTSI Workshop 2016">Report from the Internet of Things (IoT) Semantic&nbsp;Interoperability&nbsp;(IOTSI)&nbsp;Workshop&nbsp;2016</title>
19
20
21
22<!--[rfced] *RJS or Stream Manager - please review and approve the
23split of the boilerplate paragraph in the Intro.
24
25As 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
36How 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
49   groups of the IETF.
50
51-->
52
53    <author initials="J." surname="Jimenez" fullname="Jaime Jimenez">
54      <organization></organization>
55      <address>
56        <email>jaime.jimenez@ericsson.com</email>
57      </address>
58    </author>
59    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
60      <organization></organization>
61      <address>
62        <email>hannes.tschofenig@arm.com</email>
63      </address>
64    </author>
65    <author initials="D." surname="Thaler" fullname="Dave Thaler">
66      <organization></organization>
67      <address>
68        <email>dthaler@microsoft.com</email>
69      </address>
70    </author>
71
72    <date year="2018" month="September"/>
73
74<!-- [rfced] Please insert any keywords (beyond those that appear in 
75the 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
84Things (IoT) Semantic Interoperability (IOTSI)",
85which took place in Santa Clara, California March 17-18, 2016.  The main
86goal of the workshop was to foster a discussion on the different
87approaches used by companies and Standards Developing Organizations (SDOs)
88to accomplish interoperability at the application layer.  This report
89summarizes the discussions and lists recommendations to the standards
90community.  The views and positions in this report are those of the
91workshop participants and do not necessarily reflect those of the
92authors or the Internet Architecture Board (IAB), which organized
93the workshop.
94<!--begin DNE text -->
95Note 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
115designed to consider long-term issues and strategies for the
116Internet, and to suggest future directions for the Internet
117architecture.
118<!--End DNE text -->
119The investigated topics often require coordinated
120efforts from many organizations and industry bodies to improve an
121identified problem.  One of the targets of the workshops is to
122establish communication between relevant organizations, especially
123when the topics are out of the scope of the Internet Engineering
124Task Force (IETF).
125<!--Begin DNE text -->
126This long-term planning function of the IAB is
127complementary to the ongoing engineering efforts performed by working
128groups of the IETF.
129<!--End DNE text -->
130</t>
131
132<t>With the expansion of the Internet of Things (IoT), interoperability
133becomes more and more important. Standards Developing Organizations (SDOs)
134have done a tremendous amount of work to standardize new protocols
135and profile existing protocols.</t>
136
137<t>At the application layer and at the level of solution frameworks, 
138interoperability is not yet mature. Particularly, the
139work on data formats (in the form of data models and information
140models) has not seen the same level of consistency throughout
141SDOs.</t>
142
143<t>One common problem is the lack of an encoding-independent standardization
144of the information, the so-called information model. Another problem is
145the strong relationship between data formats and the underlying communication architecture, 
146such 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
147problems. Finally, some groups favor different encodings for use with
148various application-layer protocols.</t>
149
150<t>Thus, the IAB decided to organize a workshop to reach out to relevant
151stakeholders to explore the state of the art and identify
152commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was
153interested 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
157an information model look like?</t>
158  <t>What is the role of formal languages, such as schema languages, in
159describing 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,
162and individuals develop extensions?</t>
163  <t>What is the experience with interworking various data models developed
164from 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
168and 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
176common vocabulary to start the discussion.
177<xref target="RFC3444"/> provides a starting point by separating conceptual models for designers,
178or "information models", from concrete detailed definitions for implementers, or
179"data models". There are concepts that are
180undefined in that RFC and elsewhere, such as the interaction with the
181resources of an endpoint, or "interaction model".  Therefore, the three
182"main" common models that were identified were:</t>
183
184<t><list style="hanging" hangIndent="3">
185  <t hangText='Information Model'><vspace blankLines='0'/>
186  An information model defines an environment at the highest level of abstraction and
187expresses the desired functionality.
188Information models can be defined informally (e.g., in prose) or more
189formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.).
190Implementation 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
197A data model defines concrete data representations at a lower level of
198abstraction, including implementation- and protocol-specific details.
199Some examples are SNMP Management Information Base (MIB) modules, World Wide
200Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.</t>
201</list></t>
202
203<t><list style="hanging" hangIndent="3">
204  <t hangText='Interaction Model'><vspace blankLines='0'/>
205  An interaction model defines how data is accessed and retrieved from the endpoints,
206being, therefore, tied to the specific
207communication pattern that the system has (e.g., REST methods,
208Publish/Subscribe operations, or RPC calls).</t>
209</list></t>
210
211<t>Another identified terminology issue is the semantic meaning overload
212that some terms have.  The meaning can vary depending on the context in which the
213term is used.  Some examples of such terms are as follows: semantics, models,
214encoding, serialization format, media types, and encoding types.  Due
215to time constraints, no concrete terminology was agreed upon, but
216work will continue within each organization to create various
217terminology 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
224rather 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
231formal descriptions of their data and interaction models.
232Several of them use a tabular representation found in the specification itself
233but use a formal language as an alternative way of describing objects and resources
234for 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
237target="LWM2M-Schema"/> to describe their object and resource definitions. The
238XML 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 
242Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on 
243the 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
246data models and RESTful API Modeling Language (RAML) to define interaction models.  The standard files are
247available online at &lt;oneIoTa.org&gt;.</t>
248
249<t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction
250models in the same formal language, tailored for RPC-style interaction.  The standard
251files are available online on the AllSeen Alliance website, but both standard and
252vendor-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)
255to 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.
258Other 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
265are needed by developers. For example, the AllSeen Visual Studio
266Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on
267the formal description of the data model.  Another example of a data
268modeling language that can be used for code generation is YANG.  A
269popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>.
270An example of a tool that can generate code for multiple ecosystems is
271OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing
272development 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
280use standard data models and/or retrieve formal language descriptions
281from the devices themselves. As one example, the
282nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be
283used to display services and characteristics defined by the Bluetooth SIG.
284As another example, AllJoyn Explorer <xref target="AllJoynExplorer"/> can be used to browse
285and interact with any resource exposed by an AllJoyn device, including both
286standard and vendor-defined data models, by retrieving the formal descriptions
287from 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 
294with a priori knowledge of data types and actions. However, that would imply 
295that each consortium/organization will try to define their own data
296model. That would cause a major interoperability problem, possibly a completely
297intractable one  given the number of variations, extensions, compositions, or
298versioning 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
302device to allow for a runtime binding to a specific model, the objective being
303to require as little prior knowledge as possible.</t>
304
305<t>Moreover, gateways, bridges  and other similar devices need to dynamically
306translate (or map) one data model to another one. Complexity will increase 
307as there are also multiple protocols and schemas that make interoperability
308harder 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
315data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. 
316An example of such an approach has been shown with Hypermedia as the Engine of
317Application State (HATEOAS) <xref target="HATEOAS"/>.
318Another example is that all AllJoyn devices support such runtime discovery
319using a protocol mechanism called "introspection", where the metadata is 
320queried from the device itself <xref target="AllSeen"/>.</t>
321
322<t>There are various models, whether deployed or possible, for such discovery.
323The metadata might be extracted from a specification, looked up on a 
324cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's
325site, or obtained from the device itself (such as in the AllJoyn case).  The 
326relevant metadata might be obtained from the same place or different
327pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in 
328a 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
334single data model standard, there is no need for gateways that translate from one data model
335to another one. However, this is far from reality today, and there are many
336proprietary data models in addition to the already standardized ones. As a 
337consequence, 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
341translate between network layer protocols.  Eventually, IP took over, providing
342the necessary end-to-end interoperability at the network layer. Unfortunately,
343the introduction of gateways leads to the loss of expressiveness
344due to the translation between data models. The functionality of IP was so 
345valuable in the market that advanced features of other networking 
346protocols became less attractive and were not used anymore.</t>
347
348<t>Participants discussed an alternative that they called a "red star", shown
349in <xref target="red-star"/>, where data models are translated to a common
350data model shown in the middle. This 
351reduces the number of translations that are needed down to 2n (in the best case). 
352The 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 &quot;Red Star&quot; 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 
382such 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 
386offers 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
397Doctors that "YANG module" and "YANG data model" are preferred.
398We have updated the document accordingly.  Please review and let
399us know if further changes are necessary.
400
401-->
402<t>The participants also addressed the question of when translation should be done.
403Two use cases were discussed:
404<list style="format (%c)">
405<t>Design time: A translation between data model
406descriptions, such as translating a YANG module to a RAML/JSON model,
407can be performed once, during design time.
408A 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
411algorithmically done when the data model on one side is algorithmically derived
412from the data model on the other side.  This was called a "derived model".
413It was discussed that the availability of runtime discovery can aid in
414semantic translation, such as when a vendor-specific data model on one
415side of a protocol bridge is resolved and the translator can algorithmically 
416derive the semantically equivalent vendor-specific data model on the other
417side. This situation is discussed in <xref target="BridgeTaxonomy"/>.</t>
418</list></t>
419<t>The participants agreed that algorithm translation will generally require
420custom 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
423follow 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
429devices and server-side applications.
430Interactions between devices and services and how their relationship
431evolves 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
434developer might use a description of an API and implement 
435the protocol steps.  Sometimes, the data or information model can be used to generate code stubs.  Subsequent changes to an API
436require changes on the clients to upgrade to the new version, which
437requires some development of new code to satisfy the needs of the new
438API.</t>
439
440<t>These interactions could be made machine understandable in the first place,
441enabling for changes to happen at runtime.
442In that scenario, a machine client could discover the possible interactions with a
443service, adapting to changes as they occur without specific code
444being 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
447give meaning to the tags.</t>
448
449<t>These types of interactions are often based on the REST architectural
450style. Its principle is that a device or endpoint only needs a
451single entry point, with a host providing descriptions of the API
452in-band by means of web links and forms.</t>
453
454<t>By defining IoT-specific relation types, it is possible to drive
455interactions through links instead of hard-coding URIs into a RESTful
456client, thus making the system flexible enough for later changes.
457The definition of the basic hypermedia formats for IoT is still a work
458in progress. However, some of the existing mechanisms can be reused,
459such as resource discovery, forms, or links.</t>
460
461</section>
462
463<!--[rfced] FYI - we have added an IANA Considerations to match the
464guidance in RFC 8126 stating that no IANA actions are necessary.
465Please let us know any objections.  -->
466
467<section title="IANA Considerations">
468  <t>This document has no IANA actions.</t>
469</section>
470
471<section anchor="section-7" title="Security Considerations">
472
473<t>There were two types of security considerations discussed: use of formal data
474models for security configuration and security of data and data models in general.</t>
475
476<t>It was observed that the security assumptions and configuration, or "security model", varies by ecosystem today,
477making the job of a translator difficult.  For example, there are different types of security
478principals (e.g., user vs. device vs. application), the use of Access Control Lists (ACLs) versus capabilities,
479and what types of policies can be expressed, all vary by ecosystem.  As a result,
480the security model architecture generally dictates where translation can be done.</t>
481
482<t>One approach discussed was whether two endpoints might be able to use some overlay
483security model across a translator between two ecosystems, which only works if
484the two endpoints agree on a common data model for their communication.  Another approach
485discussed was simply having a translator act as a trusted intermediary, which enables
486the translator to translate between different data models.</t>
487
488<t>One suggestion discussed was either adding metadata into the
489formal data model language or having it accompany the data values over the wire, tagging
490the data with privacy levels.  However, sometimes even the privacy level of information
491might itself be sensitive.  Still, it was observed that being able to dynamically
492learn security requirements might help provide better UIs and translators.</t>
493
494</section>
495<section anchor="section-8" title="Collaboration">
496
497<t>The participants discussed how best to share information among their various organizations.
498One discussion was around having joint meetings. One current challenge reported was that
499organizations were not aware of when and where each other's meetings were scheduled,
500and sharing such information could help organizations better collocate meetings.
501To facilitate this exchange, the participants agreed to add links to their respective
502meeting schedules from a common page in the IOTSI repository <xref target="IOTSIGIT"/>.</t>
503
504<t>Another challenge reported was that organizations did not know how to find each other's
505published data models, and sharing such information could better facilitate reuse of the
506same information model.  To facilitate this exchange, the participants discussed whether
507a common repository might be used by multiple organizations.  The OCF's oneIoTa repository
508was discussed as one possibility, but it was reported that its terms of use at the time
509of the workshop prevented this.  The OCF agreed to take this back and look at updating
510the terms of use to allow other organizations to use it, as the restriction was not
511the intent.  &lt;schema.org&gt; was discussed as another possibility.  In the meantime, the
512participants agreed to add links to their respective repositories from a common page in
513the IOTSI repository <xref target="IOTSIGIT"/>.</t>
514
515<t>It was also agreed that the iotsi@iab.org mailing list would remain open and available
516for sharing information between all relevant organizations.</t>
517
518</section>
519
520
521  </middle>
522
523  <back>
524
525
526    <references title='Informative References'>
527
528<?rfc include="reference.RFC.3444" ?>
529
530
531
532<reference anchor="AllSeen-Plugin">
533  <front>
534    <title>Using the AllJoyn Studio Extension</title>
535    <author initials="B." surname="Rockwell" fullname="B. Rockwell">
536      <organization></organization>
537    </author>
538    <date year="2015" month="August" day="17"/>
539  </front>
540</reference>
541
542<reference anchor="HATEOAS" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf">
543  <front>
544    <title>Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things</title>
545    <author initials="M." surname="Kovatsch" fullname="M. Kovatsch">
546      <organization></organization>
547    </author>
548    <author initials="Y.N." surname="Hassan">
549      <organization></organization>
550    </author>
551    <author initials="K." surname="Hartke">
552      <organization></organization>
553    </author>
554    <date />
555  </front>
556  <seriesInfo name="Proceedings of the IAB IoT Semantic Interoperability Workshop" value="2016"/>
557</reference>
558
559<reference anchor="AllSeen" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf">
560  <front>
561    <title>Summary of AllSeen Alliance Work Relevant to Semantic Interoperability</title>
562    <author initials="D." surname="Thaler" fullname="D. Thaler">
563      <organization></organization>
564    </author>
565    <date year="2016"/>
566  </front>
567</reference>
568
569<reference anchor="BridgeTaxonomy" target="https://www.iab.org/wp-content/IAB-uploads/2016/03/DThaler-IOTSI.pdf">
570  <front>
571    <title>IoT Bridge Taxonomy</title>
572    <author initials="D." surname="Thaler" fullname="D. Thaler">
573      <organization></organization>
574    </author>
575    <date />
576  </front>
577<seriesInfo name="IAB IOTSI Workshop" value="2016" />
578</reference>
579
580<reference anchor="IOTSIAG" target="https://www.iab.org/activities/workshops/iotsi/agenda/">
581  <front>
582    <title>IoT Semantic Interoperability Workshop Agenda</title>
583    <author >
584      <organization>IAB</organization>
585    </author>
586    <date year="2016"/>
587  </front>
588</reference>
589
590<!--[rfced] Please review our updates to the [IOTSIGIT] and [PYANG]
591reference entries in compliance with
592https://www.rfc-editor.org/styleguide/part2/ and let us know any
593objections. -->
594
595<reference anchor="IOTSIGIT" target="https://github.com/iotsi/iotsi">
596  <front>
597    <title>Starting place for the IoT Semantic Interoperability Workshop
598    (IOTSI) Information Resource</title>
599    <author >
600      <organization></organization>
601    </author>
602    <date year="2018" month="July"/>
603  </front>
604<seriesInfo name='commit' value="ff21f74"/>
605</reference>
606
607<reference anchor="IOTSIWS" target="https://www.iab.org/activities/workshops/iotsi/">
608  <front>
609    <title>IoT Semantic Interoperability Workshop 2016</title>
610    <author >
611      <organization>IAB</organization>
612    </author>
613    <date year="2016"/>
614  </front>
615</reference>
616
617<reference anchor="LWM2M-Schema" >
618  <front>
619    <title>LWM2M XML Schema - LWM2M Editor Schema</title>
620    <author >
621      <organization>OMA</organization>
622    </author>
623    <date year="2018" month="July"/>
624  </front>
625</reference>
626
627<reference anchor="OMNA">
628  <front>
629    <title>OMA LightweightM2M (LwM2M) Object and Resource Registry</title>
630    <author >
631      <organization>OMA</organization>
632    </author>
633    <date />
634  </front>
635</reference>
636
637<reference anchor="SIG" target="https://www.bluetooth.com/specifications/gatt">
638  <front>
639    <title>GATT Specifications</title>
640    <author >
641      <organization>Bluetooth SIG</organization>
642    </author>
643    <date />
644  </front>
645</reference>
646
647<reference anchor="PYANG" target="https://github.com/mbj4668/pyang">
648  <front>
649    <title>An extensible YANG validator and converter in python</title>
650    <author>
651      <organization></organization>
652    </author>
653    <date year="2018" month="September" day="13"/>
654  </front>
655<seriesInfo name="commit" value="15c807f" />
656</reference>
657
658<reference anchor="nRF-Sniffer">
659  <front>
660    <title>nRF Sniffer: Smart/Bluetooth low energy packet sniffer</title>
661    <author >
662      <organization>Nordic Semiconductor</organization>
663    </author>
664    <date />
665  </front>
666</reference>
667
668<reference anchor="AllJoynExplorer">
669  <front>
670    <title>AllJoyn</title>
671    <author >
672      <organization>Microsoft</organization>
673    </author>
674    <date />
675  </front>
676</reference>
677
678<reference anchor="OpenDOF" target="https://opendof.org">
679  <front>
680    <title>The OpenDOF Project</title>
681    <author >
682      <organization>OpenDOF</organization>
683    </author>
684    <date />
685  </front>
686</reference>
687
688
689</references>
690
691
692<section title="Program Committee" >
693
694<t>This workshop was organized by the following individuals: Jari Arkko,
695Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
696Tschofenig.</t>
697
698</section>
699<section title="Accepted Position Papers">
700
701<!--[rfced] FYI, we standardized the capitalization of the paper
702titles from the workshop. Please let us know if that creates any
703problems.  -->
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>
723  <t>Michael Koster, "Model-Based Hypertext Language"</t>
724  <t>Matthias Kovatsch, Yassin N.  Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models"</t>
725  <t>Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things"</t>
726  <t>Barry Leiba, "Position Paper"</t>
727  <t>Marcello Lioy, "AllJoyn"</t>
728  <t>Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema"</t>
729  <t>Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues"</t>
730  <t>Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things"</t>
731  <t>Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti"</t>
732  <t>Joaquin Prado, "OMA Lightweight M2M Resource Model"</t>
733  <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
824contributions and Ericsson for hosting the workshop.</t>
825
826</section>
827
828
829  </back>
830
831
832</rfc>
833
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC3444' target='https://www.rfc-editor.org/info/rfc3444'>
4<front>
5<title>On the Difference between Information Models and Data Models</title>
6<author initials='A.' surname='Pras' fullname='A. Pras'><organization /></author>
7<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organization /></author>
8<date year='2003' month='January' />
9<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>
10</front>
11<seriesInfo name='RFC' value='3444'/>
12<seriesInfo name='DOI' value='10.17487/RFC3444'/>
13</reference>

mirror server hosted at Truenetwork, Russian Federation.