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

[Hannes Tschofenig <[e-mail]>]

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
>