Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

[Andy Bierman <[e-mail]>]

On Tue, Jul 23, 2019 at 10:13 AM Michel Veillette <
[e-mail]> wrote:

> Hi Andy
>
>
>
> To evaluate the need, or not,  of a compact version of ietf-yang-library,
> I have created a simple example containing:
>
> - one datastore
>
> - one schema
>
> - one module set
>
>
>
> The module set contains the following YANG modules:
>
> - ietf-interfaces
>
> - ietf-ip
>
> - ietf-system
>
> - iana-hardware
>
> - my-upgrade-module
>
> - ietf-yang-types
>
> - ietf-inet-types
>
>
>
> Following is this YANG library implemented using ‘ietf-yang-library’ and
> encoded in CBOR.
>
> The resulting size is 642 bytes without any location URIs which are
> optional.
>
>
>
> {
>
>   2368 : {
>
>     +8 : [
>
>       {
>
>         +21 : "set1",
>
>         +10 : [
>
>           {
>
>             +4 : "ietf-interfaces",
>
>             +6 : "2018-02-20",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
>           },
>
>           {
>
>             +4 : "ietf-ip",
>
>             +6 : "2018-02-22",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-ip"
>
>           },
>
>           {
>
>             +4 : "ietf-system",
>
>             +6 : "2014-08-06",
>
>             +5 : "urn:ietf:params:xml:ns:yang:ietf-system",
>
>             +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
>
>           },
>
>           {
>
>             +4 : "iana-hardware",
>
>             +6 : "2018-03-13",
>
>             +5 : "urn:ietf:params:xml:ns:yang:iana-hardware"
>
>           },
>
>           {
>
>             +4 : "my-upgrade-module",
>
>             +6 : "2019-07-23",
>
>             +5 : "http://mydomain.com/yang/my-upgrade-module",
>
>             +2 : ["ftp", "coap", "scheduled"]
>
>           }
>
>         ],
>
>         +1 : [
>
>           {
>
>             +2 : "ietf-yang-types",
>
>             +4 : "2018-02-20",
>
>             +3 : "urn:ietf:params:xml:ns:yang:ietf-yang-types"
>
>           },
>
>           {
>
>             +2 : "ietf-inet-types",
>
>             +4 : "2013-07-15",
>
>             +3 : "urn:ietf:params:xml:ns:yang:ietf-inet-types"
>
>           }
>
>         ]
>
>       }
>
>     ],
>
>     +30 : [
>
>       {
>
>         +2 : "schema1",
>
>         +1 : ["set1"]
>
>       }
>
>     ],
>
>     +5 : [
>
>       {
>
>         +1 : "unified",
>
>         +2 : ["schema1"]
>
>       }
>
>     ],
>
>     +4 : "mySensorDataModel"
>
>   }
>
> }
>
>
>
> The same YANG library implemented using ‘ietf-constrained-yang-library’
> required 183 bytes.
>
>
>
> {
>
>   2368 : {
>
>     +8 : [
>
>       {
>
>         +21 : 1,
>
>         +10 : [
>
>           {
>
>             +4 : 1500,
>
>             +6 : h'20180220'
>
>           },
>
>           {
>
>             +4 : 1600,
>
>             +6 : h'20180222'
>
>           },
>
>           {
>
>             +4 : 1700,
>
>             +6 : h'20140806',
>
>             +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
>
>           },
>
>           {
>
>             +4 : 2200,
>
>             +6 : h'20180313'
>
>           },
>
>           {
>
>             +4 : 1005100,
>
>             +6 : h'20190723',
>
>             +2 : ["ftp", "coap", "scheduled"]
>
>           }
>
>         ],
>
>         +1 : [
>
>           {
>
>             +2 : 1100,
>
>             +4 : h'20180220'
>
>           },
>
>           {
>
>             +2 : 1150,
>
>             +4 : h'20130715'
>
>           }
>
>         ]
>
>       }
>
>     ],
>
>     +30 : [
>
>       {
>
>         +2 : 1,
>
>         +1 : [1]
>
>       }
>
>     ],
>
>     +5 : [
>
>       {
>
>         +1 : "unified",
>
>         +2 : [1]
>
>       }
>
>     ],
>
>     +4 : h'9D373F629E20'
>
>   }
>
> }
>
>
>
> The mandatory namespace field in the original ietf-yang-library, useless
> for CoREconf, is the main contributor of this increase in size. Assuming
> that a real device have at least 5 time more YANG modules, we can estimate
> that the non compact version of the YANG library will be around 3 to 4 kB,
> the compact version will be slightly less than 1kB.
>
>
>

So what is the size difference if just the XML namespace is removed?



> Can we archive the same result with a deviation module instead of a
> complete module replacement?
>
>
>


