[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 RFC 8477

Network Working Group                                         J. Jimenez
Internet-Draft
Intended status: Informational                             H. Tschofenig
Expires: November 25, 2016
                                                               D. Thaler

                                                            May 24, 2016


   Report from the Internet of Things (IoT) Semantic Interoperability
                         (IOTSI) Workshop 2016
                     draft-iab-iotsi-workshop-00.txt

Abstract

   This document provides a summary of the 'Workshop on Internet of
   Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIWS], which took
   place in Santa Clara, CA, on 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 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 and
   the Internet Architecture Board (IAB), which organized the workshop.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 25, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Jimenez, et al.         Expires November 25, 2016               [Page 1]


Internet-Draft                    IOTSI                         May 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  What Problems to Solve  . . . . . . . . . . . . . . . . . . .   5
   5.  Translation . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Runtime Discovery . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Appendix A: Program Committee . . . . . . . . . . . . . . . .   9
   9.  Appendix B: Accepted Position Papers  . . . . . . . . . . . .   9
   10. Appendix C: List of Participants  . . . . . . . . . . . . . .  12
   11. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Internet Architecture Board (IAB) holds occasional workshops
   designed to consider long-term issues and strategies for the
   Internet, and to suggest future directions for the Internet
   architecture.  The investigated topics often require coordinated
   efforts of many organizations and industry bodies to improve an
   identified problem.  One of the targets of the workshops is to
   establish communication between relevant organizations, specially
   when the topics are out of the scope for the Internet Engineering
   Task Force (IETF).  This long-term planning function of the IAB is
   complementary to the ongoing engineering efforts performed by working
   groups of the IETF.

   Increasing interoperability in the area of Internet of Things (IoT)
   has been a top priority for many standards organizations and
   pariticularly the lower layers of the Internet protocol stack have
   received a lot of attention.  Also at the application layer, such as
   with CoAP and HTTP, there is a trend in reusing RESTful design
   patterns.  However, data exchanged on top of these application layer
   protocols there is still a lot of fragmentation and the same degree
   of increase in interoperability has not been observed.




Jimenez, et al.         Expires November 25, 2016               [Page 2]


Internet-Draft                    IOTSI                         May 2016


   Thus, the IAB decided to organize a workshop to reach out to relevant
   stakeholders to explore the state-of-the-art and to identify
   communality and gaps.

   o  The different perceived state of the art on data and information
      models.

   o  The lack of an encoding-independent standardization of the
      information, the so-called information model.

   o  The strong relationship with the underlying communication pattern,
      such as remote procedure calls (RPC), publish/subscribe or RESTful
      designs.

   o  Identifying which similar concepts groups have develop in
      parallel, specially those that would require only slight
      modifications to solve interoperability.

   o  Identifying how existing data models can be mapped against each
      other to offer inter working.

   o  Identifying common use cases for cooperation and harmonization.

2.  Terminology

   The first roadblock to semantic interoperability is the lack of a
   common vocabulary to start the discussion.  There is a need to align
   between participating organizations on a common set of basic terms.
   [RFC3444] does a start by separating conceptual models for designers
   or Information Models (IMs) and concrete detailed definitions for
   implementors or Data Models (DMs).  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 could be identified were:

   Information Model (IM)  it defines an environment at the highest
      level of abstraction, they express the desired functionality.
      They can be defined informally (e.g. in plain English) or more
      formally (e.g.  UML, Entity-Relationship Diagrams, etc.).
      Implementation details are hidden.

   Data Model (DM)  it defines concrete data representations at a lower
      level of abstraction, including implementation and protocol-
      specific details.  Some examples are: SNMP Management Information
      Base (MIBs), W3C Thing Description (TD) Things, YANG models, LWM2M
      Schemas, OCF Schemas and so on.





Jimenez, et al.         Expires November 25, 2016               [Page 3]


