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 { }
}
Correct: Will evaluate when-stmt against operational:
augment /foo {
container stats {
config false;
when "different condition";
}
}
Forcing the augmenting node to be the XPath context node impacts the
possible expressions.
I think the RD draft should make all this clear.
/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
