idnits 2.17.1
draft-iab-iotsi-workshop-01.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 ([IOTSIAG], [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 169 has weird spacing: '...b-cloud thing...'
== Line 174 has weird spacing: '...a Thing some ...'
== Line 177 has weird spacing: '... things some ...'
-- The document date (November 14, 2016) is 2720 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 3 errors (**), 0 flaws (~~), 4 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 Ericsson
4 Intended status: Informational H. Tschofenig
5 Expires: May 18, 2017 ARM
6 D. Thaler
7 Microsoft
8 November 14, 2016
10 Report from the Internet of Things (IoT) Semantic Interoperability
11 (IOTSI) Workshop 2016
12 draft-iab-iotsi-workshop-01.txt
14 Abstract
16 This document provides a summary of the 'Workshop on Internet of
17 Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIAG], [IOTSIWS],
18 which took place in Santa Clara, CA, on March 17-18, 2016. The main
19 goal of the workshop was to foster a discussion on the different
20 approaches used by companies and standards developing organizations
21 to accomplish interoperability at the application layer. This report
22 summarizes the discussions and lists recommendations to the standards
23 community. The views and positions in this report are those of the
24 workshop participants and do not necessarily reflect those of the
25 authors and the Internet Architecture Board (IAB), which organized
26 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 May 18, 2017.
45 Copyright Notice
47 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
65 4. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5
66 5. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 6. Dealing with change . . . . . . . . . . . . . . . . . . . . . 7
68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
69 8. Appendix A: Program Committee . . . . . . . . . . . . . . . . 8
70 9. Appendix B: Accepted Position Papers . . . . . . . . . . . . 8
71 10. Appendix C: List of Participants . . . . . . . . . . . . . . 10
72 11. Informative References . . . . . . . . . . . . . . . . . . . 12
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
75 1. Introduction
77 The Internet Architecture Board (IAB) holds occasional workshops
78 designed to consider long-term issues and strategies for the
79 Internet, and to suggest future directions for the Internet
80 architecture. The investigated topics often require coordinated
81 efforts of many organizations and industry bodies to improve an
82 identified problem. One of the targets of the workshops is to
83 establish communication between relevant organizations, specially
84 when the topics are out of the scope for the Internet Engineering
85 Task Force (IETF). This long-term planning function of the IAB is
86 complementary to the ongoing engineering efforts performed by working
87 groups of the IETF.
89 Increasing interoperability in the area of Internet of Things (IoT)
90 has been a top priority for many standards organizations and
91 pariticularly the lower layers of the Internet protocol stack have
92 received a lot of attention. Also at the application layer, such as
93 with CoAP and HTTP, there is a trend in reusing RESTful design
94 patterns. However, data exchanged on top of these application layer
95 protocols there is still a lot of fragmentation and the same degree
96 of increase in interoperability has not been observed.
98 Thus, the IAB decided to organize a workshop to reach out to relevant
99 stakeholders to explore the state-of-the-art and to identify
100 communality and gaps.
102 o The different perceived state of the art on data and information
103 models.
105 o The lack of an encoding-independent standardization of the
106 information, the so-called information model.
108 o The strong relationship with the underlying communication pattern,
109 such as remote procedure calls (RPC), publish/subscribe or RESTful
110 designs.
112 o Identifying which similar concepts groups have develop in
113 parallel, specially those that would require only slight
114 modifications to solve interoperability.
116 o Identifying how existing data models can be mapped against each
117 other to offer inter working.
119 o Identifying common use cases for cooperation and harmonization.
121 2. Terminology
123 The first roadblock to semantic interoperability is the lack of a
124 common vocabulary to start the discussion. There is a need to align
125 between participating organizations on a common set of basic terms.
126 [RFC3444] does a start by separating conceptual models for designers
127 or Information Models (IMs) and concrete detailed definitions for
128 implementors or Data Models (DMs). There are concepts that are
129 undefined in that RFC and elsewhere, such as the interaction with the
130 resources of an endpoint or Interaction Model. Therefore the three
131 "main" common models that could be identified were:
133 Information Model (IM) it defines an environment at the highest
134 level of abstraction, they express the desired functionality.
135 They can be defined informally (e.g. in plain English) or more
136 formally (e.g. UML, Entity-Relationship Diagrams, etc.).
137 Implementation details are hidden.
139 Data Model (DM) it defines concrete data representations at a lower
140 level of abstraction, including implementation and protocol-
141 specific details. Some examples are: SNMP Management Information
142 Base (MIBs), W3C Thing Description (TD) Things, YANG models, LWM2M
143 Schemas, OCF Schemas and so on.
145 Interaction Model (IN) it defines how data is accessed and retrieved
146 from the endpoints, being therefore tied to the specific
147 communication pattern that the system has (e.g. REST methods,
148 Publish/Subscribe operations or RPC-calls).
150 Another identified terminology issue is the semantic meaning overload
151 that some terms have. Meaning will vary depending on the context the
152 term is used. Some examples of such terms are: semantics, models,
153 encoding, serialization format, media types or encoding types. Due
154 to time constraints no concrete terminology was agreed upon, however
155 work will continue within each organization to create various
156 terminology documents, see [IOTSIGIT].
158 3. Architecture
160 Architectures follow different design patterns, some are REST-
161 oriented with clear methods to find and manipulate resources on
162 endpoints with almost no state kept between them. Others are more
163 Publish/Subscribe-oriented that focus on the flow of information
164 based on the topics of the information that is being shared. Others
165 are RPC-like requiring to know beforehand the set of parameters that
166 are accessed, requiring to generate code both on the client and
167 server side, they are tightly coupled and service-oriented.
169 Thing-hub-cloud things talk to a hub, which talks back to them and
170 to the cloud. There is a spectrum of emphasis on the hub vs. the
171 cloud. For some the hub is simply an access point; for others it
172 is a critical place for control loops and ALGs.
174 Meta Thing some things are actually virtual, like an alarm composed
175 of clock, lights, and thermostat.
177 Nearby things some things may be geospatially related even if they
178 are not on the same network or within the same administrative
179 domain.
181 Current data models and definitions for "things" often focus on
182 defining actual physical devices and representing their state. That
183 focus should perhaps be shifted into a more holistic or user-oriented
184 perspective, defining abstract concepts as well. On the other a lot
185 of focus is placed on human interaction with physical devices while
186 IoT will be more oriented to interaction between "things" instead.
188 Those things should be designed to be multiple-purpose, keeping in
189 mind that solutions should be open-ended to facilitate new usages and
190 new future domains of operation. this pattern has already happened,
191 devices that were intended for one purpose end up being used for a
192 different one given the right context ((e.g. smart phone led light
193 turned out to be a heartrate monitor). IoT domain is currently
194 missing insights into what user actually expect.
196 4. What Problems to Solve
198 Although the workshop focused on a specific problem it became obvious
199 from the position papers that various organizations, industry groups
200 and individuals attempted to solve different problems. At least the
201 following goals have been described:
203 o Formal Languages for Documentation Purposes
205 Standardization organizations are in the need for a more formal
206 description of their information and data models in order to simplify
207 review, and publication. For example, the Open Mobile Alliance (OMA)
208 used an XML schema [LWM2M-Schema] to describe their object
209 definitions (i.e., data model) as XML instance documents. These XML
210 documents offer an alternative way of describing objects compared to
211 the tabular representation found in the specification itself. The
212 XML files of standardized objects are available for download at
213 [OMNA]. Furthermore, a tool is offered to define new objects and
214 resources. The online editor tool can be found at [OMA-Editor].
216 o Formal Languages for Code Generation
218 Formal data and information modelling languages for use by developers
219 to enable code generation. For example, the Allseen Visual Studio
220 Plugin [Allseen-Plugin] offers a wizzard to generate code based on
221 the formal description of the data model. Another example of a data
222 modelling language that can be used for code generation is YANG. A
223 popular tool to help with code generation of YANG modules is pyang
224 [PYANG].
226 o Debugging Support
228 Ability to allow debugging tools to implement generic object browsers
229 by utilizing the standardized information and data model. Example:
230 NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer].
232 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
239 Allow IoT devices to exchange information, potentially along with the
240 data exchange, to discover meta-data about the data and, potentially,
241 even a self-describing interaction model. An example of such an
242 approach has been shown with HATEOAS [HATEOAS].
244 5. Translation
246 One of the targets of interoperability is to create translators
247 between the data models. There are analogies with gateways back in
248 1985 when they were used to translate between network protocols,
249 eventually IP took over providing interoperability, however we lost
250 some of the features provided by those other protocols. The creation
251 of an equivalent "hub/s" that offer translation between the different
252 data models or data semantics seems one of the ways forward. Some
253 lose of expressiveness due to the translation between models seems
254 also unavoidable.
256 When it comes to translation two different distinctions appear:
257 translating data between data models and translating data models.
258 The first one implies doing the translation at runtime while the
259 second performs one translation between the data models one time,
260 like translating a YANG model to a RAML/JSON one. Indeed, for every
261 IM multiple DMs could be translated.
263 In a sense these distinctions affect as to when the translation is
264 performed. It can be done at "design time" when the information
265 model is done, it can be done at runtime for a concrete data model
266 and it can be done depending n the actual serialization.
268 Yet another distinction will appear depending on the requirements
269 from the application protocols, RPC-style ones might require a
270 slightly different DM than REST ones for similar operations, for
271 example SNMP-traps could be similar to CoAP-Observations but not
272 quite the same. It is easier to translate between systems that
273 follow the same architecture/design pattern than across
274 architectures, full translation might not even be possible (e.g.
275 stateless vsstateful systems).
277 Translation of models script to translate XML to YANG Translation of
278 serialized data, on a hub in order to normalize it to other data
279 model.
281 6. Dealing with change
283 A large part of the workshop was dedicated to the evolution of
284 devices and server side applications. Multiple of the participating
285 groups have defined data formats for data representation, however
286 interactions between devices and services and how their relationship
287 evolves over time is more related to the interaction model.
289 There are various approaches to it. In the most primitive case, a
290 developer will use a description of an API and implement whichever
291 are the protocol steps. In some cases the information model itself
292 can be used to generate some of the code stubs. Changes of an API
293 imply changes on the clients to upgrade to the new version, which
294 requires some development of new code to satisfy the needs of the new
295 API.
297 New, approaches imply that the whole interaction could be machine-
298 understandable on the first place with changes happening at runtime.
299 In it, a machine client can discover the possible interactions with a
300 service, adapting to changes as they occur without specific code
301 being developed to adapt to them.
303 The challenge seems to be to define the human-readable parts as
304 machine-readable. Machine-readable require a shared vocabulary to
305 give meaning to the tags.
307 These type of interactions are based on the The REST architectural
308 style. the principle is that the device or the endpoint, just needs a
309 single entry point, the server would provide descriptions of the API
310 inband by means of web links and forms.
312 By defining IoT specific relation types, it is possible to drive
313 interactions through links instead of hardcoding URIs into the
314 client, thus making the system flexible enough for later changes.
315 The definition of the basic hypermedia formats for IoT is still work
316 in progress, however some of the existing mechanism can be reused,
317 such as resource discovery, forms or links.
319 7. Acknowledgements
321 We would like to thank all paper authors and participants for their
322 contributions. Due to the large number of position paper submissions
323 we were unfortunately unable to invite every author; we would like to
324 apologize to those that could not attend the workshop.
326 8. Appendix A: Program Committee
328 This workshop was organized by the following individuals: Jari Arkko,
329 Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
330 Tschofenig.
332 9. Appendix B: Accepted Position Papers
334 1. Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
336 2. Carsten Bormann, "Noise in specifications hurts"
338 3. Benoit Claise, "YANG as the Data Modelling Language in the IoT
339 space"
341 4. Robert Cragie, "The ZigBee Cluster Library over IP"
343 5. Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair:
344 interoperable IoT services for major Building Automation and
345 Lighting Control ecosystems"
347 6. Universal Devices, "Object Oriented Approach to IoT
348 Interoperability"
350 7. Bryant Eastham, "Interoperability and the OpenDOF Project"
352 8. Stephen Farrell, Alissa Cooper, "It's Often True: Security's
353 Ignored (IOTSI) - and Privacy too"
355 9. Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT
356 semantics landscape"
358 10. Ted Hardie, "Loci of Interoperability for the Internet of
359 Things"
361 11. Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure
362 Communications"
364 12. Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart
365 Objects"
367 13. David Jones, IOTDB - "Interoperability Through Semantic
368 Metastandards"
370 14. Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler
371 of Semantic Interoperability on the Web of Things"
373 15. Achilleas Kemos, "Alliance for Internet of Things Innovation
374 Semantic Interoperability Release 2.0, AIOTI WG03 - IoT
375 Standardisation"
377 16. Ari Keraenen, Cullen Jennings, "SenML: simple building block for
378 IoT semantic interoperability"
380 17. Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on
381 Unified Data Model and Framework to Support Interoperability
382 between IoT Applications"
384 18. Michael Koster, "Model-Based Hypertext Language"
386 19. Matthias Kovatsch, Yassin N. Hassan, Klaus Hartke, "Semantic
387 Interoperability Requires self describing Interaction Models"
389 20. Kai Kreuzer, "A Pragmatic Approach to Interoperability in the
390 Internet of Things"
392 21. Barry Leiba, "Position Paper"
394 22. Marcello Lioy, "AllJoyn"
396 23. Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON
397 Hyper-Schema"
399 24. Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope
400 of security issues"
402 25. Open Geospatial Consortium, "OGC SensorThings API: Communicating
403 "Where" in the Web of Things"
405 26. Jean Paoli, Taqi Jaffri, "IoT Information Model
406 Interoperability: An Open, Crowd-Sourced Approach in Three
407 Parallel Parti"
409 27. Joaquin Prado, "OMA Lightweight M2M Resource Model"
411 28. Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic
412 Interoperability Workshop"
414 29. Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable
415 Data to Facilitate Time and Context Specific Interoperability"
417 30. Jasper Roes, Laura Daniele, "Towards semantic interoperability
418 in the IoT using the Smart Appliances REFerence ontology (SAREF)
419 and its extensions"
421 31. Max Senges, "Submission for IAB IoT Sematic Interoperability
422 workshop"
424 32. Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation
425 Experiences of Semantic Interoperability for RESTful Gateway
426 Management"
428 33. Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic
429 Interoperability Gaps in the Internet-of-Things Meta-Models"
431 34. Robert Sparks and Ben Campbell, "Considerations for certain IoT
432 based services"
434 35. J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
436 36. J. Clarke Stevens, Piper Merriam, "Derived Models for
437 Interoperability Between IoT Ecosystems"
439 37. Ravi Subramaniam, "Semantic Interoperability in Open
440 Connectivity Foundation (OCF) - formerly Open Interconnect
441 Consortium (OIC)""
443 38. Andrew Sullivan, "Position paper for IOTSI workshop"
445 39. Darshak Thakore, "IoT Security in the context of Semantic
446 Interoperability"
448 40. Dave Thaler, "IoT Bridge Taxonomy"
450 41. Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to
451 Semantic Interoperability"
453 42. Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski,
454 Mike Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram,
455 "Internet of Things: Toward Smart Networked Systems and
456 Societies"
458 43. Peter van der Stok, Andy Bierman, "YANG-Based Constrained
459 Management Interface (CoMI)"
461 10. Appendix C: List of Participants
463 o Andy Bierman, YumaWorks
465 o Carsten Bormann, Uni Bremen/TZI
467 o Ben Campbell, Oracle
468 o Benoit Claise, Cisco
470 o Alissa Cooper, Cisco
472 o Robert Cragie, ARM Limited
474 o Laura Daniele, TNO
476 o Bryant Eastham, OpenDof
478 o Christian Groves, Huawei
480 o Ted Hardie, Google
482 o Yonggeun Hong, ETRI
484 o Russ Housley, Vigil Security
486 o David Janes, IOTDB
488 o Jaime Jimenez, Ericsson
490 o Shailendra Karody, Catalina Labs
492 o Ari Keraenen, Ericsson
494 o Michael Koster, SmartThings
496 o Matthias Kovatsch, Siemens
498 o Kai Kreuzer, Deutsche Telekom
500 o Barry Leiba, Huawei
502 o Steve Liang, Uni Calgary
504 o Marcello Lioy, Qualcomm
506 o Kerry Lynn, Verizon
508 o Mayan Mathen, Catalina Labs
510 o Erik Nordmenk, Arista
512 o Jean Paoli, Microsoft
514 o Joaquin Prado, OMA
515 o Dave Raggett, W3C
517 o Max Senges, Google
519 o Ned Smith, Intel
521 o Robert Sparks, Oracle
523 o Ram Sriram, NIST
525 o Clarke Stevens
527 o Ram Subramanian, Intel
529 o Andrew Sullivan, DIN
531 o Darshak Thakore, Cablelabs
533 o Dave Thaler, Microsoft
535 o Hannes Tschofenig, ARM Limited
537 o Michael Verschoor, Philips Lightning
539 11. Informative References
541 [Allseen-Plugin]
542 Rockwell, B., "Using the AllJoyn Studio Extension",
543 https://channel9.msdn.com/Blogs/Internet-of-Things-Blog/
544 Using-the-AllJoyn--Studio-Extension , 2016.
546 [HATEOAS] Kovatsch, M., "Semantic Interoperability Requires
547 Selfdescribing Interaction Models - HATEOAS for the
548 Internet of Things", Proceedings of the IoT Semantic
549 Interoperability Workshop 2016, 2016.
551 [IOTSIAG] IAB, "IoT Workshop for Semantic Interoperability (IOTSI) -
552 Agenda and Slides", 2016,
553 .
555 [IOTSIGIT]
556 IOTSI, "Github Collaborative Repository", 2016,
557 .
559 [IOTSIWS] IAB, "IoT Workshop for Semantic Interoperability (IOTSI)
560 2016 - Main Page and Position Papers", 2016,
561 .
563 [LWM2M-Schema]
564 OMA, "OMA LWM2M XML Schema",
565 http://technical.openmobilealliance.org/tech/profiles/
566 LWM2M.xsd , 2016.
568 [OMA-Editor]
569 OMA, "OMA LWM2M Object and Resource Editor",
570 http://dev_devtoolkit.openmobilealliance.org/OEditor/ ,
571 2016.
573 [OMNA] OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource
574 Registry",
575 http://technical.openmobilealliance.org/Technical/
576 technical-information/omna/
577 lightweight-m2m-lwm2m-object-registry , 2016.
579 [PYANG] Bjorklund, M., "An extensible YANG validator and converter
580 in python", https://github.com/mbj4668/pyang , 2016.
582 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
583 Information Models and Data Models", RFC 3444, DOI
584 10.17487/RFC3444, January 2003,
585 .
587 [UDI] Kohanim, M., "Object Oriented Approach to IoT
588 Interoperability", Proceedings of the IoT Workshop for
589 Semantic Interoperability (IOTSI), 2016.
591 [nRF-Sniffer]
592 Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low
593 energy packet sniffer",
594 https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-
595 Bluetooth-low-energy/nRF-Sniffer , 2016.
597 Authors' Addresses
599 Jaime Jimenez
600 Ericsson
602 Email: jaime.jimenez@ericsson.com
604 Hannes Tschofenig
605 ARM
607 Email: hannes.tschofenig@arm.com
608 Dave Thaler
609 Microsoft
611 Email: dthaler@microsoft.com