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

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Apr 2016 14:22:27 +0200

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

---

From: peter van der Stok <[email-masked]>
Date: Sun, 10 Apr 2016 14:29:36 +0200

Dear all,

I support the intention to
work on the WG document after this adoption to get it ready for last 
call.
More technical comments will follow,

Peter

Carsten Bormann schreef op 2016-04-10 14:22:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Apr 2016 08:50:38 -0700

Hi,

I am in favor of adoption.
We plan to implement this draft for use with CoMI
and possibly RESTCONF.

Andy

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 20 Apr 2016 16:08:38 +0000

Hi,

I (as an author) am in favour of adoption.

We plan to use Yang to model resources in lighting and building automation applications and will use the Yang-Cbor mapping draft to specify how the payload will be formatted in CBOR instead of using JSON/XML schema definitions.

Abhinav

________________________________
From: core <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: Wednesday, April 20, 2016 5:50 PM
To: Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

Andy

On Sun, Apr 10, 2016 at 5:22 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> 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.

Grüße, Carsten

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Apr 2016 16:31:04 +0000

+1, a step in the right direction.

Cheers,

Pascal

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: mercredi 20 avril 2016 17:51
To: Carsten Bormann <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

Andy

Grüße, Carsten

---

From: Michel Veillette <[email-masked]>
Date: Wed, 20 Apr 2016 17:43:35 +0000

As the author, it's an obvious +1.

As a member of the ZigBee NAN working group and the person in charge of recommending a network management protocol for it, it's important to start seeing progress in this goal of bringing the IETF network management approach based on YANG to the world of constrained devices and networks. Proceeding in a timely manner is important to get this protocol in time for adoption by this organization. This draft represents a first building block and a significant step in this direction.

The mapping proposed by this draft is flexible enough to be used in different scenarios.

- This mapping supports names which allows its use in RESCONF to support CBOR serialization
- This mapping supports hashes which allows its use by the CoMI REST API
- This mapping supports SIDs which allows its use by the CoOL REST API

The mapping proposed by this draft is extremely efficient which make it applicable to the most constrained networks such as those targeted by LPWAN.

Finally, this works is also of interest for the 6TiSCH group as a possible solution for Network Management Entity (NME) and Path Computation Element (PCE) integration.

Regards,
Michel Veillette

From: core [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: April-20-16 12:31 PM
To: Andy Bierman <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Cheers,

Pascal

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: mercredi 20 avril 2016 17:51
To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

Andy

Grüße, Carsten

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 20 Apr 2016 19:34:03 +0000

+1 as well…the document seems to satisfy the problem statement and is not dependent upon operational semantics and as stated earlier has multiple applicability to other ongoing  management efforts in the IETF.

Randy

---

From: James Nguyen <[email-masked]>
Date: Wed, 20 Apr 2016 15:48:52 -0400

+1

I support this document.

Also, I'd love to see the CoMI as the WG "soon" or Carsten will have to buy
me a lot of beers.  LOL

Thanks,

James

On Wed, Apr 20, 2016 at 3:34 PM, Turner, Randy <[email-masked]>
wrote:

> +1 as well…the document seems to satisfy the problem statement and is not
> dependent upon operational semantics and as stated earlier has multiple
> applicability to other ongoing  management efforts in the IETF.
>
>
> Randy
>
>
>
>
>
>
>
>
>
>
>
>

-- 
James Nguyen
Email: [email-masked]

---

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 21 Apr 2016 05:45:46 +0000

Hi Paul,

it is good to hear from you - I am familiar with the good work being done within the digital ceiling group at Cisco.

When we started looking for a modelling tool about 6 to 9 months back, RAML+JSON schema was one of the options we looked at and it was an option I was not too unhappy to use. However, YANG turned out to be a better solution for several reasons and I list the three main ones in decreasing order of importance from my point of view.

1) Standardization: I personally do not have a problem with using a standard that is sub-optimal for my problem as long as there is one solution that is being adopted in the field. For constrained device management, there were no real products in the field so we looked at the two options of RAML+JSON schema and YANG. YANG seems to be gaining a lot of momentum with the adoption of NETCONF/RESTCONF for network management. For instance it looks like 6Tish, LPWAN, Anima etc. are panning on using it already. With regards to OCF, I currently see no products in the field and IoTivity is way too bloated for me to build products on small Cortex-M type controllers at the moment. So, I do not yet see enough usage of RAML+JSON in the constrained device world and see YANG becoming a very well used tool in the network management community.