Internet-Draft                    IOTSI                         May 2016


   Interaction Model (IN)  it 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.  Meaning will vary depending on the context the
   term is used.  Some examples of such terms are: semantics, models,
   encoding, serialization format, media types or encoding types.  Due
   to time constraints no concrete terminology was agreed upon, however
   work will continue within each organization to create various
   terminology documents, see [IOTSIGIT].

3.  Architecture

   Architectures follow different design patterns, some are REST-
   oriented with clear methods to find and manipulate resources on
   endpoints with almost no state kept between them.  Others are more
   Publish/Subscribe-oriented that focus on the flow of information
   based on the topics of the information that is being shared.  Others
   are RPC-like requiring to know beforehand the set of parameters that
   are accessed, requiring to generate code both on the client and
   server side, they are tightly coupled and service-oriented.

   Thing-hub-cloud  things talk to a hub, which talks back to them and
      to the cloud.  There is a spectrum of emphasis on the hub vs. the
      cloud.  For some the hub is simply an access point; for others it
      is a critical place for control loops and ALGs.

   Meta Thing  some things are actually virtual, like an alarm composed
      of clock, lights, and thermostat.

   Nearby things  some things may be geospatially related even if they
      are not on the same network or within the same administrative
      domain.

   Current data models and definitions for "things" often focus on
   defining actual physical devices and representing their state.  That
   focus should perhaps be shifted into a more holistic or user-oriented
   perspective, defining abstract concepts as well.  On the other a lot
   of focus is placed on human interaction with physical devices while
   IoT will be more oriented to interaction between "things" instead.

   Those things should be designed to be multiple-purpose, keeping in
   mind that solutions should be open-ended to facilitate new usages and
   new future domains of operation. this pattern has already happened,
   devices that were intended for one purpose end up being used for a
   different one given the right context ((e.g. smart phone led light



Jimenez, et al.         Expires November 25, 2016               [Page 4]


Internet-Draft                    IOTSI                         May 2016


   turned out to be a heartrate monitor).  IoT domain is currently
   missing insights into what user actually expect.

4.  What Problems to Solve

   Although the workshop focused on a specific problem it became obvious
   from the position papers that various organizations, industry groups
   and individuals attempted to solve different problems.  At least the
   following goals have been described:

   o  Formal Languages for Documentation Purposes

   Standardization organizations are in the need for a more formal
   description of their information and data models in order to simplify
   review, and publication.  For example, the Open Mobile Alliance (OMA)
   used an XML schema [LWM2M-Schema] to describe their object
   definitions (i.e., data model) as XML instance documents.  These XML
   documents offer an alternative way of describing objects compared to
   the tabular representation found in the specification itself.  The
   XML files of standardized objects are available for download at
   [OMNA].  Furthermore, a tool is offered to define new objects and
   resources.  The online editor tool can be found at [OMA-Editor].

   o  Formal Languages for Code Generation

   Formal data and information modelling languages for use by developers
   to enable code generation.  For example, the Allseen Visual Studio
   Plugin [Allseen-Plugin] offers a wizzard to generate code based on
   the formal description of the data model.  Another example of a data
   modelling language that can be used for code generation is YANG.  A
   popular tool to help with code generation of YANG modules is pyang
   [PYANG].

   o  Debugging Support

   Ability to allow debugging tools to implement generic object browsers
   by utilizing the standardized information and data model.  Example:
   NRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer].

   o  Translation

   The ability for gateways and other similar devices to dynamically
   translate (or map) one data model to another one.  An example of this
   idea can be found in [UDI].

   o  Runtime Discovery





Jimenez, et al.         Expires November 25, 2016               [Page 5]


Internet-Draft                    IOTSI                         May 2016


   Allow IoT devices to exchange information, potentially along with the
   data exchange, to discover meta-data about the data and, potentially,
   even a self-describing interaction model.  An example of such an
   approach has been shown with HATEOS [HATEOS].

