>
> ,,,,
> > >
> > Sec 5.1 of the RD draft does not mention config=true nodes.
>
> The operational state datastore's schema is all config true and all
> config false nodes.
>
>
This actually changes the behavior of YANG XPath.
container foo {
leaf A { type int8; }
leaf B {
when "../A > 3";
type int8;
config false;
}
}
It has always been OK for a config=false data node's XPath expression to
point at a config=true data node.
But this has always meant the configured value. RD changes this behavior
because the new opstate datastore
contains only the operational values of config=true nodes. Now there is no
way for such an XPath expression
to test the configured value.
> >
> > 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
>
> Ok, so is your point that this text needs to mention augment as well?
> This text was copied (and modified) from 6.4.1 of RFC 7950, and that
> text doesn't mention augment either...
>
The text is misleading -- it should really be the config-stmt value of the
effective context node
that matters. A top-level augment has no config-stmt value.
>
> /martin
>
Andy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
