Kent Watsen <[email protected]> writes: > [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.
Well, in fact hostname does need an op-state copy, and it's IMO a gap in ietf-system that it doesn't provide one. Even if there is a configured value, the system may use something else, perhaps because somebody ran "hostname" command in the mean time. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
