Modules update to YANG 1.1

[exa-arrcus]

It has been quite some time since all OC models have been stuck on the original YANG 1.0 (RFC6020). This is a limiting factor on various parts of the models (as well as new model design) and is even noted among comments.

mpls/openconfig-mpls-te.yang:            // Requires YANG 1.1
mpls/openconfig-mpls-te.yang:                // Requires YANG 1.1
mpls/openconfig-mpls-te.yang:        // Requires YANG 1.1
mpls/openconfig-mpls-te.yang:           // Requires YANG 1.1
mpls/openconfig-mpls-te.yang:            // Requires YANG 1.1
mpls/openconfig-mpls-te.yang:            // Requires YANG 1.1
policy/openconfig-routing-policy.yang:        //supported in YANG 1.1
policy/openconfig-routing-policy.yang:        //supported in YANG 1.1
policy/openconfig-routing-policy.yang:          //it is supported in YANG 1.1
policy/openconfig-routing-policy.yang:        //supported in YANG 1.1
policy/openconfig-routing-policy.yang:        //supported in YANG 1.1
policy/openconfig-policy-types.yang:      //YANG 1.1.  Until then, we will require this additional type
system/openconfig-aaa.yang:        //TODO:  in YANG 1.1 this should be converted to a leafref to
system/openconfig-aaa.yang:        //server group.  this will be possible in YANG 1.1
vlan/openconfig-vlan-types.yang:      // is expected to be in YANG 1.1.
vlan/openconfig-vlan.yang:        // TODO: in YANG 1.1, unions support leafref types which

Can we start making the move to 1.1 ? What has been the hesitiation if any thus far?

[aashaikh]

Most of these comments have to do with leafrefs in a union type to note where we've had to use a string to reference an element (which is not optimal from a modeling perspective but hasn't been a significant issue in practice AFAICT).

There is an impact of this change on toolchains, etc., particularly for code generation. Are there specific requirements / benefits we would get by moving to 1.1 ? What is needed from 1.1 for new models ?

[exa-arrcus]

What is mostly referenced above is actually an issue in practice and something that we currently solve by use of deviation and use of YANG 1.1 to implement leafrefs in unions. Loose definitions such as strings put the onus on tighter checks around backend validation and possible conflicts with other types in the union (not necessarily visible to the module consumer)

Others are the use of default values in leaf-lists (quite common across the model-set), identityref functions (derived-from()/derived-from-self())

So when proposing additions upstream, since 1.0 is currently enforced in the model-set, none of above can be used and must be stripped prior to the pull request. Functionally then, each implementation has to handle the gaps in unique ways.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.