Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

[Michel Veillette <[e-mail]>]

Hi Hannes

### Application vs. Network management

Your email seem to describe mainly an application protocol instead of an network management protocol.
The requirements of both are different, capabilities are often different and in many case, both are implemented by the same device.

A network management protocol need to support use cases such as:
- Commissioning / Provisioning of a device with a well known configuration (Initialization of all resources)
- Atomic transaction (To avoid to leave a node in an inconsistent state)
- Scheduled / synchronized commit (To avoid to leave the network in an inconsistent state)
- Configuration backup and restore
- Configuration rollback (To recover from a misconfiguration)
- Event stream
- Diagnostic and monitoring

### Modeling language vs. code generation

You seem to imply that the use of a modeling language is directly associated with code generation.
First, LWM2M have its own modeling language encoded in xml.
A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang.
A simple xml transform can probably do the conversion between the two without any lost.
LWM2M just have a simpler (subset) modeling language.

The same way as LWM2M, a CoMI/CoOL implementation don’t need to rely on code generation.
The fact that CBOR allows a schema less operation enable the creation of a client or server library which is independent of the object(s) implemented and can be used with any YANG module. This is in fact the approach we are taking in an open source project we are about to start.

### Existing useful smi / yang modules

This is a list of useful, already existing yang modules:
- iana-if-type (http://www.netconfcentral.org/modules/iana-if-type/2014-05-08)
- ietf-inet-types (http://www.netconfcentral.org/modules/ietf-inet-types/2013-07-15)
- ietf-interfaces (http://www.netconfcentral.org/modules/ietf-interfaces/2014-05-08)
- ietf-ip (http://www.netconfcentral.org/modules/ietf-ip/2014-06-16)
- ietf-yang-library (http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26)
- ietf-system (http://www.netconfcentral.org/modules/ietf-system/2014-08-06)
- yang-mpl (https://tools.ietf.org/html/draft-vanderstok-core-mpl-yang-00)
- rplMib (https://tools.ietf.org/html/draft-sehgal-roll-rpl-mib-06)
- lowpanMIB (https://www.ietf.org/archive/id/draft-schoenw-6lowpan-mib-03.txt)

However, the main advantage of using YANG is not necessary in the list of already existing modules but in YANG itself and the tight integration with the rest of network management world moving forward.

If you have any more questions, don't hesitate to ask.
We will certainly talk again about it around a beer in Berlin ;)

Regards,

Hannes

-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
Sent: April-21-16 5:43 AM
To: Carsten Bormann <[e-mail]>; [e-mail] WG <[e-mail]>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi Carsten, Hi all,

I think we are going to fast here.

We hardly make any progress with the existing WG items but then we add a number of new items that are barely understood.

This call for adoption is not a call for this document this is a question whether we want to work on the following two types of things:

a) a data modelling language (Yang) for use with IoT objects (which in case of IoT are largely defined elsewhere), and

b) re-use a protocol machinery originally defined for network management around Netconf (which may now be converted to CoAP and CBOR usage).

I have spent some time trying to figure out what the implications are and (that's a bold statement) doubt that most WG participants (except for the authors of the documents) really understand what this really means.

Here are the claims:

1) IoT will re-use many of the objects defined for network management.

2) There is a need for a formal language to describe the data model.

3) There is a value in generating code using that formal data model description.

4) Yang (as a data modelling language) and the related protocols are a good match for the requirements people have.

Are these claims actually true?

Given that we are late at the party and other organizations have done a fair amount of work in that space already I am wondering whether we have done our home work of analysis the existing landscape or whether we are just interested to add another set of standards to the mix.

I have my opinion about the claims and I would like to share them with you.

Regarding (1) on the re-use argument. I do not believe that the existing, already standardized objects defined for network management are a good fit for what we are doing in IoT. I have not seen the examples where there is re-use. As illustrated below, I am exposing my sensors, buttons, and LEDs to outside world rather than network interfaces and alike. I fully understand that the world is far more complex with routers and switches that have many ports and lots of configuration parameters. They are also running regular operating systems, like Linux.

Regarding (2) on the use of formal languages. It seems that most organizations are using formal languages for describing their object definitions already today. I personally believe that these formal languages do not provide a lot of value in general but using something that is easy for humans to write and read is something I may be OK with.
Particularly the example below shows that all I need as a developer is very little. IoT devices typically do not have many sensors and the implementation complexity is elsewhere (with the operating system, the tool chain, and various low power settings).

Regarding (3) on the value of code generation.

I am currently in the process of writing a new tutorial for a developer workshop hosted by the Open Mobile Alliance (OMA), see http://openmobilealliance.org/free-hands-on-training-for-iot-developers-with-oma-lwm2m-and-arm-based-microprocessors/

I am using regular IoT hardware, namely the K64F board with onboard sensors, namely an accelerometer and magnetometer, an RGB LED, and two buttons. The sensors are connected using I2C and are certainly not among the most simplistic (which the data sheet of almost 100 pages can easily tell you).

In the process of writing code I need to do the following:

* Figure out how to connect to the sensors using I2C.

* Learn how the sensor works, how to configure the sensor to do what I want, and to convert the raw sensor data into something suitable for my application. One can only hope to find a library that does these things already and to only have to adjust the settings rather than writing everything from scratch. That typically takes a lot of time.

* Determine whether is a suitable object definition already available.
In my case I am looking at the OMNA registry (which has also been populated with the objects from the IPSO Alliance). Here are the registered objects:
http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry

In case of the Accelerometer and the Magnetometer I am lucky since those have already been defined. I don't need to define my own objects, which is a simple task given the new OMA object editor http://devtoolkit.openmobilealliance.org/OEditor/Default

* Then, I need to add the code for use with them. Here is where the formal description of the data model could help me to automatically produce code.

Now, this is the funny thing: this code amounts for around 5 lines, depending on the API and programming language you are using. Most likely the code generation will produce some code that you cannot directly use.

Here is what I have to write on the IoT side:

----

// Create object '3313' = 'Accelerometer'
acc_object = M2MInterfaceFactory::create_object("3313");

M2MObjectInstance* acc_inst = acc_object->create_object_instance();

M2MResource* acc_x_res = acc_inst->create_dynamic_resource("5702", "X Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_y_res = acc_inst->create_dynamic_resource("5703", "Y Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_z_res = acc_inst->create_dynamic_resource("5704", "Z Value",M2MResourceInstance::FLOAT, true /* observable */);

-----

I fear that we are optimizing for something that does not take a long time anyway. It will take longer to fetch the relevant Yang file, to use the tools to generate the code and to integrate it into the existing code than to just write these few lines yourself.

What the above example does not utilize potential code generation for the actual interaction model. In my case my code is hard-wired to use LWM2M.

Since I have not yet seen a meaningful example of Yang for the IoT environment I also haven't seen one that produces meaningful code for the interaction model either.

Regarding (4) concerning Yang as a data modelling language (vs. other languages also considered by the IoT communities). As Paul noted there are other languages in town and I personally do not know whether the features offered by Yang are better or equal to those offered by the other languages. I certainly haven't done that analysis.

As a concluding remark I would like to say that while my current assessment may sound negative I am happy to learn more about this topic and might get convinced that Yang is the right tool. Currently, I just haven't reached that level yet and I can claim that I have spent some time looking at this topic already.

Ciao
Hannes


On 04/10/2016 02:22 PM, Carsten Bormann wrote:
> In Buenos Aires, we discussed the adoption of
> draft-veillette-core-yang-cbor-mapping-00 but not enough people had 
> read the document to go for an in-room consensus call.
> 
> This is a two-week call for adoption of
> draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE.
> Specifically, if you (1) support or (2) have an objection to this 
> decision, please speak up on the mailing list by 2016-04-24.
> 
> Note that this work is explicitly covered by our charter, so 
> discussions of which WG should work on this are off-topic.
> 
> As always, adoption of a document as a WG document is not a vote on 
> whether we already have reached last-call state; the intention is to 
> work on the WG document after adoption for a while to get it ready for 
> last call.  If you want to combine your support/objection with 
> technical comments, this is certainly welcome so we can accelerate that process.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>