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

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:
> 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:core-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Donnerstag, 21. April 2016 23:50
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
> Michel Veillette <Michel.Veillette@trilliantinc.com>; Hannes
> Tschofenig <hannes.tschofenig@gmx.net>; core@ietf.org WG
> <core@ietf.org>
> Subject: Re: [core] ? WG adoption of
> draft-veillette-core-yang-cbor-mapping-00
>
>
>
> On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Veillette wrote:
> > 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.
> >
>
> 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.
>
>
> 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.
>
>
> --
> 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/>
>
>
> Andy
>
> _______________________________________________
> core mailing list
> core@ietf.org<mailto:core@ietf.org>
> 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.

--
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/>
________________________________________________________ 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.