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

[Andy Bierman <[e-mail]>]

Hi,

I am obviously a proponent of using YANG, for the reasons outlined
in our IOTSI position paper:

https://www.iab.org/wp-content/IAB-uploads/2016/03/CoMI_IoT_Position_Paper_4.pdf

You are asking the right questions -- is it worth the effort to
use a formal data modeling language in IoT?  If the data models
are trivial, why bother?

IMO, here's why:

 - the model is a formal description of the server API. Client programmers
   need to code to your server API.  Mistakes like 1 side thinks it's meters
   and the other side thinks it's feet can be catastrophic.  Automated
   data validation can help avoid that.

- the model fully describes the API so there is no need to send any
meta-data
  with API content.  This saves a lot of bandwidth.  The client reads the
  module-set ID and the YANG module list (once) if the module-set ID is
unknown.

- the model can define defaults. The protocol can utilize this info to omit
lots
  of data on the wire without any loss of info.

 - unconstrained devices on constrained networks need real data models

 - the lack of IoT YANG modules is a reflection on the lack of a protocol
   suitable for constrained devices.  NETCONF is focused on SDN and there
   is no concern whatsoever for CPU, memory, or network usage.

 - YANG is functioning as an easy-to-use info modeling language, because
   there are multiple protocols and multiple message encoding formats
   supporting it.  YANG to CBOR will provide an efficient encoding format
   that could be used in many protocols, not just CoAP.


Andy

On Thu, Apr 21, 2016 at 2:42 AM, Hannes Tschofenig <
[e-mail]> wrote:

> 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
> >
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
>