idnits 2.17.1 draft-iab-iotsi-workshop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jimenez 3 Internet-Draft Ericsson 4 Intended status: Informational H. Tschofenig 5 Expires: January 3, 2019 Arm Ltd. 6 D. Thaler 7 Microsoft 8 July 02, 2018 10 Report from the Internet of Things (IoT) Semantic Interoperability 11 (IOTSI) Workshop 2016 12 draft-iab-iotsi-workshop-02 14 Abstract 16 This document provides a summary of the 'Workshop on Internet of 17 Things (IoT) Semantic Interoperability (IOTSI)', which took place in 18 Santa Clara, California, on March 17-18, 2016. The main goal of the 19 workshop was to foster a discussion on the different approaches used 20 by companies and Standards Developing Organizations (SDOs) to 21 accomplish interoperability at the application layer. This report 22 summarizes the discussions, and lists recommendations to the 23 standards community. The views and positions in this report are 24 those of the workshop participants and do not necessarily reflect 25 those of the authors and the Internet Architecture Board (IAB), which 26 organized the workshop. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 3, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 4 65 4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Dealing with change . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Appendix A: Program Committee . . . . . . . . . . . . . . . . 11 71 10. Appendix B: Accepted Position Papers . . . . . . . . . . . . 11 72 11. Appendix C: List of Participants . . . . . . . . . . . . . . 14 73 12. Informative References . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The Internet Architecture Board (IAB) holds occasional workshops 79 designed to consider long-term issues and strategies for the 80 Internet, and to suggest future directions for the Internet 81 architecture. The investigated topics often require coordinated 82 efforts of many organizations and industry bodies to improve an 83 identified problem. One of the targets of the workshops is to 84 establish communication between relevant organizations, especially 85 when the topics are out of the scope for the Internet Engineering 86 Task Force (IETF). This long-term planning function of the IAB is 87 complementary to the ongoing engineering efforts performed by working 88 groups of the IETF. 90 With the expansion of the Internet of Things (IoT), interoperability 91 becomes more and more important. Standards Developing Organizations 92 (SDOs) have done a tremendous amount of work to standardize new 93 protocols, and to profile existing protocols. 95 At the application layer and at the level of solution frameworks, 96 interoperability is not yet mature. Particularly, the work on data 97 formats (in the form of data models and information models) has not 98 seen the same level of consistency throughout SDOs. 100 One common problem is the lack of an encoding-independent 101 standardization of the information, the so-called information model. 102 Another problem is the strong relationship with the underlying 103 communication architecture, such as a Remote Procedure Call (RPC) 104 style design or a RESTful design. Furthermore, groups develop 105 solutions that are very similar on the surface but differ slightly in 106 their standardized outcome, leading to interoperability problems. 107 Finally, some groups favor different encodings for use with various 108 application layer protocols. 110 Thus, the IAB decided to organize a workshop to reach out to relevant 111 stakeholders to explore the state-of-the-art and to identify 112 commonality and gaps [IOTSIAG][IOTSIWS]. In particular, the IAB was 113 interested to learn about the following aspects: 115 o What is the state of the art in data and information models? What 116 should an information model look like? 118 o What is the role of formal languages, such as schema languages, in 119 describing information and data models? 121 o What is the role of metadata, which is attached to data to make it 122 self-describing? 124 o How can we achieve interoperability when different organizations, 125 companies and individuals develop extensions? 127 o What is the experience with interworking various data models 128 developed from different groups, or with data models that evolved 129 over time? 131 o What functionality should online repositories for sharing schemas 132 have? 134 o How can existing data models be mapped against each other to offer 135 interworking? 137 o Is there room for harmonization, or are the use cases of different 138 groups and organizations so unique that there is no possibility 139 for cooperation? 141 o How can organizations better work together to increase awareness 142 and information sharing? 144 2. Terminology 146 The first roadblock to interoperability at the level of data models 147 is the lack of a common vocabulary to start the discussion. 148 [RFC3444] provides a starting point by separating conceptual models 149 for designers, or "information models", from concrete detailed 150 definitions for implementers, or "data models". There are concepts 151 that are undefined in that RFC and elsewhere, such as the interaction 152 with the resources of an endpoint, or "interaction model". Therefore 153 the three "main" common models that were identified were: 155 Information Model 156 An information model defines an environment at the highest level 157 of abstraction and expresses the desired functionality. 158 Information models can be defined informally (e.g., in plain 159 English) or more formally (e.g., UML, Entity-Relationship 160 Diagrams, etc.). Implementation details are hidden. 162 Data Model 163 A data model defines concrete data representations at a lower 164 level of abstraction, including implementation and protocol- 165 specific details. Some examples are: SNMP Management Information 166 Base (MIB) modules, W3C Thing Description (TD) Things, YANG 167 models, LWM2M Schemas, OCF Schemas, and so on. 169 Interaction Model 170 An interaction model defines how data is accessed and retrieved 171 from the endpoints, being therefore tied to the specific 172 communication pattern that the system has (e.g., REST methods, 173 Publish/Subscribe operations, or RPC calls). 175 Another identified terminology issue is the semantic meaning overload 176 that some terms have. The meaning can vary depending on the context 177 in which the term is used. Some examples of such terms are: 178 semantics, models, encoding, serialization format, media types or 179 encoding types. Due to time constraints, no concrete terminology was 180 agreed upon, but work will continue within each organization to 181 create various terminology documents. The participants agreed to set 182 up a github repository [IOTSIGIT] for sharing information. 184 3. What Problems to Solve 186 The participants agreed that there is not simply a single problem to 187 be solved, but rather a range. During the workshop the following 188 problems were discussed: 190 o Formal Languages for Documentation Purposes 192 To simplify review and publication, SDOs need formal descriptions of 193 their data and interaction models. Several of them use a tabular 194 representation found in the specification itself, but use a formal 195 language as an alternative way of describing objects and resources 196 for formal purposes. Some examples of formal language use are as 197 follows. 199 The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML schema 200 [LWM2M-Schema] to describe their object and resource definitions. 201 The XML files of standardized objects are available for download at 202 [OMNA]. 204 The Bluetooth SIG defined Generic Attributes (GATT) services and 205 characteristics for use with Bluetooth Smart/Low Energy. The 206 services and characteristics are shown in a tabular form on the 207 Bluetooth SIG website at [SIG], and are also defined as XML instance 208 documents. 210 The Open Connectivity Foundation (OCF) uses JSON Schemas to formally 211 define data models, and RAML to define interaction models. The 212 standard files are available online at OneIoTa.org. 214 The AllSeen Alliance uses AllJoyn Introspection XML to define data 215 and interaction models in the same formal language, tailored for RPC- 216 style interaction. The standard files are available online on the 217 AllSeen Alliance web site, but both standard and vendor-defined model 218 files can be obtained by directly querying a device for them at 219 runtime. 221 The World-Wide Web Consortium (W3C) uses the Resource Description 222 Framework (RDF) to define data and interaction models using a format 223 tailored for the web. 225 The Internet Engineering Task Force (IETF) uses YANG to define data 226 and interaction models. Other SDOs may use various other formats. 228 o Formal Languages for Code Generation 230 Code generation tools that use formal data and information modelling 231 languages are needed by developers. For example, the AllSeen Visual 232 Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based 233 on the formal description of the data model. Another example of a 234 data modelling language that can be used for code generation is YANG. 235 A popular tool to help with code generation of YANG modules is pyang 236 [PYANG]. An example of a tool that can do code generation for 237 multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for 238 code generation included easing development of server-side device 239 functionality, clients, and compliance tests. 241 o Debugging Support 243 Debugging tools are needed that implement generic object browsers, 244 which use standard data models and/or retrieve formal language 245 descriptions from the devices themselves. As one example, the NRF 246 Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can 247 be used to display services and characteristics defined by the 248 Bluetooth SIG. As another example, AllJoyn Explorer 249 [AllJoynExplorer] can be used to browse and interact with any 250 resource exposed by an AllJoyn device, including both standard and 251 vendor-defined data models, by retrieving the formal descriptions 252 from the device at runtime. 254 o Translation 256 The working assumption is that devices need to have a common data 257 model with a priori knowledge of data types and actions. However 258 that would imply that each consortium/organization will try to define 259 their own, causing a major interoperability problem, if not a 260 completely intractable one given the amount of variations, 261 extensions, compositions or versioning changes that will happen on a 262 per data model basis. 264 Another potential approach is to have a minimal ammount of 265 information on the device to allow for a runtime binding to a 266 specific model, the objective being to require as little prior 267 knowledge as possible. 269 Moreover, gateways, bridges and other similar devices need to 270 dynamically translate (or map) one data model to another one. 271 Complexity will increase as there are also multiple protocols and 272 schemas that make interoperability harder to achieve. 274 o Runtime Discovery 276 Runtime discovery allows IoT devices to exchange metadata about the 277 data, potentially along with the data exchanged itself. In some 278 cases the metadata not only describes data but also the interaction 279 model as well. An example of such an approach has been shown with 280 HATEOAS [HATEOAS]. Another example is that all AllJoyn devices 281 support such runtime discovery using a protocol mechanism called 282 "introspection", where the metadata is queried from the device itself 283 [AllSeen]. 285 There are various models, whether deployed or possible, for such 286 discovery. The metadata might be extracted from a specification, or 287 looked up on a cloud repository (e.g., OneIoTa for OCF models), or 288 looked up via a vendor's site, or obtained from the device itself 289 (such as in the AllJoyn case). The relevant metadata might be 290 obtained from the same place, or different pieces might be obtained 291 from different places, such as separately obtaining information such 292 as (a) syntax information, (b) end-user descriptions in a desired 293 language, and (c) developer-specific comments for implementers. 295 4. Translation 297 In an ideal world where organizations and companies cooperate and 298 agree on a single data model standard, there is no need for gateways 299 that translate from one data model to the other one. However, this 300 is far from reality today, and there are many proprietary data models 301 in addition to the already standardized ones. As a consequence, 302 gateways are needed to translate between data models. This leads to 303 (n^2)-n combinations, in the worst case. 305 There are analogies with gateways back in the 1980s that were used to 306 translate between network layer protocols. Eventually IP took over, 307 providing the necessary end-to-end interoperability at the network 308 layer. Unfortunately, the introduction of gateways leads to the loss 309 of expressiveness due to the translation between data models. The 310 functionality of IP was so valuable in the market that advanced 311 features of other networking protocols became less attractive and 312 were not used anymore. 314 Participants discussed an alternative which they called a 'red star', 315 shown in Figure 1, where data models are translated to a common data 316 model shown in the middle. This reduces the number of translations 317 that are needed down to 2n (in the best case). The problem, of 318 course, is that everyone wants their own data model to be the red 319 star in the center. 321 +-----+ +-----+ 322 | | | | 323 | | -- -- | | 324 | | -- -- | | 325 +-----+ -- -- +-----+ 326 -- --- 327 -- -- 328 -- -- 329 -- -- 330 --- -- A -- --- 331 / \ ___/ \___ / \ 332 | | ---------------', .'--------------- | | 333 \ / /. ^ .\ \ / 334 --- /' '\ --- 335 -- -- 336 -- -- 337 -- -- 338 -- -- 339 -- -- 340 /\ -- -- /\ 341 / \ -- -- / \ 342 / \ / \ 343 / \ / \ 344 /--------\ /--------\ 346 Figure 1: The 'Red Star' in Data/Information Models. 348 While the workshop itself was not a suitable forum to discuss the 349 design of such translation in detail, several questions were raised: 351 o Do we need a "red star" that does everything or could we design 352 something that offers a more restricted functionality? 354 o How do we handle loss of data and loss of functionality? 356 o Should data be translated between data models or data models be 357 translated? 359 o How can interaction models be translated? They need to be dealt 360 with in addition to the data models. 362 o Many (if not all) data and interaction models have some bizarre 363 functionality that cannot be translated easily. How can those be 364 handled? 366 o What limitations are we going to accept in these translations? 367 The participants also addressed the question of when translation 368 should be done. Two use cases were discussed: 370 a) Design time: a translation between data model descriptions, such 371 as translating a YANG model to a RAML/JSON model, can be performed 372 once, during design time. A single information model might be mapped 373 to a number of different data models. 375 b) Run time: Runtime translation of values in two standard data 376 models can only be algorithmically done when the data model on one 377 side is algorithmically derived from the data model on the other 378 side. This was called a "derived model". It was discussed that the 379 availability of runtime discovery can aid in semantic translation, 380 such as when a vendor-specific data model on one side of a protocol 381 bridge is resolved and the translator can algorithmically derive the 382 semantically-equivalent vendor-specific data model on the other side 383 of a protocol bridge, as discussed in [BridgeTaxonomy]. 385 The participants agreed that algorithm translation will generally 386 require custom code, whenever one is translating to anything other 387 than a derived model. 389 Participants concluded that it is typically easier to translate data 390 between systems that follow the same communication architecture. 392 5. Dealing with change 394 A large part of the workshop was dedicated to the evolution of 395 devices and server-side applications. Interactions between devices 396 and services and how their relationship evolves over time is 397 complicated by their respective different interaction models. 399 The workshop participants discussed various approaches to deal with 400 change. In the most basic case, a developer might use a description 401 of an API and implement the protocol steps. Sometimes the data or 402 information model can be used to generate code stubs. Subsequent 403 changes to an API require changes on the clients to upgrade to the 404 new version, which requires some development of new code to satisfy 405 the needs of the new API. 407 These interactions could be made machine-understandable in the first 408 place, enabling for changes to happen at runtime. In that scenario, 409 a machine client could discover the possible interactions with a 410 service, adapting to changes as they occur without specific code 411 being developed to adapt to them. 413 The challenge seems to be to code the human-readable specification 414 into a machine-readable format. Machine-readable languages require a 415 shared vocabulary to give meaning to the tags. 417 These types of interactions are often based on the REST architectural 418 style. Its principle is that a device or endpoint only needs a 419 single entry point with a host providing descriptions of the API in- 420 band by means of web links and forms. 422 By defining IoT-specific relation types, it is possible to drive 423 interactions through links instead of hardcoding URIs into a RESTful 424 client, thus making the system flexible enough for later changes. 425 The definition of the basic hypermedia formats for IoT is still work 426 in progress. However, some of the existing mechanisms can be reused, 427 such as resource discovery, forms, or links. 429 6. Security Considerations 431 There were two types of security considerations discussed: use of 432 formal data models for security configuration, and security of data 433 and data models in general. 435 It was observed that the security assumptions and configuration, or 436 "security model", varies by ecosystem today, making the job of a 437 translator difficult. For example, the types of security principals 438 (e.g., user vs. device vs. application), the use of access control 439 lists (ACLs) vs. capabilities, and what types of policies can be 440 expressed, all vary by ecosystem. As a result, the security model 441 architecture generally dictates where translation can be done. 443 One approach discussed was whether two endpoints might be able to use 444 some overlay security model, across a translator between two 445 ecosystems, which only works if the two endpoints agree on a common 446 data model for their communication. Another approach discussed was 447 simply having a translator act as a trusted intermediary, which 448 allows the translator to be able to translate between different data 449 models. 451 One suggestion discussed was potentially adding metadata into either 452 the formal data model language, or accompanying the data values over 453 the wire, tagging the data with privacy levels. However, sometimes 454 even the privacy level of information might itself be sensitive. 455 Still, it was observed that being able to dynamically learn security 456 requirements might help provide better UIs and translators. 458 7. Collaboration 460 The participants discussed how best to share information among their 461 various organizations. One discussion was around having joint 462 meetings. One current challenge reported was that organizations were 463 not aware of when and where each others' meetings were scheduled, and 464 sharing such information could help organizations better collocate 465 meetings. To facilitate this exchange, the participants agreed to 466 add links to their respective meeting schedules from a common page in 467 the IOTSI repository [IOTSIGIT]. 469 Another challenge reported was that organizations did not know how to 470 find each others' published data models, and sharing such information 471 could better facilitate reuse of the same information model. To 472 facilitate this exchange, this participants discussed whether a 473 common repository might be used by multiple organizations. The OCF's 474 OneIoTa repository was discussed as one possibility but it was 475 reported that its terms of use at the time of the workshop prevented 476 this. The OCF agreed to take this back and look at updating the 477 terms of use to allow other organizations to use it too, as the 478 restriction was not the intent. Schema.org was discussed as another 479 possibility. In the meantime, the participants agreed to add links 480 to their respective repositories from a common page in the IOTSI 481 repository [IOTSIGIT]. 483 It was also agreed that the iotsi@iab.org mailing list would remain 484 open and available for sharing information between all relevant 485 organizations. 487 8. Acknowledgements 489 We would like to thank all paper authors and participants for their 490 contributions, and Ericsson for hosting the workshop. 492 9. Appendix A: Program Committee 494 This workshop was organized by the following individuals: Jari Arkko, 495 Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes 496 Tschofenig. 498 10. Appendix B: Accepted Position Papers 500 o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever" 502 o Carsten Bormann, "Noise in specifications hurts" 504 o Benoit Claise, "YANG as the Data Modelling Language in the IoT 505 space" 507 o Robert Cragie, "The ZigBee Cluster Library over IP" 509 o Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair: 510 interoperable IoT services for major Building Automation and 511 Lighting Control ecosystems" 513 o Universal Devices, "Object Oriented Approach to IoT 514 Interoperability" 516 o Bryant Eastham, "Interoperability and the OpenDOF Project" 518 o Stephen Farrell, Alissa Cooper, "It's Often True: Security's 519 Ignored (IOTSI) - and Privacy too" 521 o Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT semantics 522 landscape" 524 o Ted Hardie, "Loci of Interoperability for the Internet of Things" 526 o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure 527 Communications" 529 o Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart 530 Objects" 532 o David Jones, IOTDB - "Interoperability Through Semantic 533 Metastandards" 535 o Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler of 536 Semantic Interoperability on the Web of Things" 538 o Achilleas Kemos, "Alliance for Internet of Things Innovation 539 Semantic Interoperability Release 2.0, AIOTI WG03 - IoT 540 Standardisation" 542 o Ari Keraenen, Cullen Jennings, "SenML: simple building block for 543 IoT semantic interoperability" 545 o Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on Unified 546 Data Model and Framework to Support Interoperability between IoT 547 Applications" 549 o Michael Koster, "Model-Based Hypertext Language" 551 o Matthias Kovatsch, Yassin N. Hassan, Klaus Hartke, "Semantic 552 Interoperability Requires self describing Interaction Models" 554 o Kai Kreuzer, "A Pragmatic Approach to Interoperability in the 555 Internet of Things" 557 o Barry Leiba, "Position Paper" 559 o Marcello Lioy, "AllJoyn" 561 o Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON Hyper- 562 Schema" 564 o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope 565 of security issues" 567 o Open Geospatial Consortium, "OGC SensorThings API: Communicating 568 "Where" in the Web of Things" 570 o Jean Paoli, Taqi Jaffri, "IoT Information Model Interoperability: 571 An Open, Crowd-Sourced Approach in Three Parallel Parti" 573 o Joaquin Prado, "OMA Lightweight M2M Resource Model" 575 o Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic 576 Interoperability Workshop" 578 o Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable Data 579 to Facilitate Time and Context Specific Interoperability" 581 o Jasper Roes, Laura Daniele, "Towards semantic interoperability in 582 the IoT using the Smart Appliances REFerence ontology (SAREF) and 583 its extensions" 585 o Max Senges, "Submission for IAB IoT Sematic Interoperability 586 workshop" 588 o Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation 589 Experiences of Semantic Interoperability for RESTful Gateway 590 Management" 592 o Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic 593 Interoperability Gaps in the Internet-of-Things Meta-Models" 595 o Robert Sparks and Ben Campbell, "Considerations for certain IoT 596 based services" 598 o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool" 600 o J. Clarke Stevens, Piper Merriam, "Derived Models for 601 Interoperability Between IoT Ecosystems" 603 o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity 604 Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"" 606 o Andrew Sullivan, "Position paper for IOTSI workshop" 608 o Darshak Thakore, "IoT Security in the context of Semantic 609 Interoperability" 611 o Dave Thaler, "IoT Bridge Taxonomy" 613 o Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to 614 Semantic Interoperability" 616 o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike 617 Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram, "Internet 618 of Things: Toward Smart Networked Systems and Societies" 620 o Peter van der Stok, Andy Bierman, "YANG-Based Constrained 621 Management Interface (CoMI)" 623 11. Appendix C: List of Participants 625 o Andy Bierman, YumaWorks 627 o Carsten Bormann, Uni Bremen/TZI 629 o Ben Campbell, Oracle 631 o Benoit Claise, Cisco 633 o Alissa Cooper, Cisco 635 o Robert Cragie, ARM Limited 637 o Laura Daniele, TNO 639 o Bryant Eastham, OpenDOF 641 o Christian Groves, Huawei 643 o Ted Hardie, Google 645 o Yonggeun Hong, ETRI 647 o Russ Housley, Vigil Security 649 o David Janes, IOTDB 650 o Jaime Jimenez, Ericsson 652 o Shailendra Karody, Catalina Labs 654 o Ari Keraenen, Ericsson 656 o Michael Koster, SmartThings 658 o Matthias Kovatsch, Siemens 660 o Kai Kreuzer, Deutsche Telekom 662 o Barry Leiba, Huawei 664 o Steve Liang, Uni Calgary 666 o Marcello Lioy, Qualcomm 668 o Kerry Lynn, Verizon 670 o Mayan Mathen, Catalina Labs 672 o Erik Nordmark, Arista 674 o Jean Paoli, Microsoft 676 o Joaquin Prado, OMA 678 o Dave Raggett, W3C 680 o Max Senges, Google 682 o Ned Smith, Intel 684 o Robert Sparks, Oracle 686 o Ram Sriram, NIST 688 o Clarke Stevens 690 o Ram Subramanian, Intel 692 o Andrew Sullivan, DIN 694 o Darshak Thakore, CableLabs 696 o Dave Thaler, Microsoft 697 o Hannes Tschofenig, ARM Limited 699 o Michael Verschoor, Philips Lighting 701 12. Informative References 703 [AllJoynExplorer] 704 Microsoft, "AllJoyn Explorer", 2016. 706 [AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to 707 Semantic Interoperability", 2016, . 710 [AllSeen-Plugin] 711 Rockwell, B., "Using the AllJoyn Studio Extension", 2016. 713 [BridgeTaxonomy] 714 Thaler, D., "IoT Bridge Taxonomy", 2016, 715 . 718 [HATEOAS] Kovatsch, M., "Semantic Interoperability Requires Self- 719 describing Interaction Models - HATEOAS for the Internet 720 of Things", Proceedings of the IoT Semantic 721 Interoperability Workshop 2016, 2016, 722 . 725 [IOTSIAG] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) - 726 Agenda and Slides", 2016, 727 . 729 [IOTSIGIT] 730 IOTSI, "Github Collaborative Repository", 2016, 731 . 733 [IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) 734 2016 - Main Page and Position Papers", 2016, 735 . 737 [LWM2M-Schema] 738 OMA, "OMA LWM2M XML Schema", 2018. 740 [nRF-Sniffer] 741 Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low 742 energy packet sniffer", 2016. 744 [OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource 745 Registry", 2018. 747 [OpenDOF] OpenDOF, "The OpenDOF Project", 2015, 748 . 750 [PYANG] Bjorklund, M., "An extensible YANG validator and converter 751 in python", 2016. 753 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 754 Information Models and Data Models", RFC 3444, 755 DOI 10.17487/RFC3444, January 2003, . 758 [SIG] Bluetooth SIG, "GATT Specifications", 2018, 759 . 761 Authors' Addresses 763 Jaime Jimenez 764 Ericsson 766 Email: jaime.jimenez@ericsson.com 768 Hannes Tschofenig 769 Arm Ltd. 771 Email: hannes.tschofenig@arm.com 773 Dave Thaler 774 Microsoft 776 Email: dthaler@microsoft.com