5.  Translation

   One of the targets of interoperability is to create translators
   between the data models.  There are analogies with gateways back in
   1985 when they were used to translate between network protocols,
   eventually IP took over providing interoperability, however we lost
   some of the features provided by those other protocols.  The creation
   of an equivalent "hub/s" that offer translation between the different
   data models or data semantics seems one of the ways forward.  Some
   lose of expressiveness due to the translation between models seems
   also unavoidable.

   When it comes to translation two different distinctions appear:
   translating data between data models and translating data models.
   The first one implies doing the translation at runtime while the
   second performs one translation between the data models one time,
   like translating a YANG model to a RAML/JSON one.  Indeed, for every
   IM multiple DMs could be translated.

   In a sense these distinctions affect as to when the translation is
   performed.  It can be done at "design time" when the information
   model is done, it can be done at runtime for a concrete data model
   and it can be done depending n the actual serialization.

   Yet another distinction will appear depending on the requirements
   from the application protocols, RPC-style ones might require a
   slightly different DM than REST ones for similar operations, for
   example SNMP-traps could be similar to CoAP-Observations but not
   quite the same.  It is easier to translate between systems that
   follow the same architecture/design pattern than across
   architectures, full translation might not even be possible (e.g.
   stateless vs stateful systems).

   Translation of models script to translate XML to YANG Translation of
   serialized data, on a hub in order to normalize it to other data
   model.

6.  Runtime Discovery

   Runtime changes are doing after design and at compile time.
   Discovery, is it devices or data items on devices.  A lot of people
   think about devices but also abstract entities.  To do discovery one
   question is "how much must "be shared before time.  The meta-data has



Jimenez, et al.         Expires November 25, 2016               [Page 6]


Internet-Draft                    IOTSI                         May 2016


   also two possible notions, is it instance specific (e.g. location of
   the thing) or does it have to do with the model itself?

   Need to handle change in the environment.  Replace things without
   manual configuration, change control flow, etc. at runtime.  Few
   things (vocabulary) is shared a priori.  Drives the application
   runtime, "Engine of application state", we needs self-describing
   interaction models.  Ravi: nothing prevents HATEOAS + data model Ari:
   And OMA LwM2M uses SenML Matthias: these are complementary
   approaches.  It is to point out that it is also about Interaction
   Models.  Of course DM are needed to convey data.

   Interaction model

   You get one entry point (in CoAP it is the RD) and the client tries
   to perform discovery in order to find and follow links in order to
   discover capabilities.  You submit forms to interact with them.  This
   way you can create processes that span over multiple devices involved
   in the process.  If later one you find that you need something else,
   you can add new functionality at runtime, next client that comes
   along will have the same logic but see different capabilities of
   functionality and therefore use it.

   Parts of the information have to be shared a priori.  The process is
   incremental, but once discovered, you don't need to perform the same
   operation every time, you can go to the bookmark.

   The following are examples of all those in HTML.























Jimenez, et al.         Expires November 25, 2016               [Page 7]


Internet-Draft                    IOTSI                         May 2016


   // Links (Anchors) with human-readable information
   <a href="about.html">More information</a>
   <link rel="stylesheet" href="style.css">

   // Templated Links to perform a query with a parameter.
   <form method="get" action="search.php">
     <input id="query" type="text">
   </form>

   // Embedded Links which are used to embed other resources.
   <img src="logo.png">
   <audio src="audio.ogg">
   <video src="video.mp4">

   // Forms with the concrete method to be used and the
   <form method="post" action="">
     <input id="name" type="text">
     <input id="age" type="text">
     <input id="homepage" type="text">
   </form>

   The challenge is to define the human-readable parts as machine-
   readable.  For that a vocabulary is necessary to give meaning to the
   tags.  Such information needs to be share beforehand.

   In some models everything has to be shared from the beginning,
   therefore any change would involve changing the whole "framework".
   By forcing to share only the bare minimum, you avoid such problem.

   Some organizations have created predefined interfaces, all of them
   are predefined and described, they even provide code generation.  The
   device logic has to support such interfaces, no changes are possible
   at runtime.

   Data models have common elements that have the property of
   composition.  Often alliances provide repositories for data models,
   static definitions of "things" and how to composed them.  With links
   and composition, you can create more dynamic interactions and
   describe the environment so that it is discovered in runtime.  On top
   of that there can be annotations with the notion of interfaces.
   There are also discovery mechanisms where anything related to the
   state of a thing can be discovered.

   You have to know the vocabulary used a priori, basic assumptions for
   discovery, there is a handle that will point.






