On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund <m...@tail-f.com>
> wrote:
> >
> > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <m...@tail-f.com>
> > > wrote:
> > > >
> > > > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder <
> > > > > > j.schoenwael...@jacobs-university.de> 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?
>
> No, the values of these nodes in the operational state datastore will
> be used (these are the "applied configuration" values).
>
> > 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.
>
> No, see above.
>
>
Sec 5.1 of the RD draft does not mention config=true nodes.
augment /foo {
when "blah";
}
The XPatch context node for this when-stmt is /foo, which is a config=true
node.
Sec 5.1 says
o If the XPath expression is defined in a substatement to a data
node that represents system state, the accessible tree is all
operational state in the server. The root node has all top-level
data nodes in all modules as children.
The augment is a top-level statement in this example, so this text
does not apply
> /martin
>
Andy
>
>
>
> >
> >
> >
> > > /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
> > > > > > > > netmod@ietf.org
> > > > > > > > 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
