Model scoping, reuse and the design implications

[earies]

The public repository of OpenConfig is primarily focused on "network element" device models (router/switch) with a few exceptions (wifi, manifests, ate). In addition, there are a number of external projects (both in OpenConfig and outside) that have expressed interest to leverage and/or extend the model-sets for varying use-cases.

As discovered in the following CI check: https://github.com/openconfig/public/pull/1183#issuecomment-2372565244, the scoping. importing and reuse of YANG groupings can pose issues and limitations to the forward progress of expressing desired intent. This has been seen in prior PRs as well often introducing the circular dependency dilemma.

I'd like to raise this issue to address awareness and initiate discussion (in upcoming operator/community meetings) towards the following:

• When a model should or should not exist within the public repository (and incorporated into the entire collective CI pipeline)
• When is a domain of intended use best suited for separate repository (cross leveraging from outside, potentially not following OC style/design, etc...)
• Scoping of device vs. network/controller viewpoints and the impacts towards instance-identifiers
• Impacts on reuse when anchor points are reimplemented/redefined
• Impacts on restrictions necessary to accommodate unrelated domains/intent (Falling back to the inability to express per the modeling language)

As model sets and scopes grow, the issues will exacerbate and the less that one can express within the available YANG language. This results into encoding desired behaviors into description statements or separate specification documents -> special handling -> greater likelyhood of interpretation and implementation differences.