Jimenez, et al.         Expires November 25, 2016               [Page 8]


Internet-Draft                    IOTSI                         May 2016


   The challenge is to have the features that are exposed and modeled
   (DM and IM) and to keep the backwards compatibility.  As well as
   having the capability to provide new features in the future.

   All of this is done in the case that we want to have something better
   than just having firmware updates every time.

   BLE they have an additional discovery services and some metadata that
   refers to the data type.  A generic client could understand some of
   the characteristics.  The interaction model is not something to be
   easily reconstructed.  With HATEOAS and OCF's approach, it seems that
   you can learn how to interact with the device with that metadata.
   Let's say that we don't need that crap, it is not useful.  If someone
   wants a device he can just download some software and use it. for
   some of the use cases it is needed. if I buy a heart rate monitor. i
   can do that as a developer i dont want to use that.  It is also
   needed to keep the support the prior features.  Also if I want to
   change vendor.  The notion is that after discovery I know how to use
   it eve if I don't know what it is.

   It depends also on how do you see the programming environment.
   translation from one data model to another. gw sucks the code and
   does the translation. ar esome of the language so powerful to do
   that? prototype to do something

7.  Acknowledgements

   We would like to thank all paper authors and participants for their
   contributions.  Due to the large number of position paper submissions
   we were unfortunately unable to invite every author; we would like to
   apologize to those that could not attend the workshop.

8.  Appendix A: Program Committee

   This workshop was organized by the following individuals: Jari Arkko,
   Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes
   Tschofenig.

9.  Appendix B: Accepted Position Papers

   1.   Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"

   2.   Carsten Bormann, "Noise in specifications hurts"

   3.   Benoit Claise, "YANG as the Data Modelling Language in the IoT
        space"

   4.   Robert Cragie, "The ZigBee Cluster Library over IP"



Jimenez, et al.         Expires November 25, 2016               [Page 9]


Internet-Draft                    IOTSI                         May 2016


   5.   Dee Denteneer, Michael Verschoor, Teresa Zotti, "Fairhair:
        interoperable IoT services for major Building Automation and
        Lighting Control ecosystems"

   6.   Universal Devices, "Object Oriented Approach to IoT
        Interoperability"

   7.   Bryant Eastham, "Interoperability and the OpenDOF Project"

   8.   Stephen Farrell, Alissa Cooper, "It's Often True: Security's
        Ignored (IOTSI) - and Privacy too"

   9.   Christian Groves, Lui Yan, ang Weiwei, "Overview of IoT
        semantics landscape"

   10.  Ted Hardie, "Loci of Interoperability for the Internet of
        Things"

   11.  Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure
        Communications"

   12.  Jaime Jimenez, Michael Koster, Hannes Tschofenig, "IPSO Smart
        Objects"

   13.  David Jones, IOTDB - "Interoperability Through Semantic
        Metastandards"

   14.  Sebastian Kaebisch, Darko Anicic, "Thing Description as Enabler
        of Semantic Interoperability on the Web of Things"

   15.  Achilleas Kemos, "Alliance for Internet of Things Innovation
        Semantic Interoperability Release 2.0, AIOTI WG03 - IoT
        Standardisation"

   16.  Ari Keraenen, Cullen Jennings, "SenML: simple building block for
        IoT semantic interoperability"

   17.  Dongmyoung Kim, Yunchul Choi, Yonggeun Hong, "Research on
        Unified Data Model and Framework to Support Interoperability
        between IoT Applications"

   18.  Michael Koster, "Model-Based Hypertext Language"

   19.  Matthias Kovatsch, Yassin N.  Hassan, Klaus Hartke, "Semantic
        Interoperability Requires Self-describing Interaction Models"

   20.  Kai Kreuzer, "A Pragmatic Approach to Interoperability in the
        Internet of Things"