2) Technical: From a technical point of view, YANG provides me the right kind of additional options to specify an interoperable lighting resource model. IMO, the main technical difference between YANG and RAML+schema is that the later fixes the syntax of any client-server interaction but the former can also be used to model semantics. For example, I would like my luminare resource model to provide an API for accessing light intensity but also be able to tell which state the luminaries go to if there was a power cycle and/or if network connectivity is lost to the server. I want these to be specified not by a client writing to specific resources in the luminaire object but as a part of a standard so that all luminairs from different manufacturers behave in the same standard manner. A second example is that I would like to categorize my data into different blocks based on usage by commissioning/maintenance engineers. There are several example where requiring interoperable behaviour of sensors/actuators in the field requires me to not only standardize the syntax but also the semantics of my information model. Also, specifying YANG + conversion rules to JSON, XML, CBOR etc. allows me to carry any media-type using a single information model. I do not want to use JSON in the constrained networks and will be using CBOR. Though, it is possible for me to start with JSON schema and carry CBOR payload, this does not make use of all the optimizations that are possible in JSON. Also, YANG has some additional features, e.g. notifications that are very important in event driven local control that have no counterpart that I know of in RAML.

3) Tooling: In this respect RAML+JSON is better, but not much better. The main issue is that there are tools available to go from RAML+JSON to web server applications. However, to translate the Interface+schema to c/c++ on small embedded device, there don't seem to be too many options ATM.

To summarize, I think it is essential that the industry aligns around one modelling language and I would not have too much of a problem if this was RAML+JSON. However, I do not see that happening right now and YANG+CBOR seems to be more suited to the constrained network/constrained devices application with more momentum because it is being used in the network management applications.

Regards,

Abhinav

________________________________
From: Paul Duffy <[email-masked]>
Sent: Wednesday, April 20, 2016 6:41 PM
To: Somaraju Abhinav
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Greetings Somaraju

BTW I am a member of the Cisco Digital Ceiling team (amongst other matters).

What are your issues with JSON Schema versus YANG?

OCF has adopted RAML for RESTful interface definitions.  Cisco is supportive of RAML and RAML + JSON Schema.  We think this is good approach.  Reasons: YANG tools ecosystem / support for YANG is generally poor, and JSON generally has huge traction and great tooling support.

YANG to CBOR seems a large impedance mismatch.

?

Cheers

On 4/20/2016 12:08 PM, Somaraju Abhinav wrote:

Hi,

Abhinav

________________________________
From: core <[email-masked]><mailto:[email-masked]> on behalf of Andy Bierman <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, April 20, 2016 5:50 PM
To: Carsten Bormann
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

Andy

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 21 Apr 2016 06:36:43 +0000

+1 ; also in favor of adoption for the purpose that Abhinav mentions.

Esko Dijk

From: core [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: Wednesday, April 20, 2016 18:09
To: Andy Bierman <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

Abhinav

From: core <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>

Hi,

Andy

Grüße, Carsten

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Apr 2016 11:42:54 +0200

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Apr 2016 09:12:20 -0700

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

---

From: Michel Veillette <[email-masked]>
Date: Thu, 21 Apr 2016 17:34:50 +0000

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:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: April-21-16 5:43 AM
To: Carsten Bormann <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi Carsten, Hi all,

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:

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.

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.

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).

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).

* 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.

----

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:
> draft-veillette-core-yang-cbor-mapping-00 but not enough people had 
> read the document to go for an in-room consensus call.
> 
> Note that this work is explicitly covered by our charter, so 
> discussions of which WG should work on this are off-topic.
> 
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Apr 2016 19:48:06 +0200

> LWM2M just have a simpler (subset) modeling language.

These are pretty bold statements. Claiming something is simple and
knowing something is simple are sometimes different things. Have you
worked throught the details? Is there a decent public definition of
the 'simpler (subset) modeling language'? And with public I mean
public, not hidden behind all sorts of registration walls.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Paul Duffy <[email-masked]>
Date: Thu, 21 Apr 2016 14:30:23 -0400

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

---

From: Michel Veillette <[email-masked]>
Date: Thu, 21 Apr 2016 19:47:53 +0000

Hi Juergen

I'm not sure I can share a LWM2M definition files since peoples need fill a form to get access to them, see the following link.

