idnits 2.17.1 draft-iab-iotsi-workshop-00.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 a Security Considerations section. ** 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.) ** The abstract seems to contain references ([IOTSIWS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 168 has weird spacing: '...b-cloud thing...' == Line 173 has weird spacing: '...a Thing some ...' == Line 176 has weird spacing: '... things some ...' -- The document date (May 24, 2016) is 2891 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IOTSIAG' is defined on line 617, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 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 4 Intended status: Informational H. Tschofenig 5 Expires: November 25, 2016 6 D. Thaler 8 May 24, 2016 10 Report from the Internet of Things (IoT) Semantic Interoperability 11 (IOTSI) Workshop 2016 12 draft-iab-iotsi-workshop-00.txt 14 Abstract 16 This document provides a summary of the 'Workshop on Internet of 17 Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIWS], which took 18 place in Santa Clara, CA, 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 to accomplish 21 interoperability at the application layer. This report summarizes 22 the discussions and lists recommendations to the standards community. 23 The views and positions in this report are those of the workshop 24 participants and do not necessarily reflect those of the authors and 25 the Internet Architecture Board (IAB), which organized the workshop. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 25, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5 65 5. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Runtime Discovery . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Appendix A: Program Committee . . . . . . . . . . . . . . . . 9 69 9. Appendix B: Accepted Position Papers . . . . . . . . . . . . 9 70 10. Appendix C: List of Participants . . . . . . . . . . . . . . 12 71 11. Informative References . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 The Internet Architecture Board (IAB) holds occasional workshops 77 designed to consider long-term issues and strategies for the 78 Internet, and to suggest future directions for the Internet 79 architecture. The investigated topics often require coordinated 80 efforts of many organizations and industry bodies to improve an 81 identified problem. One of the targets of the workshops is to 82 establish communication between relevant organizations, specially 83 when the topics are out of the scope for the Internet Engineering 84 Task Force (IETF). This long-term planning function of the IAB is 85 complementary to the ongoing engineering efforts performed by working 86 groups of the IETF. 88 Increasing interoperability in the area of Internet of Things (IoT) 89 has been a top priority for many standards organizations and 90 pariticularly the lower layers of the Internet protocol stack have 91 received a lot of attention. Also at the application layer, such as 92 with CoAP and HTTP, there is a trend in reusing RESTful design 93 patterns. However, data exchanged on top of these application layer 94 protocols there is still a lot of fragmentation and the same degree 95 of increase in interoperability has not been observed. 97 Thus, the IAB decided to organize a workshop to reach out to relevant 98 stakeholders to explore the state-of-the-art and to identify 99 communality and gaps. 101 o The different perceived state of the art on data and information 102 models. 104 o The lack of an encoding-independent standardization of the 105 information, the so-called information model. 107 o The strong relationship with the underlying communication pattern, 108 such as remote procedure calls (RPC), publish/subscribe or RESTful 109 designs. 111 o Identifying which similar concepts groups have develop in 112 parallel, specially those that would require only slight 113 modifications to solve interoperability. 115 o Identifying how existing data models can be mapped against each 116 other to offer inter working. 118 o Identifying common use cases for cooperation and harmonization. 120 2. Terminology 122 The first roadblock to semantic interoperability is the lack of a 123 common vocabulary to start the discussion. There is a need to align 124 between participating organizations on a common set of basic terms. 125 [RFC3444] does a start by separating conceptual models for designers 126 or Information Models (IMs) and concrete detailed definitions for 127 implementors or Data Models (DMs). There are concepts that are 128 undefined in that RFC and elsewhere, such as the interaction with the 129 resources of an endpoint or Interaction Model. Therefore the three 130 "main" common models that could be identified were: 132 Information Model (IM) it defines an environment at the highest 133 level of abstraction, they express the desired functionality. 134 They can be defined informally (e.g. in plain English) or more 135 formally (e.g. UML, Entity-Relationship Diagrams, etc.). 136 Implementation details are hidden. 138 Data Model (DM) it defines concrete data representations at a lower 139 level of abstraction, including implementation and protocol- 140 specific details. Some examples are: SNMP Management Information 141 Base (MIBs), W3C Thing Description (TD) Things, YANG models, LWM2M 142 Schemas, OCF Schemas and so on. 144 Interaction Model (IN) it defines how data is accessed and retrieved 145 from the endpoints, being therefore tied to the specific 146 communication pattern that the system has (e.g. REST methods, 147 Publish/Subscribe operations or RPC-calls). 149 Another identified terminology issue is the semantic meaning overload 150 that some terms have. Meaning will vary depending on the context the 151 term is used. Some examples of such terms are: semantics, models, 152 encoding, serialization format, media types or encoding types. Due 153 to time constraints no concrete terminology was agreed upon, however 154 work will continue within each organization to create various 155 terminology documents, see [IOTSIGIT]. 157 3. Architecture 159 Architectures follow different design patterns, some are REST- 160 oriented with clear methods to find and manipulate resources on 161 endpoints with almost no state kept between them. Others are more 162 Publish/Subscribe-oriented that focus on the flow of information 163 based on the topics of the information that is being shared. Others 164 are RPC-like requiring to know beforehand the set of parameters that 165 are accessed, requiring to generate code both on the client and 166 server side, they are tightly coupled and service-oriented. 168 Thing-hub-cloud things talk to a hub, which talks back to them and 169 to the cloud. There is a spectrum of emphasis on the hub vs. the 170 cloud. For some the hub is simply an access point; for others it 171 is a critical place for control loops and ALGs. 173 Meta Thing some things are actually virtual, like an alarm composed 174 of clock, lights, and thermostat. 176 Nearby things some things may be geospatially related even if they 177 are not on the same network or within the same administrative 178 domain. 180 Current data models and definitions for "things" often focus on 181 defining actual physical devices and representing their state. That 182 focus should perhaps be shifted into a more holistic or user-oriented 183 perspective, defining abstract concepts as well. On the other a lot 184 of focus is placed on human interaction with physical devices while 185 IoT will be more oriented to interaction between "things" instead. 187 Those things should be designed to be multiple-purpose, keeping in 188 mind that solutions should be open-ended to facilitate new usages and 189 new future domains of operation. this pattern has already happened, 190 devices that were intended for one purpose end up being used for a 191 different one given the right context ((e.g. smart phone led light 192 turned out to be a heartrate monitor). IoT domain is currently 193 missing insights into what user actually expect. 195 4. What Problems to Solve 197 Although the workshop focused on a specific problem it became obvious 198 from the position papers that various organizations, industry groups 199 and individuals attempted to solve different problems. At least the 200 following goals have been described: 202 o Formal Languages for Documentation Purposes 204 Standardization organizations are in the need for a more formal 205 description of their information and data models in order to simplify 206 review, and publication. For example, the Open Mobile Alliance (OMA) 207 used an XML schema [LWM2M-Schema] to describe their object 208 definitions (i.e., data model) as XML instance documents. These XML 209 documents offer an alternative way of describing objects compared to 210 the tabular representation found in the specification itself. The 211 XML files of standardized objects are available for download at 212 [OMNA]. Furthermore, a tool is offered to define new objects and 213 resources. The online editor tool can be found at [OMA-Editor]. 215 o Formal Languages for Code Generation 217 Formal data and information modelling languages for use by developers 218 to enable code generation. For example, the Allseen Visual Studio 219 Plugin [Allseen-Plugin] offers a wizzard to generate code based on 220 the formal description of the data model. Another example of a data 221 modelling language that can be used for code generation is YANG. A 222 popular tool to help with code generation of YANG modules is pyang 223 [PYANG]. 225 o Debugging Support 227 Ability to allow debugging tools to implement generic object browsers 228 by utilizing the standardized information and data model. Example: 229 NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer]. 231 o Translation 233 The ability for gateways and other similar devices to dynamically 234 translate (or map) one data model to another one. An example of this 235 idea can be found in [UDI]. 237 o Runtime Discovery 238 Allow IoT devices to exchange information, potentially along with the 239 data exchange, to discover meta-data about the data and, potentially, 240 even a self-describing interaction model. An example of such an 241 approach has been shown with HATEOS [HATEOS]. 243 5. Translation 245 One of the targets of interoperability is to create translators 246 between the data models. There are analogies with gateways back in 247 1985 when they were used to translate between network protocols, 248 eventually IP took over providing interoperability, however we lost 249 some of the features provided by those other protocols. The creation 250 of an equivalent "hub/s" that offer translation between the different 251 data models or data semantics seems one of the ways forward. Some 252 lose of expressiveness due to the translation between models seems 253 also unavoidable. 255 When it comes to translation two different distinctions appear: 256 translating data between data models and translating data models. 257 The first one implies doing the translation at runtime while the 258 second performs one translation between the data models one time, 259 like translating a YANG model to a RAML/JSON one. Indeed, for every 260 IM multiple DMs could be translated. 262 In a sense these distinctions affect as to when the translation is 263 performed. It can be done at "design time" when the information 264 model is done, it can be done at runtime for a concrete data model 265 and it can be done depending n the actual serialization. 267 Yet another distinction will appear depending on the requirements 268 from the application protocols, RPC-style ones might require a 269 slightly different DM than REST ones for similar operations, for 270 example SNMP-traps could be similar to CoAP-Observations but not 271 quite the same. It is easier to translate between systems that 272 follow the same architecture/design pattern than across 273 architectures, full translation might not even be possible (e.g. 274 stateless vs stateful systems). 276 Translation of models script to translate XML to YANG Translation of 277 serialized data, on a hub in order to normalize it to other data 278 model. 280 6. Runtime Discovery 282 Runtime changes are doing after design and at compile time. 283 Discovery, is it devices or data items on devices. A lot of people 284 think about devices but also abstract entities. To do discovery one 285 question is "how much must "be shared before time. The meta-data has 286 also two possible notions, is it instance specific (e.g. location of 287 the thing) or does it have to do with the model itself? 289 Need to handle change in the environment. Replace things without 290 manual configuration, change control flow, etc. at runtime. Few 291 things (vocabulary) is shared a priori. Drives the application 292 runtime, "Engine of application state", we needs self-describing 293 interaction models. Ravi: nothing prevents HATEOAS + data model Ari: 294 And OMA LwM2M uses SenML Matthias: these are complementary 295 approaches. It is to point out that it is also about Interaction 296 Models. Of course DM are needed to convey data. 298 Interaction model 300 You get one entry point (in CoAP it is the RD) and the client tries 301 to perform discovery in order to find and follow links in order to 302 discover capabilities. You submit forms to interact with them. This 303 way you can create processes that span over multiple devices involved 304 in the process. If later one you find that you need something else, 305 you can add new functionality at runtime, next client that comes 306 along will have the same logic but see different capabilities of 307 functionality and therefore use it. 309 Parts of the information have to be shared a priori. The process is 310 incremental, but once discovered, you don't need to perform the same 311 operation every time, you can go to the bookmark. 313 The following are examples of all those in HTML. 315 // Links (Anchors) with human-readable information 316 More information 317 319 // Templated Links to perform a query with a parameter. 320
321 322
324 // Embedded Links which are used to embed other resources. 325 326