Jimenez, et al.         Expires November 25, 2016              [Page 10]


Internet-Draft                    IOTSI                         May 2016


   21.  Barry Leiba, "Position Paper"

   22.  Marcello Lioy, "AllJoyn"

   23.  Kerry Lynn, Laird Dornin, "Modeling RESTful APIs with JSON
        Hyper-Schema"

   24.  Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope
        of security issues"

   25.  Open Geospatial Consortium, "OGC SensorThings API: Communicating
        "Where" in the Web of Things"

   26.  Jean Paoli, Taqi Jaffri, "IoT Information Model
        Interoperability: An Open, Crowd-Sourced Approach in Three
        Parallel Parti"

   27.  Joaquin Prado, "OMA Lightweight M2M Resource Model"

   28.  Dave Raggett, Soumya Kanti Datta, "Input paper for IAB Semantic
        Interoperability Workshop"

   29.  Pete Rai, Stephen Tallamy, "Semantic Overlays Over Immutable
        Data to Facilitate Time and Context Specific Interoperability"

   30.  Jasper Roes, Laura Daniele, "Towards semantic interoperability
        in the IoT using the Smart Appliances REFerence ontology (SAREF)
        and its extensions"

   31.  Max Senges, "Submission for IAB IoT Sematic Interoperability
        workshop"

   32.  Bill Silverajan, Mert Ocak, Jaime Jimenez, "Implementation
        Experiences of Semantic Interoperability for RESTful Gateway
        Management"

   33.  Ned Smith, Jeff Sedayao, Claire Vishik, "Key Semantic
        Interoperability Gaps in the Internet-of-Things Meta-Models"

   34.  Robert Sparks and Ben Campbell, "Considerations for certain IoT
        based services"

   35.  J.  Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"

   36.  J.  Clarke Stevens, Piper Merriam, "Derived Models for
        Interoperability Between IoT Ecosystems"





Jimenez, et al.         Expires November 25, 2016              [Page 11]


Internet-Draft                    IOTSI                         May 2016


   37.  Ravi Subramaniam, "Semantic Interoperability in Open
        Connectivity Foundation (OCF) - formerly Open Interconnect
        Consortium (OIC)""

   38.  Andrew Sullivan, "Position paper for IOTSI workshop"

   39.  Darshak Thakore, "IoT Security in the context of Semantic
        Interoperability"

   40.  Dave Thaler, "IoT Bridge Taxonomy"

   41.  Dave Thaler, S"ummary of AllSeen Alliance Work Relevant to
        Semantic Interoperability"

   42.  Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski,
        Mike Bennett, Gary Berg-Cross, Torsten Hahmann, Ram Sriram,
        "Internet of Things: Toward Smart Networked Systems and
        Societies"

   43.  Peter van der Stok, Andy Bierman, "YANG-Based Constrained
        Management Interface (CoMI)"

10.  Appendix C: List of Participants

   o  Andy Bierman, YumaWorks

   o  Carsten Bormann, Uni Bremen/TZI

   o  Ben Campbell, Oracle

   o  Benoit Claise, Cisco

   o  Alissa Cooper, Cisco

   o  Robert Cragie, ARM Limited

   o  Laura Daniele, TNO

   o  Bryant Eastham, OpenDof

   o  Christian Groves, Huawei

   o  Ted Hardie, Google

   o  Yonggeun Hong, ETRI

   o  Russ Housley, Vigil Security




Jimenez, et al.         Expires November 25, 2016              [Page 12]


