[As an individual contributor]
In preparation for our Virtual Interim meeting this Thursday, my primary goal
was to understand the problems needing to be solved. Hopefully this isn't too
much of a simplification, but there seems to be just the single core issue:
- no programatic mechanism to relate running state to intended
state (configuration). Currently, management systems must
code to the text found YANG description statements.
The draft then puts forth a a number of recommendations to address the issue
including:
- recommendation to put state in leafs
- recommendation to use a naming convention
- recommendation to have statement like operational true/intent/false
- recommendation to add to YANG a map statement (since lists don't support
deep keys)
- recommendation to allow config=true inside config=false containers
Some parts of the draft did not make sense to me. For instance, the
synchronous vs asynchronous discussion didn't seem to be connected to the
solution. Same for the desire to have an asynchronous push notification
mechanism. Separately, I don't agree that receiving NETCONF RPC-reply <ok/>
means that the intended configuration is operational, so much as "received by
the server". I also don't agree that every configured value has op-state -
e.g., consider a server's hostname.
Overall I agree that it would be nice if there was a programmatic mechanism to
relate intended and configured state, even if only for state nodes that are
identical to configured nodes. But I m struggling to understand the importance
of supporting generic clients that do not understand the semantics of a model
well enough to know where and how to consume its operational state.
Thanks,
Kent
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
