Is it necessary to list all dependencies of a YANG module during a conversion?

[jean-christophe-manciot]

pyang 2.5.2 python3 3.9.8-1

Let's take an example by converting a YANG module into jtox: 1) without listing any dependency:

pyang --format jtox --output openconfig-network-instance@2021-07-22.jtox openconfig-network-instance@2021-07-22.yang

2) with listing all directly imported modules:

pyang --format jtox --output openconfig-network-instance-with-dependencies@2021-07-22.jtox openconfig-network-instance@2021-07-22.yang ietf-inet-types@2013-07-15.yang ietf-yang-types@2013-07-15.yang openconfig-aft@2021-08-06.yang openconfig-bgp@2021-06-16.yang openconfig-evpn@2021-06-11.yang openconfig-extensions@2020-06-16.yang openconfig-igmp@2021-05-17.yang openconfig-interfaces@2021-04-06.yang openconfig-isis@2021-06-16.yang openconfig-local-routing@2020-03-24.yang openconfig-mpls@2021-06-16.yang openconfig-network-instance-l3@2018-11-21.yang openconfig-network-instance-types@2021-07-14.yang openconfig-ospfv2@2021-03-17.yang openconfig-pim@2021-06-16.yang openconfig-policy-forwarding@2021-08-06.yang openconfig-policy-types@2018-11-21.yang openconfig-routing-policy@2020-08-18.yang openconfig-segment-routing@2021-07-28.yang openconfig-types@2019-04-16.yang openconfig-vlan@2021-07-28.yang

We get 2 different jtox files:

ls -al openconfig-network-instance*@2021-07-22.jtox
-rw-r--r-- 1 root root 195882 Mar 23 11:19 'openconfig-network-instance@2021-07-22.jtox'
-rw-r--r-- 1 root root 272905 Mar 23 11:18 'openconfig-network-instance-with-dependencies@2021-07-22.jtox'

In the second case, I have not included the nested imported YANG modules for simplicity sake.

So, is it necessary to list all (including nested) dependencies of a YANG module during a conversion?

[llhotka]

You needn't specify import-only modules that only provide groupings and/or typedefs, but you have to specify implemented modules that define their own data hierarchies or augments.

Note that you can list all implemented modules in a NETCONF hello file, and then use it with the --hello option.

[jean-christophe-manciot]

I'm a little confused.

pyang is able to list all imported modules by itself, right? So, for all of those which "define their own data hierarchies or augments", it is necessary to specify them alongside the original module, because pyang cannot figure this by itself?. I must be missing something here.

[llhotka]

This is the difference between implemented and import-only modules, see sections 5.6.5 and 7.1.5 in RFC 7950. Simply, if module A imports B, and then either augments a target node in B or uses a node in B in a path statement, then both A and B have to be implemented (and listed as command-line parameters of in a hello file passed to pyang).

I haven't checked but I assume that you have modules of both types in the command line parameters above.

[jean-christophe-manciot]

Thanks for your answer.

• For the modules which are not imported into module A but augments it, I can understand why it is necessary to specify them alongside module A as they stand 'outside'.
• For all modules which are imported/included, it seems clearly possible for pyang to figure out whether they are import-only or implemented.
• same remark for all modules recursively imported/included into previous ones.

So, I guess there is room for improving pyang there.

Regarding my example: if I follow your explanation 'if module A imports B, and then either augments a target node in B or uses a node in B in a path statement' and 7.1.5 in RFC 7950, since in openconfig-network-instance@2021-07-22.yang there is:

• no augment statement,
• no deviation statement (obviously for a standard module),
• no path statement involving any of the imported modules,
• no must statement involving any of the imported modules,
• several when statements involving only oc-ni-types

there should not be any need to add any dependency alongside openconfig-network-instance except openconfig-network-instance-types@2021-07-14.yang for the conversion.

Does that sound correct to you?

However,

pyang --format jtox --output openconfig-network-instance-with-dependency@2021-07-22.jtox openconfig-network-instance@2021-07-22.yang  openconfig-network-instance-types@2021-07-14.yang

leads to a file very different from the second jtox. Is this expected?

ls -al openconfig-network-instance*.jtox
-rw-r--r-- 1 root root 195882 Mar 23 11:19 'openconfig-network-instance@2021-07-22.jtox'
-rw-r--r-- 1 root root 272905 Mar 23 11:18 'openconfig-network-instance-with-dependencies@2021-07-22.jtox'
-rw-r--r-- 1 root root 195879 Mar 24 17:51 'openconfig-network-instance-with-dependency@2021-07-22.jtox'

[jean-christophe-manciot]

If I follow your first explanation, the only imported modules which "define their own data hierarchies" are:

• openconfig-bgp@2021-06-16.yang
• openconfig-interfaces@2021-04-06.yang
• openconfig-local-routing@2020-03-24.yang
• openconfig-routing-policy@2020-08-18.yang
• openconfig-vlan@2021-07-28.yang

Converting module A with them leads to a file very similar to the second one:

pyang --format jtox --output openconfig-network-instance-with-5-dependencies@2021-07-22.jtox openconfig-network-instance@2021-07-22.yang openconfig-bgp@2021-06-16.yang openconfig-interfaces@2021-04-06.yang openconfig-local-routing@2020-03-24.yang openconfig-routing-policy@2020-08-18.yang openconfig-vlan@2021-07-28.yang

leads to openconfig-network-instance-with-5-dependencies@2021-07-22.jtox:

ls -al openconfig-network-instance*.jtox
-rw-r--r-- 1 root root 195882 Mar 23 11:19 'openconfig-network-instance@2021-07-22.jtox'
-rw-r--r-- 1 root root 272902 Mar 24 18:02 'openconfig-network-instance-with-5-dependencies@2021-07-22.jtox'
-rw-r--r-- 1 root root 272905 Mar 23 11:18 'openconfig-network-instance-with-dependencies@2021-07-22.jtox'
-rw-r--r-- 1 root root 195879 Mar 24 17:51 'openconfig-network-instance-with-dependency@2021-07-22.jtox'