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

[Somaraju Abhinav <[e-mail]>]

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 <[e-mail]>
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,

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 <[e-mail]><mailto:[e-mail]> on behalf of Andy Bierman <[e-mail]><mailto:[e-mail]>
Sent: Wednesday, April 20, 2016 5:50 PM
To: Carsten Bormann
Cc: [e-mail]<mailto:[e-mail]> WG
Subject: Re: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

Hi,

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


Andy


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


_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
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.