http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

I didn't go through a formal mapping between these two modeling languages but following is what this mapping might look like:

LWM2M                | YANG
---------------------+---------------
<Object>             | module
<Name>               | module name
<Description1>       | description
<MultipleInstances>  | list if true, container if false
<Mandatory>          | mandatory
<Item>               | leaf if <MultipleInstances> is true, leaf-list if false
 <Name>              | leaf name
 <Operations>        | config
 <MultipleInstances> | See <Item>
 <Mandatory>         | mandatory
 <Type>              | type
 <RangeEnumeration>  | range or enum
 <Units>             | units
 <Description>       | description

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: April-21-16 1:48 PM
To: Michel Veillette <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00

> LWM2M just have a simpler (subset) modeling language.

These are pretty bold statements. Claiming something is simple and knowing something is simple are sometimes different things. Have you worked throught the details? Is there a decent public definition of the 'simpler (subset) modeling language'? And with public I mean public, not hidden behind all sorts of registration walls.

/js

---

From: Michel Veillette <[email-masked]>
Date: Thu, 21 Apr 2016 20:02:04 +0000

Hi Paul

The working documents are available at http://core-wg.github.io/yang-cbor/
.yang and .sid file examples are available at https://github.com/core-wg/yang-cbor/tree/master/registry

For the running code, you will have to wait around the next IETF.

Regards,
Michel

From: core [mailto:[email-masked]] On Behalf Of Paul Duffy
Sent: April-21-16 2:30 PM
To: [email-masked]
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Thanks Hannes

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.

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

Hi Carsten, Hi all,

Here are the claims:

description.

systems, like Linux.

tell you).

registered objects:

produce code.

----

-----

LWM2M.

Ciao

Hannes

Grüße, Carsten

core mailing list

core mailing list

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Apr 2016 22:46:30 +0200

> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

Then I can't help.
 
> I didn't go through a formal mapping between these two modeling languages but following is what this mapping might look like:

The devil is usually in the details but since there is no public
specification I do not know. It sounds somewhat surprising that an
'<Object>' would equate a YANG module but then I simply do not know.
Only someone who has access to the specifications and who can get
clearance to write about a mapping according to IETF rules can work
on this.

/js

PS: You shall [...] not [...] use all or any part of a Document as part
    of a specification or standard not emanating from the Licensor
    without the prior written consent of the Licensor [...]

---

From: Michel Veillette <[email-masked]>
Date: Thu, 21 Apr 2016 21:00:29 +0000

Hi Juergen

The extract I have provided is from a publically available document, see:
https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf

My remark about the LWM2M modeling language was just to highlight that such language don't necessary imply code generation.

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: April-21-16 4:47 PM
To: Michel Veillette <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00

On Thu, Apr 21, 2016 at 07:47:53PM +0000, Michel Veillette wrote:
> http://technical.openmobilealliance.org/Technical/technical-informatio
> n/release-program/current-releases/oma-lightweightm2m-v1-0

Then I can't help.
 
> I didn't go through a formal mapping between these two modeling languages but following is what this mapping might look like:

The devil is usually in the details but since there is no public specification I do not know. It sounds somewhat surprising that an '<Object>' would equate a YANG module but then I simply do not know.
Only someone who has access to the specifications and who can get clearance to write about a mapping according to IETF rules can work on this.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Apr 2016 14:03:15 -0700

Hi,

I am not advocating a requirements document but it is helpful
to understand them before trying to agree on the details.
It is not just data model or nothing to consider, but what
data modeling features are really needed.

For example, YANG allows decentralized model extension.
Any module can augment another one, without any process
other than writing the module. YANG has many ways
(grouping, leafref, typedef, etc.) to easily reuse other modules.

YANG has the concept of a datastore, not just API input and output.
It has the notion of configuration vs. state, that is also relevant to NM.
Cross-object validation (e.g. must-stmt) and conditional usage (when-stmt)
is important for configuration management. It has advanced support
for module conformance (what is optional to implement? what is optional to
use?)

Is it OK if CoAP is used for purposes outside of IoT?
I think constrained networks are within the charter,
so real network management of  devices on constrained networks
seems relevant to this WG.

Andy

On Thu, Apr 21, 2016 at 1:46 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > I'm not sure I can share a LWM2M definition files since peoples need
> fill a form to get access to them, see the following link.
> >
> >
> > I didn't go through a formal mapping between these two modeling
> languages but following is what this mapping might look like:
> >
> > LWM2M                | YANG

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Apr 2016 23:37:42 +0200

