Use of deviations in published OC models

[rgwilton]

The latest OC repository includes modules that deviate other modules. E.g.,

:~/git/OpenConfig-latest/release/all-models$ grep deviate *
openconfig-access-points.yang:    deviate not-supported;
openconfig-access-points.yang:    deviate not-supported;
openconfig-ap-interfaces.yang:    deviate not-supported;
openconfig-ap-interfaces.yang:    deviate not-supported;
openconfig-ap-interfaces.yang:    deviate not-supported;
openconfig-ap-interfaces.yang:    deviate not-supported;

This means that if you attempt to compile all of the OC modules (including the access-point related ones) into a single schema then some leaves (e.g., interface ip-unnumbered and system/config/hostname) that are expected to be used for non-access point deployments end up getting removed.

Please can we change how this modelling is done to avoid using deviations in the published YANG modules?

[jsterne]

+1. Those deviations prevent any implementation from supporting the full set of models.

[earies]

+1 - this was noticed some time back as well. The models within the repo have grown outside of a single type of entity modeling and since WiFi characteristics can alter some of the intention in the base models, there should be a distinct demarc that either involves some higher level folder classification or an entirely separate repo itself.

There are other repos (such as gNSI) that augment into the OC tree with data-models kept separate and outside of this public repo. I would propose any such cases where there are deviations also consider the same.

[jsnyder81]

I think from we can just remove deviate from the wifi models.