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

[Michel Veillette <[e-mail]>]

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.

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

Regards
Michel

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]<mailto:[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]<mailto:[e-mail]>>; IETF Secretariat <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Core <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: 12 juillet 2019 17:16
To: IETF Secretariat <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Core <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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>