Re: [netmod] OpsState and Schema-Mount

[Kent Watsen <[e-mail]>]

Before the "rule" I can choose to place monitoring in its own module
without any reliance on other modules.  If the monitoring does not share indexing,
what value is there in putting it in the config tree?  I see none except a poor
attempt at model classification.

[KENT] from opstate-reqs:

    4. Ability to relate configuration with its corresponding
       operational state.
           A.  Ability to relate intended config nodes to corresponding
                  applied config nodes
            B.  Ability to relate intended config nodes to associated derived
                  state nodes
            C.  The relationships need to be programmatically consumable



If the monitoring is rooting under config=true nodes, then those config=true
nodes need to be created somehow.  A client with write access is probably required.

[KENT] yes, but those config true ancestor nodes could be created by another client that has write-access, similar to POSIX filesystem.



Much easier to solve the conformance since /foo-state does not need any objects from /foo
to exist first.  Creating the /foo container means that all config=true requirements for
that container must be implemented (or complex deviations used)

[KENT] seems like an implementation detail.  The conceptual model is fine.   <get-config> and new <get-state> can have different views.  <get-config> should maintain the view of the config false nodes returned not including system-generated objects (e.g., interfaces), whereas <get-state> can also return system-generated objects, some of which may require also returning config true ancestor nodes.