> My remark about the LWM2M modeling language was just to highlight that such language don't necessary imply code generation.

YANG does not imply code generation either. A YANG module defines a
contract, and in the light of a protocol a programmatic interface.
There is nothing in YANG that requires code generation.

It just happens that people often tend to automate things if they find
themself repeatedly writing similar code. It is at the end a question
of how much data a device exposes and what kind of developers you are
dealing with and whether you have a product that is expected to evolve
over years or something designed to be sold and thrown away
afterwards. ;-)

/js

PS: I have just implemented a YANG data model 'manually' because I had
    reasons to not depend on tool chains (the target environment are
    OpenWrt type of devices). But still I took advantage of having
    YANG tools available to validate test cases so that I can be
    reasonably sure my manually written code is a good match of the
    contract.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Apr 2016 14:49:58 -0700

On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > My remark about the LWM2M modeling language was just to highlight that
> such language don't necessary imply code generation.
> >
>

There are commercial and open-source toolchains that handle the NETCONF/YANG
interaction model and most of the data model details in the protocol stack,
instead of pushing that
work out to the model instrumentation.  This can save a lot of code and
makes sure
the client or server has consistent behavior.

But you are making an important point.
The expected use CoMI/CoOL co-authors have discussed is client firmware
written
to work with specific YANG modules/revisions.  The client needs to retrieve
enough
server state to know if the server supports the same module revisions, and
then just assumes
the API contract will be followed.  It does not need any YANG parser or
code automation.

--

Andy

---

From: Somaraju Abhinav <[email-masked]>
Date: Fri, 22 Apr 2016 08:46:50 +0000

Hi,
We have been using YANG to model objects that we use with LWM2M for about 6 months now. As far as I can tell, there is only one part of the LWM2M resource model that cannot be modelled using YANG: LWM2M has resources on which you can read, write and execute (operations). YANG distinguishes between resources that are operations vs data and therefore cannot be used to model resources in LWM2M that support the three types of operations. There are of course ways around this issue.

As an example, please find attached an IPSO object available for download at http://www.ipso-alliance.org/so-starter-pack/ which my colleague has modelled in YANG. Please note that the YANG model is just an example and is not approved/endorsed by IPSO or LWM2M.

Regards,
Abhinav

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Donnerstag, 21. April 2016 23:50
To: Juergen Schoenwaelder <[email-masked]>; Michel Veillette <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00

On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

There are commercial and open-source toolchains that handle the NETCONF/YANG
interaction model and most of the data model details in the protocol stack, instead of pushing that
work out to the model instrumentation.  This can save a lot of code and makes sure
the client or server has consistent behavior.

But you are making an important point.
The expected use CoMI/CoOL co-authors have discussed is client firmware written
to work with specific YANG modules/revisions.  The client needs to retrieve enough
server state to know if the server supports the same module revisions, and then just assumes
the API contract will be followed.  It does not need any YANG parser or code automation.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Apr 2016 11:05:38 +0200

We have modeled something in YANG is not the same as there is a
_simple_ translation (or I wrongly assumed 'automated translation'
while the intention was 'human translation'?).

The link you provide still requires to register my email address, but
yes this time with a bit less legalize. Anyway, I am not interested in
looking at stuff where content protection is apparently rated higher
than open access.

Concerning operations: In YANG 1.1, you can associate an operation
with a YANG container or a YANG list element (it is called an action
in YANG 1.1). But since you map so called 'objects' to modules, it
probably does not matter (and I am not sure mapping 'objects' to
modules is what I would do but then I just do not the LWM2M details).

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 22 Apr 2016 11:13:35 +0200

That registration process also appears to be broken.

https://open-stand.org

Grüße, Carsten

---

From: Somaraju Abhinav <[email-masked]>
Date: Fri, 22 Apr 2016 10:25:16 +0000

We have modeled something in YANG is not the same as there is a _simple_ translation (or I wrongly assumed 'automated translation'
while the intention was 'human translation'?).
[AS] Agree. This was just supposed to be an example. We have not worked on a translation tool/rules from YANG to LWM2M. However, we do use automated tools to go from YANG modules to LWM2M compliant client code-skeletons written in c/c++ (via an intermediate and unnecessary step of producing XSD files).

