Preparing for IoT Semantic Interoperability Workshop 2016 workshop, let me make a couple of statements, more in the form of short bullets list, or demonstration. These points can developed during the workshop.

Disclaimer: this paper only represents my personal views.

1. We should make a (terminology) distinction between data modeling language, data model, encoding, protocol, and programming language.

• Information model:
  • see RFC 3444.
  • Example: UML
• Data modeling language:
  • Example: YANG (RFC 6020), SMIv2 (RFC 2578)
• Data model:
  • See RFC 3444.
  • Example: YANG data models, MIB modules
• Encoding:
  • Example: XML, JSON, CBOR, ASN.1, protobuf
• Protocol:
  • Example: NETCONF, RESTCONF, CoAP, CoMI, SNMP, gRPC
• Programming language:
  • Example: C, C++, python, java, etc.

2. When I look at the scale and frequency of changes in today network (and not only IoT), I hope that nobody disputes the fact that automation and programmability are required.

3. I hope that the industry will standardize on a single data modeling language for the IoT collection technologies, so that no mapping between data models would be required. As a consequence, I consider information models as an extra unnecessary step, which would delay standardization. Indeed, the information models are not consumable for that automation. Granted, there is an effort to map YANG from UML, including an opensource tool, but the point remains: the end goal for automation is data models. This workshop is about information model and data models. My question is: why do we need to spend time at all on information models? When I speak to some operators, they tell me: “don’t provide me with information models; I need data models, i.e. something I can consume for automation”.

4. The IETF has been standardizing as the YANG as THE data modeling language, not only for configuration but also for operational status.
Those YANG data models can be specified in different encodings (XML, JSON) and in different protocols (NETCONF with XML encoding, RESTCONF with XML or JSON encoding), and programmed with the language of your choice. For example, there are tools that take as input YANG data models and automatically produce the python APIs. In other words, while we might different flavors of encodings, protocols, and programming languages, all can be deducted from a single source: the YANG data models.

5. As a consequence of the previous point, data model-driven management is not only a trend, is a fact right now.

6. Considering that YANG becomes the data modeling language to manage network elements and services on top of those (see YANG Model Classification) , considering that all devices (IoT or not) will all be connected, and considering that we might have to configure together network elements and IoT devices, why would we chose a different data modeling language than YANG in the IoT space? Interoperability is not only important between IoT devices, but also with the rest of the IP world

7. Summary: you should really use YANG as the data modeling language in the IoT space. YANG meets all the key requirements for management of constrained resource devices (see RFC 7547: Management of Networks with Constrained Devices: Problem Statement and Requirements)

).

C.Q.F.D. : Ce Qu’il Fallait Démontrer (in French)
Q.E.D.: quod erat demonstrandum