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

From: IETF Secretariat <[email-masked]>
Date: Thu, 11 Jul 2019 08:32:29 -0700

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/

Comment:
Till 2019-07-18

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Jul 2019 14:16:29 -0700

> https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michel Veillette <[email-masked]>
Date: Mon, 15 Jul 2019 14:37:07 +0000

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

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%7C8bb9a04c432b4f951aa308d7070e41df%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636985630142011420&sdata=y3mqrhz4doIEmRBNsvjDgs9zMMd%2FuaRcNQNNLsWQ2pE%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
[email-masked]<mailto:[email-masked]>
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%7C8bb9a04c432b4f951aa308d7070e41df%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636985630142011420&sdata=wgigCDGdCpHKFejaAVbJ96Kqrw1ohGqKYMDlMBS2xZs%3D&reserved=0>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 23 Jul 2019 17:13:45 +0000

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 <[email-masked]>
Sent: 22 juillet 2019 20:33
To: Michel Veillette <[email-masked]>
Cc: Carsten Bormann <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>; IETF Secretariat <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Core <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Hi Andy

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 12 juillet 2019 17:16
To: IETF Secretariat <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Core <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

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>

Andy

Comment:
Till 2019-07-18

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jul 2019 11:52:14 -0700

On Tue, Jul 23, 2019 at 10:13 AM Michel Veillette <
[email-masked]> 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 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?

> 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
Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 22 juillet 2019 20:33
> *To:* Michel Veillette <[email-masked]>
> *Cc:* Carsten Bormann <[email-masked]>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi,
>
>
>
> 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 <
> [email-masked]> 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 <[email-masked]>; IETF Secretariat <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked];
> Core <[email-masked]>
> *Subject:* RE: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
> Hi Andy
>
>
>
> Simply augmenting the existing “ietf-yang-library” will increase its size,
> which makes this solution even less friendly to constrained devices and
> networks.
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 12 juillet 2019 17:16
> *To:* IETF Secretariat <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> Core <[email-masked]>
> *Subject:* Re: [core] The CORE WG has placed
> draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
>
>
>
>
>
>
>
> <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>
>
>
>
>
>
> <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>
>
>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 23 Jul 2019 20:22:01 +0000

Hi Andy

I understand that this data is transferred very infrequently. However, keeping the size under 1280 bytes has a significant advantage, it can be transferred using a single IPv6 datagram, without CoAP block for example.

ietf-constrained-yang-library also support an important scaling feature. Instead of using a content-id which is meaningful within the context of a single device, ietf-constrained-yang-library use a hash which allows caching of a YANG library for a group of devices. (e.g. thousands or millions od devices can share the same library)

For the current list of changes as listed in https://tools.ietf.org/html/draft-veillette-core-yang-library-05#section-3.2, which ones should we keep in a solution based on a deviation.

1- module-set 'name' and schema 'name' are implemented using an 8 bits unsigned integer
2- module 'name', submodule 'name' and datastore 'name' are implemented using a SID
3- 'feature' and 'deviation' are implemented using a SID
4- 'revision' fields are implemented using a 4 bytes binary string.
5- the mandatory requirement of the 'namespace' fields is removed

#5 seem to be a minimum
#2 an #3 can be optional if implemented as a union
#4 is a nice to have, 4 bytes instead of 10 bytes for each revision
#1 can also be optional if implemented as a union

Regards,
Michel

From: Andy Bierman <[email-masked]>
Sent: 23 juillet 2019 14:52
To: Michel Veillette <[email-masked]>
Cc: Core <[email-masked]>; Carsten Bormann <[email-masked]>; ivaylo petrov <[email-masked]>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

On Tue, Jul 23, 2019 at 10:13 AM Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy

{
  2368 : {
    +8 : [
      {
        +21 : "set1",
        +10 : [
          {
            +4 : "ietf-interfaces",
            +6 : "2018-02-20",
            +5 : "http://mydomain.com/yang/my-upgrade-module<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmydomain.com%2Fyang%2Fmy-upgrade-module&data=02%7C01%7C%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520210812&sdata=QuB6ynLZej%2BGyDvkxVM2KLs64JqZeKPa48OkYPPa8SM%3D&reserved=0>",

{
  2368 : {
    +8 : [
      {
        +21 : 1,
        +10 : [
          {
            +4 : 1500,
            +6 : h'20180220'
          },
          {
            +4 : 1600,
            +6 : h'20180222'
          },
          {
            +4 : 1700,
            +6 : h'20140806',

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 <[email-masked]<mailto:[email-masked]>>
Sent: 22 juillet 2019 20:33
To: Michel Veillette <[email-masked]<mailto:[email-masked]>>
Cc: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Hi,

Andy

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%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520220808&sdata=0xFFD%2B1GA9ET9nvmYJYJBqHHTAPl5jYJqUHSXsPXjYE%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

Hi Andy

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%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520220808&sdata=JESy70MJ7YNPxiOGeRIVN92lcqu8vk8v9wq16ifkqf8%3D&reserved=0>

Andy

Comment:
Till 2019-07-18

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
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%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520230800&sdata=TiSNn2E%2FQkZm2Tp359ieUosKEptM7SITfkOjFnqiN3k%3D&reserved=0>

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 24 Jul 2019 00:15:35 +0200

Hi all,

+1 for this call for adoption.

Alexander