Concerning operations: In YANG 1.1, you can associate an operation with a YANG container or a YANG list element (it is called an action in YANG 1.1).
[AS] Yes, we looked at using containers+actions to model read/write/execute resources. I think there are a few ways to do this - e.g. using Yang extensions. I have personally not had to use it though because I prefer the YANG solution of keeping data and operations separate.

But since you map so called 'objects' to modules, it probably does not matter (and I am not sure mapping 'objects' to modules is what I would do but then I just do not the LWM2M details).
[AS] I played around with three options initially - using YANG submodules as LWM2M objects, using YANG containers as objects and using YANG modules as objects. For our purpose all three options worked okay. I don't have a preference one way or another.

On Fri, Apr 22, 2016 at 08:46:50AM +0000, Somaraju Abhinav wrote:
> To: Juergen Schoenwaelder <[email-masked]>;
> Michel Veillette <[email-masked]>; Hannes
> Tschofenig <[email-masked]>; [email-masked] WG
> <[email-masked]>
> Subject: Re: [core] ? WG adoption of
> draft-veillette-core-yang-cbor-mapping-00
>
>
>
> There are commercial and open-source toolchains that handle the
> NETCONF/YANG interaction model and most of the data model details in
> the protocol stack, instead of pushing that work out to the model
> instrumentation.  This can save a lot of code and makes sure the client or server has consistent behavior.
>
> The expected use CoMI/CoOL co-authors have discussed is client
> firmware written to work with specific YANG modules/revisions.  The
> client needs to retrieve enough server state to know if the server
> supports the same module revisions, and then just assumes the API contract will be followed.  It does not need any YANG parser or code automation.
>
>
> --

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Apr 2016 21:28:35 +0200

Hi Juergen,

trying to read your message -- are you just commenting on the side
conversation here or is this also a comment on the adoption call?

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 10:29:38 +0200

I guess it is side conversation for this thread. ;-)

I have been pushing for factoring the YANG to CBOR mapping out of the
COMI documents and hence I am happy that this is now happening and
hence I am supportive.

/js

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Apr 2016 12:19:54 +0200

Hi Juergen, Hi Carsten,

The data modelling language used by OMA LWM2M is an XML schema and the
OMA only uses it for two purposes:

 * Adding new objects and resources to the registry allows automatic
validation (of the XML instance documents against the XML schema).

 * The XML schema really only models the data and does not attempt to
describe the interaction.

There has been no attempt to generate code from the XML instance
documents (as far as I know).

I have tried to take a subset of the device object and to describe it in
Yang. To my knowledge nobody has tried to describe all currently
registered objects with Yang.

In any case, here is what I have tried:

----

module LWM2M_Device {
	// header information
	yang-version "1";
	namespace "foobar1";			
	prefix "LWM2M_Device";
	
	// linkage statements
	import extensions {
		prefix extensions;
		[email-masked];
	}
	
	// meta information
	organization "OMA";
	contact "foobar2";
	description
		"This object provides a range of device related information which can
be queried by the LWM2M Server, and a device reboot and factory reset
function.";
	reference
"http://technical.openmobilealliance.org/tech/profiles/LWM2M_Device-v1_0.xml";
	
	// revision history
	revision 2016-04-20 {
		description "Initial revision.";
		reference "";
	}
	
	// module definitions
	extensions:LWM2M_Object_ID "3";
	
	// typedef statements
	
	// data statements
	
	leaf Manufacturer {
		extensions:LWM2M_Resource_ID "0";
        type string;
		config true;
		description "Human readable manufacturer name";
	}
	
	leaf ModelNumber {
		extensions:LWM2M_Resource_ID "1";
		type String;
		config true;
		description "A model identifier
                (manufacturer specified string).";
	}
	
	leaf SerialNumber {
		extensions:LWM2M_Resource_ID "2";
		type String;
		config true;
		description "Serial Number.";
	}
	
	leaf AvailablePowerSources {
		extensions:LWM2M_Resource_ID "6";
		type int32 {
                  range "0..7";
                };		
		config true;
		description "
 0 – DC power
 1 – Internal Battery
 2 – External Battery
 4 – Power over Ethernet
 5 – USB
 6 – AC (Mains) power
 7 – Solar";
	}
	
