Ladislav Lhotka <[email protected]> wrote: > Martin Bjorklund <[email protected]> writes: > > > Hi, > > > > Kent Watsen <[email protected]> wrote: > >> [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. > > > > I also re-read this document yesterday, and I agree with this > > conclusion. > > +1 > > > > > Note that section 5.19 of the recently published > > draft-ietf-netmod-rfc6087bis-03 contains text that tries to illustrate > > some of the issues around the problem of associating state with > > config. > > > >> 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. > > > > I am also confused by the terms "intended config" and "actual > > config", and the lifecycle of these objects in an asynchronous > > system. Is the idea that every leaf that you can configure exists in > > three different places: > > > > o as "actual config" (under the "config" container) > > o as "intended config" (under the "state" container) > > o as "operationally used value" (also under the "state" container, > > but presumably with a different name?) > > > > When a client tries to set this leaf in an asynchronous system, will > > the "intended config" value be set first, then the "actual config", > > and lastly the "operationally used value"? > > > > The examples in the document don't reflect this, so maybe I didn't get > > it right. > > I agree it is confusing, and in particular I don't get the naming - > intended configuration should be an operator's intention, > i.e. config=true, no?
That's what I thought, but not what the document says; hence the confusion. I am asking for clarification. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