Internet-Draft                    IOTSI                         May 2016


   o  David Janes, IOTDB

   o  Jaime Jimenez, Ericsson

   o  Shailendra Karody, Catalina Labs

   o  Ari Keraenen, Ericsson

   o  Michael Koster, SmartThings

   o  Matthias Kovatsch, Siemens

   o  Kai Kreuzer, Deutsche Telekom

   o  Barry Leiba, Huawei

   o  Steve Liang, Uni Calgary

   o  Marcello Lioy, Qualcomm

   o  Kerry Lynn, Verizon

   o  Mayan Mathen, Catalina Labs

   o  Erik Nordmenk, Arista

   o  Jean Paoli, Microsoft

   o  Joaquin Prado, OMA

   o  Dave Raggett, W3C

   o  Max Senges, Google

   o  Ned Smith, Intel

   o  Robert Sparks, Oracle

   o  Ram Sriram, NIST

   o  Clarke Stevens

   o  Ram Subramanian, Intel

   o  Andrew Sullivan, DIN

   o  Darshak Thakore, Cablelabs




Jimenez, et al.         Expires November 25, 2016              [Page 13]


Internet-Draft                    IOTSI                         May 2016


   o  Dave Thaler, Microsoft

   o  Hannes Tschofenig, ARM Limited

   o  Michael Verschoor, Philips Lightning

11.  Informative References

   [Allseen-Plugin]
              Rockwell, B., "Using the AllJoyn Studio Extension",
              https://channel9.msdn.com/Blogs/Internet-of-Things-Blog/
              Using-the-AllJoyn--Studio-Extension , 2016.

   [HATEOS]   Kovatsch, M., "Semantic Interoperability Requires
              Self&#173;describing Interaction Models - HATEOAS for the
              Internet of Things", Proceedings of the IoT Semantic
              Interoperability Workshop 2016, 2016.

   [IOTSIAG]  IAB, "IoT Workshop for Semantic Interoperability (IOTSI) -
              Agenda and Slides", 2016,
              <https://www.iab.org/activities/workshops/iotsi/agenda/>.

   [IOTSIGIT]
              IOTSI, "Github Collaborative Repository", 2016,
              <https://github.com/iotsi>.

   [IOTSIWS]  IAB, "IoT Workshop for Semantic Interoperability (IOTSI)
              2016 - Main Page and Position Papers", 2016,
              <https://www.iab.org/activities/workshops/iotsi/>.

   [LWM2M-Schema]
              OMA, "OMA LWM2M XML Schema",
              http://technical.openmobilealliance.org/tech/profiles/
              LWM2M.xsd , 2016.

   [OMA-Editor]
              OMA, "OMA LWM2M Object and Resource Editor",
              http://dev_devtoolkit.openmobilealliance.org/OEditor/ ,
              2016.

   [OMNA]     OMA, "OMNA Lightweight M2M (LWM2M) Object & Resource
              Registry",
              http://technical.openmobilealliance.org/Technical/
              technical-information/omna/
              lightweight-m2m-lwm2m-object-registry , 2016.

   [PYANG]    Bjorklund, M., "An extensible YANG validator and converter
              in python", https://github.com/mbj4668/pyang , 2016.



Jimenez, et al.         Expires November 25, 2016              [Page 14]


Internet-Draft                    IOTSI                         May 2016


   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, DOI
              10.17487/RFC3444, January 2003,
              <http://www.rfc-editor.org/info/rfc3444>.

   [UDI]      Kohanim, M., "Object Oriented Approach to IoT
              Interoperability", Proceedings of the IoT Workshop for
              Semantic Interoperability (IOTSI), 2016.

   [nRF-Sniffer]
              Nordic Semiconductor, "nRF Sniffer - Smart/Bluetooth low
              energy packet sniffer",
              https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-
              Bluetooth-low-energy/nRF-Sniffer , 2016.

Authors' Addresses

   Jaime Jimenez

   Email: jaime.jimenez@ericsson.com


   Hannes Tschofenig

   Email: hannes.tschofenig@arm.com


   Dave Thaler

   Email: dthaler@microsoft.com





















Jimenez, et al.         Expires November 25, 2016              [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/