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

[Paul Duffy <[e-mail]>]

Thanks Hannes

A few related comments....

re: 2 and 3.  I do see a machine consumable interface / resource 
definition as useful.  At least as the contract both ends of the 
communication will code.  Recent Cisco experience underlines 
co-developing using prose based descriptions is highly error prone (I 
not surprised).  I'm further an advocate of using these interface 
descriptions for code gen, doc gen, and conformance testing tools (when 
certification is being performed).  The pro IDL macro points have not 
changed over the years: Corba, COM, WSDL, WADL, and now the IoT space.

re: 4.  This is a tough one.  I struggle with YANG for IoT. 
Acknowledging it is the IETF's baby.  But I see no traction out at the 
far edge of IoT.   Different dialects?  Tooling support (editors, 
validators, code gen, doc gen, etc)? Cisco is putting effort into the 
RAML ecosystem, OCF being a first example of that.

http://www.oneiota.org/documents?filter[media_type]=application%2Framl%2Byaml

I better understand RAML, but am happy to be enlightened re: YANG for 
IoT endpoints.  Does anyone have a side by side example worked out?  
Interface definition to running code?

Cheers


On 4/21/2016 5:42 AM, Hannes Tschofenig 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