	leaf BatteryLevel {
		extensions:LWM2M_Resource_ID "9";
		type int32 {
            range "0..100";
        };
		units percent;
		config false;
		description "Contains the current battery level as a percentage (with
a range from 0 to 100). This value is only valid when the value of
Available Power Sources Resource is 1.";
	}
	
	leaf MemoryFree {
		extensions:LWM2M_Resource_ID "10";
		type int32;
		units KB;
		config false;
		description "Estimated current available amount of storage space which
can store data and software in the LWM2M Device (expressed in kilobytes).";
	}
	
	leaf CurrentTime {
		extensions:LWM2M_Resource_ID "13";
		type timestamp;
		units KB;
		config false;
		description "Current UNIX time of the LWM2M Client. The LWM2M Client
should be responsible to increase this time value as every second
elapses. The LWM2M Server is able to write this Resource to make the
LWM2M Client synchronized with the LWM2M Server.";
	}
	
}

----

The problem I have is to find out whether Yang is able to also describe
the interaction model of OMA LWM2M. I believe the current understanding
is that this is not possible without some extensions. Please correct me.

Ciao
Hannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Apr 2016 12:33:38 +0200

Hannes,

whether this YANG fragment makes sense or not I simply do not know
without knowing LWM2M and since there are no open specs there is
little help you can expect. I have no clue about the interaction model
of OMA LWM2M nor do I know what LWM2M_Device is etc.

The claim was made that there is a 'simple' conversion (and I read
that as 'simple algorithm' to do conversion) and all I am asking is
whether someone actually went through the details of this. All I saw
so far are sketches of examples, thats good for a start but still
likely a longer way from a 'simple algorithm' (if that was the
intention).

But we should really be using a different thread - or simply wait
until someone managed to work out the details and got permission from
OMA to write it down without violating their legal constraints they
put on their registration wall.

/js

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Apr 2016 13:03:34 +0200

Hi Juergen,

> of OMA LWM2M nor do I know what LWM2M_Device is etc.

The specs are publically available for download at no cost.

Here is the link:

You want to look at the 'Technical Specification'.

The registry for the objects are also public and available in a nicely
written page (similar to what IANA provides for the IETF):
http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry

> likely a longer way from a 'simple algorithm' (if that was the

Nobody has gone through the details. This is one of my complaints as
well. There is this argument that we can do things easily with Yang
since it is such a powerful language but then nobody spends the time to
look at the already available solutions.

> 
> But we should really be using a different thread

Changed the name of the Thread.

> - or simply wait

There is no permission that needs to be obtained IMHO, if I understand
the OMA copyright policy correctly.

Ciao
Hannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Apr 2016 09:07:44 +0200

> You want to look at the 'Technical Specification'.

They are not open, I have to accept certain legal terms to get
access. In particular:

  use all or any part of a Document as part of a specification or
  standard not emanating from the Licensor without the prior written
  consent of the Licensor

I might already need a written consent if I post an example here since
everything posted to an IETF list may be considered a contribution.
 
> http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry

Looking at examples to infer what the semantics of the schema are is
not what I am going to spend my time on.

> the OMA copyright policy correctly.

See above.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Apr 2016 23:17:26 +0200

The discussion that spawned from this adoption call is ongoing, but we
seem to have converged on (slightly rough*) consensus on adopting this
draft as a WG item.

Authors: please resubmit the current draft as
draft-ietf-core-yang-cbor-00.txt; we will start processing further
changes in the WG process.
(If you already know about technical issues, please use the WG tracker
at https://trac.tools.ietf.org/wg/core/trac/report/9 for now; editorial
issues might be tracked easier on github.)

Note that the yang-cbor draft is on github in the
https://github.com/core-wg/yang-cbor repository (which also contains
other drafts that may or may not converge into WG documents).  When the
renaming is complete, the current editor's copy of the WG draft will be
visible at:

http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html

*) the roughness was about the danger of the CoRE WG overextending
itself by taking on more work.  This will be actively watched by the
chairs, whose priority will continue to be on getting current work
finished.  However, there is significant new energy in the COMI/COOL
work, so the overall capacity of the WG will increase by starting to
work on this part of our charter.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Apr 2016 09:21:28 +0200

Hi Juergen

thanks for your feedback.

What is considered 'open' seems to vary a bit. I was using the
definition of the OpenStand, see
https://open-stand.org/about-us/principles/

I will reach out to the OMA staff to find out why the current
boilerplate text exists.

Ciao
Hannes