Re: [netmod] XPath questions about revised datastores

[Andy Bierman <[e-mail]>]

On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder <
> > [e-mail]> 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


> 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



> 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.



>
>
> /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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <http://www.jacobs-university.de/>
> > >
>