On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <[email protected]> > wrote: > > > > > Andy Bierman <[email protected]> wrote: > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > [email protected]> wrote: > > > > > > > > > Andy, > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > discusses > > > > > the XPath context. An xpath expression in a config-false container > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > augment /foo { > > > > when "some condition"; > > > > container stats { } > > > > } > > > > > > Do you mean that stats is a config true container? And presumably in > > > the stats containter you have config false leafs? > > > > > > > > no -- stats is a config false container > > Ok. Well, then this is also ok. The stats container will exist if > "some condition" is true in the operational state datastore. > > > > I think this works as expected. In a conventional datastore > > > (e.g. running), the stats container exists if "some condition" is true > > > in that datastore. > > > > > > > > > no -- in my example the desire is to augment the operational state based > on > > the > > operational value of a config=true leaf > > Yes, that will happen in both cases. > > > > In the operational state, the stats container exists if "some > > > condition" is true in that the operational state datastore. > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > augment /foo { > > > > container stats { > > > > config false; > > > > when "different condition"; > > > > } > > > > } > > > > > > In this case the stats container will never exist in any conventional > > > datastore, since it is config false. > > > > > > In the operational state, the stats container exists if "different > > > condition" is true in that the operational state datastore. > > > > > > > Forcing the augmenting node to be the XPath context node impacts the > > > > possible expressions. > > > > I think the RD draft should make all this clear. > > > > > > This is not different from how it works today wrt candidate vs running > > > for example. > > > > > > > no -- the datastore doesn't change based on the context node config-stmt > > value > > for candidate and running. > > The datastore doesn't change with NMDA either - an XPath expression is > always evaluated in a particular datastore, just like before. There > is no mechanism to read data from a different datastore in the XPath > expressions. > > > But in the first example the when-stmt is evaluated in the context of /foo which is config=true. Doesn't that mean the configuration values will be used? The config=false nodes added if the when-stmt is true are not the context nodes in the first form. Authors need to be careful to put the when-stmt in a config=false context node in order to evaluate in the operational datastore. > /martin > Andy > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > > > especially wrt/ counters and other objects that are not > > > > > > related to intended config vs. applied config. > > > > > > > > > > > > Q1) how does a client know the difference between an > auto-generated > > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG > extension > > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > > > Q2) How does XPath reference an operational node if the > /foo-state > > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > > > module foo { > > > > > > > > > > > > container foo { > > > > > > leaf stat-collect-type { > > > > > > type enumeration { > > > > > > enum stat-set1; > > > > > > enum stat-set2; > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > container foo-state { > > > > > > config false; > > > > > > leaf stat-collect-type { > > > > > > type enumeration { > > > > > > enum stat-set1; > > > > > > enum stat-set2; > > > > > > } > > > > > > } > > > > > > container stat-set1 { > > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > > ... > > > > > > } > > > > > > container stat-set2 { > > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > > ... > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > In this example, there is a request stat collect type > > > > > /foo/stat-collect-type > > > > > > and there is an operational value (what the server/device is > capable > > > > > > of collecting -- e.g. client requests stat-set2 knowing the > server > > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > > > So if /foo-state is folded into /foo (because that is the intent > -- > > > to > > > > > get > > > > > > rid of this extra stat-collect-type leaf), then how do the > when-stmts > > > > > > get applied to the operational value instead of the configured > value? > > > > > > The same issue applies if the when-stmts are within an > augment-stmt > > > > > > > > > > > > WANT: > > > > > > > > > > > > augment /foo-state { > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > container stat-set1 { > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > RD Provides: > > > > > > > > > > > > augment /foo { > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > container stat-set1 { > > > > > > config false; > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > There is no way to use when-stmt to reference the operational > value. > > > > > > This is a rather common usage of the when-stmt, so it should not > > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > [email protected] > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
