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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
