Internet Architecture Board (IAB) J. Jimenez Request for Comments: 8477 H. Tschofenig Category: Informational D. Thaler ISSN: 2070-1721 October 2018 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
AbstractThis document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. 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. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8477.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5 4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Dealing with Change . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Program Committee . . . . . . . . . . . . . . . . . 14 Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 14 Appendix C. List of Participants . . . . . . . . . . . . . . . . 17 IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
IOTSIAG] [IOTSIWS]. In particular, the IAB was interested to learn about the following aspects: o What is the state of the art in data and information models? What should an information model look like? o What is the role of formal languages, such as schema languages, in describing information and data models? o What is the role of metadata, which is attached to data to make it self-describing?
o How can we achieve interoperability when different organizations, companies, and individuals develop extensions? o What is the experience with interworking various data models developed from different groups, or with data models that evolved over time? o What functionality should online repositories for sharing schemas have? o How can existing data models be mapped against each other to offer interworking? o Is there room for harmonization, or are the use cases of different groups and organizations so unique that there is no possibility for cooperation? o How can organizations better work together to increase awareness and information sharing? RFC3444] provides a starting point by separating conceptual models for designers, or "information models", from concrete detailed definitions for implementers, or "data models". There are concepts that are undefined in that RFC and elsewhere, such as the interaction with the resources of an endpoint, or "interaction model". Therefore, the three "main" common models that were identified were: Information Model An information model defines an environment at the highest level of abstraction and expresses the desired functionality. Information models can be defined informally (e.g., in prose) or more formally (e.g., Unified Modeling Language (UML), Entity- Relationship Diagrams, etc.). Implementation details are hidden. Data Model A data model defines concrete data representations at a lower level of abstraction, including implementation- and protocol- specific details. Some examples are SNMP Management Information Base (MIB) modules, World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to- Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.
Interaction Model An interaction model defines how data is accessed and retrieved from the endpoints, being, therefore, tied to the specific communication pattern that the system has (e.g., REST methods, Publish/Subscribe operations, or RPC calls). Another identified terminology issue is the semantic meaning overload that some terms have. The meaning can vary depending on the context in which the term is used. Some examples of such terms are as follows: semantics, models, encoding, serialization format, media types, and encoding types. Due to time constraints, no concrete terminology was agreed upon, but work will continue within each organization to create various terminology documents. The participants agreed to set up a GitHub repository [IOTSIGIT] for sharing information. LWM2M-Schema] to describe their object and resource definitions. The XML files of standardized objects are available for download at [OMNA]. The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on the Bluetooth SIG website [SIG] and are defined as XML instance documents. The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models and RESTful API Modeling Language (RAML) to define interaction models. The standard files are available online at <oneIoTa.org>.
The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. The standard files are available online on the AllSeen Alliance website, but both standard and vendor-defined model files can be obtained by directly querying a device for them at runtime. The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web. The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. Other SDOs may use various other formats. o Formal Languages for Code Generation Code-generation tools that use formal data and information modeling languages are needed by developers. For example, the AllSeen Visual Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based on the formal description of the data model. Another example of a data modeling language that can be used for code generation is YANG. A popular tool to help with code generation of YANG modules is pyang [PYANG]. An example of a tool that can generate code for multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests. o Debugging Support Debugging tools are needed that implement generic object browsers, which use standard data models and/or retrieve formal language descriptions from the devices themselves. As one example, the nRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can be used to display services and characteristics defined by the Bluetooth SIG. As another example, AllJoyn Explorer [AllJoynExplorer] can be used to browse and interact with any resource exposed by an AllJoyn device, including both standard and vendor-defined data models, by retrieving the formal descriptions from the device at runtime. o Translation The working assumption is that devices need to have a common data model with a priori knowledge of data types and actions. However, that would imply that each consortium/organization will try to define their own data model. That would cause a major interoperability
problem, possibly a completely intractable one given the number of variations, extensions, compositions, or versioning changes that will happen for each data model. Another potential approach is to have a minimal amount of information on the device to allow for a runtime binding to a specific model, the objective being to require as little prior knowledge as possible. 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. o Runtime Discovery Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. An example of such an approach has been shown with Hypermedia as the Engine of Application State (HATEOAS) [HATEOAS]. Another example is that all AllJoyn devices support such runtime discovery using a protocol mechanism called "introspection", where the metadata is queried from the device itself [AllSeen]. There are various models, whether deployed or possible, for such discovery. The metadata might be extracted from a specification, looked up on a cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's site, or obtained from the device itself (such as in the AllJoyn case). The relevant metadata might be obtained from the same place or different pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in a desired language, and (c) developer-specific comments for implementers.
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. Participants discussed an alternative that they called a "red star", shown in Figure 1, 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. +-----+ +-----+ | | | | | | -- -- | | | | -- -- | | +-----+ -- -- +-----+ -- --- -- -- -- -- -- -- --- -- A -- --- / \ ___/ \___ / \ | | ---------------', .'--------------- | | \ / /. ^ .\ \ / --- /' '\ --- -- -- -- -- -- -- -- -- -- -- /\ -- -- /\ / \ -- -- / \ / \ / \ / \ / \ /--------\ /--------\ Figure 1: The "Red Star" in Data/Information Models While the workshop itself was not a suitable forum to discuss the design of such translation in detail, several questions were raised: o Do we need a "red star" that does everything, or could we design something that offers a more restricted functionality? o How do we handle loss of data and functionality?
o Should data be translated between data models, or should data models themselves be translated? o How can interaction models be translated? They need to be dealt with in addition to the data models. o Many (if not all) data and interaction models have some bizarre functionality that cannot be translated easily. How can those be handled? o What limitations are we going to accept in these translations? The participants also addressed the question of when translation should be done. Two use cases were discussed: (a) Design time: A translation between data model descriptions, such as translating a YANG module to a RAML/JSON model, can be performed once, during design time. A single information model might be mapped to a number of different data models. (b) Run time: Runtime translation of values in two standard data models can only be algorithmically done when the data model on one side is algorithmically derived from the data model on the other side. This was called a "derived model". It was discussed that the availability of runtime discovery can aid in semantic translation, such as when a vendor-specific data model on one side of a protocol bridge is resolved and the translator can algorithmically derive the semantically equivalent vendor- specific data model on the other side. This situation is discussed in [BridgeTaxonomy]. The participants agreed that algorithm translation will generally require custom code whenever one is translating to anything other than a derived model. Participants concluded that it is typically easier to translate data between systems that follow the same communication architecture.
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. These interactions could be made machine understandable in the first place, enabling for changes to happen at runtime. In that scenario, a machine client could discover the possible interactions with a service, adapting to changes as they occur without specific code being developed to adapt to them. 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. These types of interactions are often based on the REST architectural style. Its principle is that a device or endpoint only needs a single entry point, with a host providing descriptions of the API in-band by means of web links and forms. By defining IoT-specific relation types, it is possible to drive interactions through links instead of hard-coding URIs into a RESTful client, thus making the system flexible enough for later changes. The definition of the basic hypermedia formats for IoT is still a work in progress. However, some of the existing mechanisms can be reused, such as resource discovery, forms, or links.
[AllJoynExplorer] Microsoft, "AllJoyn". [AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability", 2016, <https://www.iab.org/ wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>. [AllSeen-Plugin] Rockwell, B., "Using the AllJoyn Studio Extension", August 2015. [BridgeTaxonomy] Thaler, D., "IoT Bridge Taxonomy", IAB IOTSI Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/DThaler-IOTSI.pdf>. [HATEOAS] Kovatsch, M., Hassan, Y., and K. Hartke, "Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things", Proceedings of the IAB IoT Semantic Interoperability Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf>. [IOTSIAG] IAB, "IoT Semantic Interoperability Workshop Agenda", 2016, <https://www.iab.org/activities/workshops/iotsi/agenda/>. [IOTSIGIT] "Starting place for the IoT Semantic Interoperability Workshop (IOTSI) Information Resource", commit ff21f74, July 2018, <https://github.com/iotsi/iotsi>. [IOTSIWS] IAB, "IoT Semantic Interoperability Workshop 2016", 2016, <https://www.iab.org/activities/workshops/iotsi/>. [LWM2M-Schema] OMA, "LWM2M XML Schema - LWM2M Editor Schema", July 2018. [nRF-Sniffer] Nordic Semiconductor, "nRF Sniffer: Smart/Bluetooth low energy packet sniffer". [OMNA] OMA, "OMA LightweightM2M (LwM2M) Object and Resource Registry".
[OpenDOF] OpenDOF, "The OpenDOF Project", <https://opendof.org>. [PYANG] "An extensible YANG validator and converter in python", commit 15c807f, September 2018, <https://github.com/mbj4668/pyang>. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>. [SIG] Bluetooth SIG, "GATT Specifications", <https://www.bluetooth.com/specifications/gatt>.
o Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation" o Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability" o Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications" o Michael Koster, "Model-Based Hypertext Language" o Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models" o Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things" o Barry Leiba, "Position Paper" o Marcello Lioy, "AllJoyn" o Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema" o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues" o Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things" o Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti" o Joaquin Prado, "OMA Lightweight M2M Resource Model" o Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop" o Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability" o Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"
o Max Senges, "Submission for IAB IoT Sematic Interoperability workshop" o Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management" o Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models" o Robert Sparks and Ben Campbell, "Considerations for certain IoT- based services" o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool" o J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems" o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)" o Andrew Sullivan, "Position paper for IOTSI workshop" o Darshak Thakore, "IoT Security in the context of Semantic Interoperability" o Dave Thaler, "IoT Bridge Taxonomy" o Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability" o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies" o Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"
IAB Members at the Time of Approval Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf