GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8477

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

Abstract

 This 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.

Jimenez, et al. Informational [Page 1] RFC 8477 IOTSI Workshop 2016 October 2018

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.

Table of Contents

 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

Jimenez, et al. Informational [Page 2] RFC 8477 IOTSI Workshop 2016 October 2018

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 from many organizations and industry bodies to improve an
 identified problem.  One of the targets of the workshops is to
 establish communication between relevant organizations, especially
 when the topics are out of the scope of 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.
 With the expansion of the Internet of Things (IoT), interoperability
 becomes more and more important.  Standards Developing Organizations
 (SDOs) have done a tremendous amount of work to standardize new
 protocols and profile existing protocols.
 At the application layer and at the level of solution frameworks,
 interoperability is not yet mature.  Particularly, the work on data
 formats (in the form of data models and information models) has not
 seen the same level of consistency throughout SDOs.
 One common problem is the lack of an encoding-independent
 standardization of the information, the so-called information model.
 Another problem is the strong relationship between data formats and
 the underlying communication architecture, such as a design in Remote
 Procedure Call (RPC) style or a RESTful design (where REST refers to
 Representational State Transfer).  Furthermore, groups develop
 solutions that are very similar on the surface but differ slightly in
 their standardized outcome, leading to interoperability problems.
 Finally, some groups favor different encodings for use with various
 application-layer protocols.
 Thus, the IAB decided to organize a workshop to reach out to relevant
 stakeholders to explore the state of the art and identify commonality
 and gaps [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?

Jimenez, et al. Informational [Page 3] RFC 8477 IOTSI Workshop 2016 October 2018

 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?

2. Terminology

 The first roadblock to interoperability at the level of data models
 is the lack of a common vocabulary to start the discussion.
 [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.

Jimenez, et al. Informational [Page 4] RFC 8477 IOTSI Workshop 2016 October 2018

 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.

3. What Problems to Solve

 The participants agreed that there is not simply a single problem to
 be solved but rather a range of problems.  During the workshop, the
 following problems were discussed:
 o  Formal Languages for Documentation Purposes
 To simplify review and publication, SDOs need formal descriptions of
 their data and interaction models.  Several of them use a tabular
 representation found in the specification itself but use a formal
 language as an alternative way of describing objects and resources
 for formal purposes.  Some examples of formal language use are as
 follows.
 The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema
 [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>.

Jimenez, et al. Informational [Page 5] RFC 8477 IOTSI Workshop 2016 October 2018

 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

Jimenez, et al. Informational [Page 6] RFC 8477 IOTSI Workshop 2016 October 2018

 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.

4. Translation

 In an ideal world where organizations and companies cooperate and
 agree on a single data model standard, there is no need for gateways
 that translate from one data model to another one.  However, this is
 far from reality today, and there are many proprietary data models in
 addition to the already standardized ones.  As a consequence,
 gateways are needed to translate between data models.  This leads to
 (n^2)-n combinations, in the worst case.
 There are analogies with gateways back in the 1980s that were used to
 translate between network layer protocols.  Eventually, IP took over,
 providing the necessary end-to-end interoperability at the network
 layer.  Unfortunately, the introduction of gateways leads to the loss

Jimenez, et al. Informational [Page 7] RFC 8477 IOTSI Workshop 2016 October 2018

 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?

Jimenez, et al. Informational [Page 8] RFC 8477 IOTSI Workshop 2016 October 2018

 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.

5. Dealing with Change

 A large part of the workshop was dedicated to the evolution of
 devices and server-side applications.  Interactions between devices
 and services and how their relationship evolves over time is
 complicated by their respective interaction models.
 The workshop participants discussed various approaches to deal with
 change.  In the most basic case, a developer might use a description
 of an API and implement the protocol steps.  Sometimes, the data or

Jimenez, et al. Informational [Page 9] RFC 8477 IOTSI Workshop 2016 October 2018

 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.

6. IANA Considerations

 This document has no IANA actions.

7. Security Considerations

 There were two types of security considerations discussed: use of
 formal data models for security configuration and security of data
 and data models in general.
 It was observed that the security assumptions and configuration, or
 "security model", varies by ecosystem today, making the job of a
 translator difficult.  For example, there are different types of
 security principals (e.g., user vs. device vs. application), the use
 of Access Control Lists (ACLs) versus capabilities, and what types of
 policies can be expressed, all vary by ecosystem.  As a result, the
 security model architecture generally dictates where translation can
 be done.

Jimenez, et al. Informational [Page 10] RFC 8477 IOTSI Workshop 2016 October 2018

 One approach discussed was whether two endpoints might be able to use
 some overlay security model across a translator between two
 ecosystems, which only works if the two endpoints agree on a common
 data model for their communication.  Another approach discussed was
 simply having a translator act as a trusted intermediary, which
 enables the translator to translate between different data models.
 One suggestion discussed was either adding metadata into the formal
 data model language or having it accompany the data values over the
 wire, tagging the data with privacy levels.  However, sometimes even
 the privacy level of information might itself be sensitive.  Still,
 it was observed that being able to dynamically learn security
 requirements might help provide better UIs and translators.

8. Collaboration

 The participants discussed how best to share information among their
 various organizations.  One discussion was around having joint
 meetings.  One current challenge reported was that organizations were
 not aware of when and where each other's meetings were scheduled, and
 sharing such information could help organizations better collocate
 meetings.  To facilitate this exchange, the participants agreed to
 add links to their respective meeting schedules from a common page in
 the IOTSI repository [IOTSIGIT].
 Another challenge reported was that organizations did not know how to
 find each other's published data models, and sharing such information
 could better facilitate reuse of the same information model.  To
 facilitate this exchange, the participants discussed whether a common
 repository might be used by multiple organizations.  The OCF's
 oneIoTa repository was discussed as one possibility, but it was
 reported that its terms of use at the time of the workshop prevented
 this.  The OCF agreed to take this back and look at updating the
 terms of use to allow other organizations to use it, as the
 restriction was not the intent.  <schema.org> was discussed as
 another possibility.  In the meantime, the participants agreed to add
 links to their respective repositories from a common page in the
 IOTSI repository [IOTSIGIT].
 It was also agreed that the iotsi@iab.org mailing list would remain
 open and available for sharing information between all relevant
 organizations.

Jimenez, et al. Informational [Page 11] RFC 8477 IOTSI Workshop 2016 October 2018

9. Informative References

 [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".

Jimenez, et al. Informational [Page 12] RFC 8477 IOTSI Workshop 2016 October 2018

 [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>.

Jimenez, et al. Informational [Page 13] RFC 8477 IOTSI Workshop 2016 October 2018

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.

Appendix B. Accepted Position Papers

 o  Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
 o  Carsten Bormann, "Noise in Specifications hurts"
 o  Benoit Claise, "YANG as the Data Modelling Language in the IoT
    space"
 o  Robert Cragie, "The ZigBee Cluster Library over IP"
 o  Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair:
    interoperable IoT services for major Building Automation and
    Lighting Control ecosystems"
 o  Universal Devices, "Object Oriented Approach to IoT
    Interoperability"
 o  Bryant Eastham, "Interoperability and the OpenDOF Project"
 o  Stephen Farrell and Alissa Cooper, "It's Often True: Security's
    Ignored (IOTSI) - and Privacy too"
 o  Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT
    semantics landscape"
 o  Ted Hardie, "Loci of Interoperability for the Internet of Things"
 o  Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure
    Communications"
 o  Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart
    Objects"
 o  David Jones, "IOTDB - interoperability Through Semantic
    Metastandards"
 o  Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler
    of Semantic Interoperability on the Web of Things"

Jimenez, et al. Informational [Page 14] RFC 8477 IOTSI Workshop 2016 October 2018

 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"

Jimenez, et al. Informational [Page 15] RFC 8477 IOTSI Workshop 2016 October 2018

 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)"

Jimenez, et al. Informational [Page 16] RFC 8477 IOTSI Workshop 2016 October 2018

Appendix C. List of Participants

    Andy Bierman, YumaWorks
    Carsten Bormann, Uni Bremen/TZI
    Ben Campbell, Oracle
    Benoit Claise, Cisco
    Alissa Cooper, Cisco
    Robert Cragie, ARM Limited
    Laura Daniele, TNO
    Bryant Eastham, OpenDOF
    Christian Groves, Huawei
    Ted Hardie, Google
    Yonggeun Hong, ETRI
    Russ Housley, Vigil Security
    David Janes, IOTDB
    Jaime Jimenez, Ericsson
    Shailendra Karody, Catalina Labs
    Ari Keraenen, Ericsson
    Michael Koster, SmartThings
    Matthias Kovatsch, Siemens
    Kai Kreuzer, Deutsche Telekom
    Barry Leiba, Huawei
    Steve Liang, Uni Calgary
    Marcello Lioy, Qualcomm
    Kerry Lynn, Verizon
    Mayan Mathen, Catalina Labs
    Erik Nordmark, Arista
    Jean Paoli, Microsoft
    Joaquin Prado, OMA
    Dave Raggett, W3C
    Max Senges, Google
    Ned Smith, Intel
    Robert Sparks, Oracle
    Ram Sriram, NIST
    Clarke Stevens
    Ram Subramanian, Intel
    Andrew Sullivan, DIN
    Darshak Thakore, CableLabs
    Dave Thaler, Microsoft
    Hannes Tschofenig, ARM Limited
    Michael Verschoor, Philips Lighting

Jimenez, et al. Informational [Page 17] RFC 8477 IOTSI Workshop 2016 October 2018

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

Acknowledgements

 We would like to thank all paper authors and participants for their
 contributions and Ericsson for hosting the workshop.

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. Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8477.txt · Last modified: 2018/10/19 18:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki