| 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 Interoperability (IOTSI) Workshop 2016</title> |
| 19 | |
| 20 | |
| 21 | |
| 22 | <!--[rfced] *RJS or Stream Manager - please review and approve the |
| 23 | split of the boilerplate paragraph in the Intro. |
| 24 | |
| 25 | As it appears at https://www.rfc-editor.org/materials/iab-format.txt: |
| 26 | |
| 27 | The following boilerplate paragraph SHOULD appear in the introduction: |
| 28 | |
| 29 | The Internet Architecture Board (IAB) holds occasional workshops |
| 30 | designed to consider long-term issues and strategies for the |
| 31 | Internet, and to suggest future directions for the Internet |
| 32 | architecture. This long-term planning function of the IAB is |
| 33 | complementary to the ongoing engineering efforts performed by working |
| 34 | groups of the Internet Engineering Task Force (IETF). |
| 35 | |
| 36 | How it appears in this document: |
| 37 | |
| 38 | |
| 39 | The Internet Architecture Board (IAB) holds occasional workshops |
| 40 | designed to consider long-term issues and strategies for the |
| 41 | Internet, and to suggest future directions for the Internet |
| 42 | architecture. The investigated topics often require coordinated |
| 43 | efforts of many organizations and industry bodies to improve an |
| 44 | identified problem. One of the targets of the workshops is to |
| 45 | establish communication between relevant organizations, especially |
| 46 | when the topics are out of the scope for the Internet Engineering |
| 47 | Task Force (IETF). This long-term planning function of the IAB is |
| 48 | complementary to the ongoing engineering efforts performed by working |
| 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 |
| 75 | the title) for use on https://www.rfc-editor.org/search. |
| 76 | --> |
| 77 | |
| 78 | <keyword>example</keyword> |
| 79 | |
| 80 | |
| 81 | <abstract> |
| 82 | |
| 83 | <t>This document provides a summary of the "Workshop on Internet of |
| 84 | Things (IoT) Semantic Interoperability (IOTSI)", |
| 85 | which took place in Santa Clara, California March 17-18, 2016. The main |
| 86 | goal of the workshop was to foster a discussion on the different |
| 87 | approaches used by companies and Standards Developing Organizations (SDOs) |
| 88 | to accomplish interoperability at the application layer. This report |
| 89 | summarizes the discussions and lists recommendations to the standards |
| 90 | community. The views and positions in this report are those of the |
| 91 | workshop participants and do not necessarily reflect those of the |
| 92 | authors or the Internet Architecture Board (IAB), which organized |
| 93 | the workshop. |
| 94 | <!--begin DNE text --> |
| 95 | Note that this document is a report on the proceedings of the |
| 96 | workshop. The views and positions documented in this report are |
| 97 | those of the workshop participants and do not necessarily reflect IAB |
| 98 | views and positions. |
| 99 | |
| 100 | <!--end DNE text --> |
| 101 | </t> |
| 102 | |
| 103 | </abstract> |
| 104 | |
| 105 | |
| 106 | </front> |
| 107 | |
| 108 | <middle> |
| 109 | |
| 110 | |
| 111 | <section anchor="section-1" title="Introduction"> |
| 112 | |
| 113 | <!--Begin DNE text --> |
| 114 | <t>The Internet Architecture Board (IAB) holds occasional workshops |
| 115 | designed to consider long-term issues and strategies for the |
| 116 | Internet, and to suggest future directions for the Internet |
| 117 | architecture. |
| 118 | <!--End DNE text --> |
| 119 | The investigated topics often require coordinated |
| 120 | efforts from many organizations and industry bodies to improve an |
| 121 | identified problem. One of the targets of the workshops is to |
| 122 | establish communication between relevant organizations, especially |
| 123 | when the topics are out of the scope of the Internet Engineering |
| 124 | Task Force (IETF). |
| 125 | <!--Begin DNE text --> |
| 126 | This long-term planning function of the IAB is |
| 127 | complementary to the ongoing engineering efforts performed by working |
| 128 | groups of the IETF. |
| 129 | <!--End DNE text --> |
| 130 | </t> |
| 131 | |
| 132 | <t>With the expansion of the Internet of Things (IoT), interoperability |
| 133 | becomes more and more important. Standards Developing Organizations (SDOs) |
| 134 | have done a tremendous amount of work to standardize new protocols |
| 135 | and profile existing protocols.</t> |
| 136 | |
| 137 | <t>At the application layer and at the level of solution frameworks, |
| 138 | interoperability is not yet mature. Particularly, the |
| 139 | work on data formats (in the form of data models and information |
| 140 | models) has not seen the same level of consistency throughout |
| 141 | SDOs.</t> |
| 142 | |
| 143 | <t>One common problem is the lack of an encoding-independent standardization |
| 144 | of the information, the so-called information model. Another problem is |
| 145 | the strong relationship between data formats and the underlying communication architecture, |
| 146 | such as a design in Remote Procedure Call (RPC) style or a RESTful design (where REST refers to Representational State Transfer). Furthermore, groups develop solutions that are very similar on the surface but differ slightly in their standardized outcome, leading to interoperability |
| 147 | problems. Finally, some groups favor different encodings for use with |
| 148 | various application-layer protocols.</t> |
| 149 | |
| 150 | <t>Thus, the IAB decided to organize a workshop to reach out to relevant |
| 151 | stakeholders to explore the state of the art and identify |
| 152 | commonality and gaps <xref target="IOTSIAG"/><xref target="IOTSIWS"/>. In particular, the IAB was |
| 153 | interested to learn about the following aspects:</t> |
| 154 | |
| 155 | <t><list style="symbols"> |
| 156 | <t>What is the state of the art in data and information models? What should |
| 157 | an information model look like?</t> |
| 158 | <t>What is the role of formal languages, such as schema languages, in |
| 159 | describing information and data models?</t> |
| 160 | <t>What is the role of metadata, which is attached to data to make it self-describing?</t> |
| 161 | <t>How can we achieve interoperability when different organizations, companies, |
| 162 | and individuals develop extensions?</t> |
| 163 | <t>What is the experience with interworking various data models developed |
| 164 | from different groups, or with data models that evolved over time?</t> |
| 165 | <t>What functionality should online repositories for sharing schemas have?</t> |
| 166 | <t>How can existing data models be mapped against each other to offer interworking?</t> |
| 167 | <t>Is there room for harmonization, or are the use cases of different groups |
| 168 | and organizations so unique that there is no possibility for cooperation?</t> |
| 169 | <t>How can organizations better work together to increase awareness and information sharing?</t> |
| 170 | </list></t> |
| 171 | |
| 172 | </section> |
| 173 | <section anchor="section-2" title="Terminology"> |
| 174 | |
| 175 | <t>The first roadblock to interoperability at the level of data models is the lack of a |
| 176 | common vocabulary to start the discussion. |
| 177 | <xref target="RFC3444"/> provides a starting point by separating conceptual models for designers, |
| 178 | or "information models", from concrete detailed definitions for implementers, or |
| 179 | "data models". There are concepts that are |
| 180 | undefined in that RFC and elsewhere, such as the interaction with the |
| 181 | resources of an endpoint, or "interaction model". Therefore, the three |
| 182 | "main" common models that were identified were:</t> |
| 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 |
| 187 | expresses the desired functionality. |
| 188 | Information models can be defined informally (e.g., in prose) or more |
| 189 | formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.). |
| 190 | Implementation details are hidden.</t> |
| 191 | </list></t> |
| 192 | |
| 193 | <t><list style="hanging" hangIndent="3"> |
| 194 | <t hangText='Data Model'><vspace blankLines='0'/> |
| 195 | |
| 196 | |
| 197 | A data model defines concrete data representations at a lower level of |
| 198 | abstraction, including implementation- and protocol-specific details. |
| 199 | Some examples are SNMP Management Information Base (MIB) modules, World Wide |
| 200 | Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.</t> |
| 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, |
| 206 | being, therefore, tied to the specific |
| 207 | communication pattern that the system has (e.g., REST methods, |
| 208 | Publish/Subscribe operations, or RPC calls).</t> |
| 209 | </list></t> |
| 210 | |
| 211 | <t>Another identified terminology issue is the semantic meaning overload |
| 212 | that some terms have. The meaning can vary depending on the context in which the |
| 213 | term is used. Some examples of such terms are as follows: semantics, models, |
| 214 | encoding, serialization format, media types, and encoding types. Due |
| 215 | to time constraints, no concrete terminology was agreed upon, but |
| 216 | work will continue within each organization to create various |
| 217 | terminology documents. The participants agreed to set up a GitHub repository |
| 218 | <xref target="IOTSIGIT"/> for sharing information.</t> |
| 219 | |
| 220 | </section> |
| 221 | <section anchor="section-4" title="What Problems to Solve"> |
| 222 | |
| 223 | <t>The participants agreed that there is not simply a single problem to be solved but |
| 224 | rather a range of problems. During the workshop, the following problems were discussed:</t> |
| 225 | |
| 226 | <t><list style="symbols"> |
| 227 | <t>Formal Languages for Documentation Purposes</t> |
| 228 | </list></t> |
| 229 | |
| 230 | <t>To simplify review and publication, SDOs need |
| 231 | formal descriptions of their data and interaction models. |
| 232 | Several of them use a tabular representation found in the specification itself |
| 233 | but use a formal language as an alternative way of describing objects and resources |
| 234 | for formal purposes. Some examples of formal language use are as follows.</t> |
| 235 | |
| 236 | <t>The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema <xref |
| 237 | target="LWM2M-Schema"/> to describe their object and resource definitions. The |
| 238 | XML files of standardized objects are available for download at |
| 239 | <xref target="OMNA"/>.</t> |
| 240 | |
| 241 | <t>The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with |
| 242 | Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on |
| 243 | the Bluetooth SIG website <xref target="SIG"/> and are defined as XML instance documents.</t> |
| 244 | |
| 245 | <t>The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define |
| 246 | data models and RESTful API Modeling Language (RAML) to define interaction models. The standard files are |
| 247 | available online at <oneIoTa.org>.</t> |
| 248 | |
| 249 | <t>The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction |
| 250 | models in the same formal language, tailored for RPC-style interaction. The standard |
| 251 | files are available online on the AllSeen Alliance website, but both standard and |
| 252 | vendor-defined model files can be obtained by directly querying a device for them at runtime.</t> |
| 253 | |
| 254 | <t>The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) |
| 255 | to define data and interaction models using a format tailored for the web.</t> |
| 256 | |
| 257 | <t>The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. |
| 258 | Other SDOs may use various other formats.</t> |
| 259 | |
| 260 | <t><list style="symbols"> |
| 261 | <t>Formal Languages for Code Generation</t> |
| 262 | </list></t> |
| 263 | |
| 264 | <t>Code-generation tools that use formal data and information modeling languages |
| 265 | are needed by developers. For example, the AllSeen Visual Studio |
| 266 | Plugin <xref target="AllSeen-Plugin"/> offers a wizard to generate code based on |
| 267 | the formal description of the data model. Another example of a data |
| 268 | modeling language that can be used for code generation is YANG. A |
| 269 | popular tool to help with code generation of YANG modules is pyang <xref target="PYANG"/>. |
| 270 | An example of a tool that can generate code for multiple ecosystems is |
| 271 | OpenDOF <xref target="OpenDOF"/>. Use cases discussed for code generation included easing |
| 272 | development of server-side device functionality, clients, and compliance tests.</t> |
| 273 | |
| 274 | |
| 275 | <t><list style="symbols"> |
| 276 | <t>Debugging Support</t> |
| 277 | </list></t> |
| 278 | |
| 279 | <t>Debugging tools are needed that implement generic object browsers, which |
| 280 | use standard data models and/or retrieve formal language descriptions |
| 281 | from the devices themselves. As one example, the |
| 282 | nRF Bluetooth Smart sniffer from Nordic Semiconductor <xref target="nRF-Sniffer"/> can be |
| 283 | used to display services and characteristics defined by the Bluetooth SIG. |
| 284 | As another example, AllJoyn Explorer <xref target="AllJoynExplorer"/> can be used to browse |
| 285 | and interact with any resource exposed by an AllJoyn device, including both |
| 286 | standard and vendor-defined data models, by retrieving the formal descriptions |
| 287 | from the device at runtime.</t> |
| 288 | |
| 289 | <t><list style="symbols"> |
| 290 | <t>Translation</t> |
| 291 | </list></t> |
| 292 | |
| 293 | <t>The working assumption is that devices need to have a common data model |
| 294 | with a priori knowledge of data types and actions. However, that would imply |
| 295 | that each consortium/organization will try to define their own data |
| 296 | model. That would cause a major interoperability problem, possibly a completely |
| 297 | intractable one given the number of variations, extensions, compositions, or |
| 298 | versioning changes that will happen for each data model.</t> |
| 299 | |
| 300 | |
| 301 | <t>Another potential approach is to have a minimal amount of information on the |
| 302 | device to allow for a runtime binding to a specific model, the objective being |
| 303 | to require as little prior knowledge as possible.</t> |
| 304 | |
| 305 | <t>Moreover, gateways, bridges and other similar devices need to dynamically |
| 306 | translate (or map) one data model to another one. Complexity will increase |
| 307 | as there are also multiple protocols and schemas that make interoperability |
| 308 | harder to achieve.</t> |
| 309 | |
| 310 | <t><list style="symbols"> |
| 311 | <t>Runtime Discovery</t> |
| 312 | </list></t> |
| 313 | |
| 314 | <t>Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the |
| 315 | data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. |
| 316 | An example of such an approach has been shown with Hypermedia as the Engine of |
| 317 | Application State (HATEOAS) <xref target="HATEOAS"/>. |
| 318 | Another example is that all AllJoyn devices support such runtime discovery |
| 319 | using a protocol mechanism called "introspection", where the metadata is |
| 320 | queried from the device itself <xref target="AllSeen"/>.</t> |
| 321 | |
| 322 | <t>There are various models, whether deployed or possible, for such discovery. |
| 323 | The metadata might be extracted from a specification, looked up on a |
| 324 | cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's |
| 325 | site, or obtained from the device itself (such as in the AllJoyn case). The |
| 326 | relevant metadata might be obtained from the same place or different |
| 327 | pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in |
| 328 | a desired language, and (c) developer-specific comments for implementers.</t> |
| 329 | |
| 330 | </section> |
| 331 | <section anchor="section-5" title="Translation"> |
| 332 | |
| 333 | <t>In an ideal world where organizations and companies cooperate and agree on a |
| 334 | single data model standard, there is no need for gateways that translate from one data model |
| 335 | to another one. However, this is far from reality today, and there are many |
| 336 | proprietary data models in addition to the already standardized ones. As a |
| 337 | consequence, gateways are needed to translate between data models. This leads to |
| 338 | (n^2)-n combinations, in the worst case.</t> |
| 339 | |
| 340 | <t>There are analogies with gateways back in the 1980s that were used to |
| 341 | translate between network layer protocols. Eventually, IP took over, providing |
| 342 | the necessary end-to-end interoperability at the network layer. Unfortunately, |
| 343 | the introduction of gateways leads to the loss of expressiveness |
| 344 | due to the translation between data models. The functionality of IP was so |
| 345 | valuable in the market that advanced features of other networking |
| 346 | protocols became less attractive and were not used anymore.</t> |
| 347 | |
| 348 | <t>Participants discussed an alternative that they called a "red star", shown |
| 349 | in <xref target="red-star"/>, where data models are translated to a common |
| 350 | data model shown in the middle. This |
| 351 | reduces the number of translations that are needed down to 2n (in the best case). |
| 352 | The problem, of course, is that everyone wants their own data model to be the red star in the center.</t> |
| 353 | |
| 354 | <figure title="The "Red Star" in Data/Information Models" anchor="red-star"><artwork><![CDATA[ |
| 355 | +-----+ +-----+ |
| 356 | | | | | |
| 357 | | | -- -- | | |
| 358 | | | -- -- | | |
| 359 | +-----+ -- -- +-----+ |
| 360 | -- --- |
| 361 | -- -- |
| 362 | -- -- |
| 363 | -- -- |
| 364 | --- -- A -- --- |
| 365 | / \ ___/ \___ / \ |
| 366 | | | ---------------', .'--------------- | | |
| 367 | \ / /. ^ .\ \ / |
| 368 | --- /' '\ --- |
| 369 | -- -- |
| 370 | -- -- |
| 371 | -- -- |
| 372 | -- -- |
| 373 | -- -- |
| 374 | /\ -- -- /\ |
| 375 | / \ -- -- / \ |
| 376 | / \ / \ |
| 377 | / \ / \ |
| 378 | /--------\ /--------\ |
| 379 | ]]></artwork></figure> |
| 380 | |
| 381 | <t>While the workshop itself was not a suitable forum to discuss the design of |
| 382 | such translation in detail, several questions were raised:</t> |
| 383 | |
| 384 | <t><list style="symbols"> |
| 385 | <t>Do we need a "red star" that does everything, or could we design something that |
| 386 | offers a more restricted functionality?</t> |
| 387 | <t>How do we handle loss of data and functionality?</t> |
| 388 | <t>Should data be translated between data models, or should data models themselves be translated?</t> |
| 389 | <t>How can interaction models be translated? They need to be dealt with in addition |
| 390 | to the data models.</t> |
| 391 | <t>Many (if not all) data and interaction models have some bizarre functionality |
| 392 | that cannot be translated easily. How can those be handled?</t> |
| 393 | <t>What limitations are we going to accept in these translations?</t> |
| 394 | </list></t> |
| 395 | |
| 396 | <!--[rfced] We recently received guidance from Benoit and the YANG |
| 397 | Doctors that "YANG module" and "YANG data model" are preferred. |
| 398 | We have updated the document accordingly. Please review and let |
| 399 | us know if further changes are necessary. |
| 400 | |
| 401 | --> |
| 402 | <t>The participants also addressed the question of when translation should be done. |
| 403 | Two use cases were discussed: |
| 404 | <list style="format (%c)"> |
| 405 | <t>Design time: A translation between data model |
| 406 | descriptions, such as translating a YANG module to a RAML/JSON model, |
| 407 | can be performed once, during design time. |
| 408 | A single information model might be mapped to a number of different data models.</t> |
| 409 | |
| 410 | <t>Run time: Runtime translation of values in two standard data models can only be |
| 411 | algorithmically done when the data model on one side is algorithmically derived |
| 412 | from the data model on the other side. This was called a "derived model". |
| 413 | It was discussed that the availability of runtime discovery can aid in |
| 414 | semantic translation, such as when a vendor-specific data model on one |
| 415 | side of a protocol bridge is resolved and the translator can algorithmically |
| 416 | derive the semantically equivalent vendor-specific data model on the other |
| 417 | side. This situation is discussed in <xref target="BridgeTaxonomy"/>.</t> |
| 418 | </list></t> |
| 419 | <t>The participants agreed that algorithm translation will generally require |
| 420 | custom code whenever one is translating to anything other than a derived model.</t> |
| 421 | |
| 422 | <t>Participants concluded that it is typically easier to translate data between systems that |
| 423 | follow the same communication architecture.</t> |
| 424 | |
| 425 | </section> |
| 426 | <section anchor="section-6" title="Dealing with Change"> |
| 427 | |
| 428 | <t>A large part of the workshop was dedicated to the evolution of |
| 429 | devices and server-side applications. |
| 430 | Interactions between devices and services and how their relationship |
| 431 | evolves over time is complicated by their respective interaction models.</t> |
| 432 | |
| 433 | <t>The workshop participants discussed various approaches to deal with change. In the most basic case, a |
| 434 | developer might use a description of an API and implement |
| 435 | the protocol steps. Sometimes, the data or information model can be used to generate code stubs. Subsequent changes to an API |
| 436 | require changes on the clients to upgrade to the new version, which |
| 437 | requires some development of new code to satisfy the needs of the new |
| 438 | API.</t> |
| 439 | |
| 440 | <t>These interactions could be made machine understandable in the first place, |
| 441 | enabling for changes to happen at runtime. |
| 442 | In that scenario, a machine client could discover the possible interactions with a |
| 443 | service, adapting to changes as they occur without specific code |
| 444 | being developed to adapt to them.</t> |
| 445 | |
| 446 | <t>The challenge seems to be to code the human-readable specification into a machine-readable format. Machine-readable languages require a shared vocabulary to |
| 447 | give meaning to the tags.</t> |
| 448 | |
| 449 | <t>These types of interactions are often based on the REST architectural |
| 450 | style. Its principle is that a device or endpoint only needs a |
| 451 | single entry point, with a host providing descriptions of the API |
| 452 | in-band by means of web links and forms.</t> |
| 453 | |
| 454 | <t>By defining IoT-specific relation types, it is possible to drive |
| 455 | interactions through links instead of hard-coding URIs into a RESTful |
| 456 | client, thus making the system flexible enough for later changes. |
| 457 | The definition of the basic hypermedia formats for IoT is still a work |
| 458 | in progress. However, some of the existing mechanisms can be reused, |
| 459 | such as resource discovery, forms, or links.</t> |
| 460 | |
| 461 | </section> |
| 462 | |
| 463 | <!--[rfced] FYI - we have added an IANA Considerations to match the |
| 464 | guidance in RFC 8126 stating that no IANA actions are necessary. |
| 465 | Please 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 |
| 474 | models 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, |
| 477 | making the job of a translator difficult. For example, there are different types of security |
| 478 | principals (e.g., user vs. device vs. application), the use of Access Control Lists (ACLs) versus capabilities, |
| 479 | and what types of policies can be expressed, all vary by ecosystem. As a result, |
| 480 | the 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 |
| 483 | security model across a translator between two ecosystems, which only works if |
| 484 | the two endpoints agree on a common data model for their communication. Another approach |
| 485 | discussed was simply having a translator act as a trusted intermediary, which enables |
| 486 | the translator to translate between different data models.</t> |
| 487 | |
| 488 | <t>One suggestion discussed was either adding metadata into the |
| 489 | formal data model language or having it accompany the data values over the wire, tagging |
| 490 | the data with privacy levels. However, sometimes even the privacy level of information |
| 491 | might itself be sensitive. Still, it was observed that being able to dynamically |
| 492 | learn 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. |
| 498 | One discussion was around having joint meetings. One current challenge reported was that |
| 499 | organizations were not aware of when and where each other's meetings were scheduled, |
| 500 | and sharing such information could help organizations better collocate meetings. |
| 501 | To facilitate this exchange, the participants agreed to add links to their respective |
| 502 | meeting 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 |
| 505 | published data models, and sharing such information could better facilitate reuse of the |
| 506 | same information model. To facilitate this exchange, the participants discussed whether |
| 507 | a common repository might be used by multiple organizations. The OCF's oneIoTa repository |
| 508 | was discussed as one possibility, but it was reported that its terms of use at the time |
| 509 | of the workshop prevented this. The OCF agreed to take this back and look at updating |
| 510 | the terms of use to allow other organizations to use it, as the restriction was not |
| 511 | the intent. <schema.org> was discussed as another possibility. In the meantime, the |
| 512 | participants agreed to add links to their respective repositories from a common page in |
| 513 | the 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 |
| 516 | for 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] |
| 591 | reference entries in compliance with |
| 592 | https://www.rfc-editor.org/styleguide/part2/ and let us know any |
| 593 | objections. --> |
| 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, |
| 695 | Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes |
| 696 | Tschofenig.</t> |
| 697 | |
| 698 | </section> |
| 699 | <section title="Accepted Position Papers"> |
| 700 | |
| 701 | <!--[rfced] FYI, we standardized the capitalization of the paper |
| 702 | titles from the workshop. Please let us know if that creates any |
| 703 | problems. --> |
| 704 | |
| 705 | <t><list style="symbols"> |
| 706 | <t>Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"</t> |
| 707 | <t>Carsten Bormann, "Noise in Specifications hurts"</t> |
| 708 | <t>Benoit Claise, "YANG as the Data Modelling Language in the IoT space"</t> |
| 709 | <t>Robert Cragie, "The ZigBee Cluster Library over IP"</t> |
| 710 | <t>Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"</t> |
| 711 | <t>Universal Devices, "Object Oriented Approach to IoT Interoperability"</t> |
| 712 | <t>Bryant Eastham, "Interoperability and the OpenDOF Project"</t> |
| 713 | <t>Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"</t> |
| 714 | <t>Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"</t> |
| 715 | <t>Ted Hardie, "Loci of Interoperability for the Internet of Things"</t> |
| 716 | <t>Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"</t> |
| 717 | <t>Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"</t> |
| 718 | <t>David Jones, "IOTDB - interoperability Through Semantic Metastandards"</t> |
| 719 | <t>Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"</t> |
| 720 | <t>Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"</t> |
| 721 | <t>Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"</t> |
| 722 | <t>Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"</t> |
| 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 |
| 824 | contributions and Ericsson for hosting the workshop.</t> |
| 825 | |
| 826 | </section> |
| 827 | |
| 828 | |
| 829 | </back> |
| 830 | |
| 831 | |
| 832 | </rfc> |
| 833 | |