Yes


   deviation
/yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:namespace {
      deviate replace {
         mandatory false;
      }
   }

You could also replace the type-stmt for key leafs you want to change, but
this seems like overkill.
This data will not change very often. The /yang-library/content-id leaf can
be polled or yang-library-change
notification can be used. YoT devices will probably have modules hard-wired
into firmware so
this data can be cached on the client (using content-id).


Regards
>
> Michel
>
>
Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 22 juillet 2019 20:33
> *To:* Michel Veillette <[e-mail]>
> *Cc:* Carsten Bormann <[e-mail]>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi,
>
>
>
> I don't think it is needed because the client is supposed to know the SID
> mappings outside of YANG library.
>
> This library is likely to be very static on a YoT device. Maybe changing
> once per firmware upgrade.
>
> It does not really need optimized retrieval.
>
>
>
> I prefer to keep the models the same between NC/RC and CORECONF.
>
> The YANG to CBOR solution should include ways to make the message encoding
> more efficient.
>
> That way, the same application logic can use whatever protocol operations
> are needed, instead of special CORECONF models.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Mon, Jul 22, 2019 at 5:23 PM Michel Veillette <
> [e-mail]> wrote:
>
> Hi Andy
>
>
>
> About “draft-veillette-core-yang-library”, should we postpone the working
> group adoption of this draft to get more time to work on a different
> solution?
>
>
>
> I raising this topic because the current CoMI draft (
> https://tools.ietf.org/html/draft-ietf-core-comi-07#section-6
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-comi-07%23section-6&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123365593&sdata=UF0b3Tg6AFTojtId%2BfWjqzwS06UmnFD2TBa9%2B%2Ffkr3o%3D&reserved=0>)
> have a mandatory reference to it. We either need to change the content of
> CoMI or commit to bring ietf-constrained-yang-library to life.
>
>
>
> Regards,
>
> Michel
>
>
>
> *From:* Michel Veillette
> *Sent:* 15 juillet 2019 10:37
> *To:* Andy Bierman <[e-mail]>; IETF Secretariat <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail];
> Core <[e-mail]>
> *Subject:* RE: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi Andy
>
>
>
> I effectively see some values in supporting the module names.
>
> However, these names should be optional leaves and not mandatory keys.
>
> Simply augmenting the existing “ietf-yang-library” will increase its size,
> which makes this solution even less friendly to constrained devices and
> networks.
>
>
>
> Hope to see you in MTL to discuss these changes,
>
> Michel
>
>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 12 juillet 2019 17:16
> *To:* IETF Secretariat <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> Core <[e-mail]>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
>
>
>
>
> On Thu, Jul 11, 2019 at 8:32 AM IETF Secretariat <
> [e-mail]> wrote:
>
>
> The CORE WG has placed draft-veillette-core-yang-library in state
> Call For Adoption By WG Issued (entered by Carsten Bormann)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-veillette-core-yang-library%2F&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123365593&sdata=r0Q%2F%2BiyhhWFRFeGUI0n0IXUVjk9m%2BcXSxyQfvDGtSUs%3D&reserved=0>
>
>
>
>
>
> I do not know if there is a clear problem statement presented and agreed
> upon by the CORE WG yet.
>
> The YANG Library (RFC 8525) is used by a server to provide a client with
> details about the YANG modules
>
> that are implemented in the server.
>
>
>
> The draft proposed for adoption is a cut-and-paste-and-replace version of
> this RFC.
>
> The strings used as list keys (e.g., /yang-library/module/name) are
> replaced by SID values.
>
> Other key leafs such as /yang-library/schema/name are replaced by int8
> leafs instead of strings.
>
>
>
> IMO there are better solution approaches, considering that this data
> structure will be
>
> relatively static, and there is a caching mechanism built into RFC 8525 to
> reduce
>
> retrieval of the entire YANG library.
>
>
>
> It does not seem realistic that a server would have only SIDs installed
> and no way to get the module names.
>
> This is a short list, unlike the list of YANG data nodes. So it should be
> OK to simply augment the existing module
>
> with SID values.  If the list key replacements are really needed, then a
> deviation module could be used by CORECONF
>
> (e.g. deviate replace {type-stmt}) instead of a replacement module.
>
>
>
> I agree it will be important for a CORECONF client to determine the YANG
> library details for each server.
>
> This could be offline data or directly retrievable from the server. The
> solution need to be resolved by the WG.
>
> I support the problem statement by not this solution.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> Comment:
> Till 2019-07-18
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=02%7C01%7C%7C2489ae00202046b470fc08d70f05624c%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636994388123375588&sdata=bDB3hCRSWLR%2BTWigUMmLlTSndkumQc469l46HjE%2BgPI%3D&reserved=0>
>
>