On 04/12/2017 17:47, Andy Bierman wrote:
On Mon, Dec 4, 2017 at 9:05 AM, Ladislav Lhotka <[email protected]
<mailto:[email protected]>> wrote:
On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <[email protected] <mailto:[email protected]>> wrote:
> > Hi,
> >
> > if we have
> >
> > augment "/target/node" {
> > when "...";
> > ...
> > }
> >
> > is the "when" expression supposed to be evaluated separately
in each
>
> datastore,
> > and the augment applied only in those datastores where the
result is true?
>
> Yes.
But then it cannot be guaranteed that the schema for <operational>
is a superset
of the schema of configuration datastores - the when expression
can evaluate to
false in <operational> but true in <intended>.
I see your point now.
The server has to evaluate the when-stmts in operational.
I think that this is probably down to implementation, but I don't think
that this is necessarily required. A server is meant to conform to
'when' statements in <operational> (e.g. if the system is in a normal
steady state), but they are allowed to be violated, and I'm not
expecting that a server would evaluate them (except perhaps to discover
implementation bugs). Further, if violations of when statements in
<operational> are detected then I don't think that there is anything
that the server can reasonable do.
Even though the schema trees are the same, the client has a complex
task comparing
<intended> to <operational>.
I don't get why this isn't just a simple diff between the <intended> and
<operational> data trees. What is causing the complexity?
Thanks,
Rob
However it is no different than the existing
complexity comparing <candidate> to <running>.
Lada
Andy
>
> > RFC 7950 says in sec. 7.21.5 that the context node for XPath
evaluation is
>
> "the
> > augment's target node in the data tree", but with NMDA we have
multiple data
> > trees, hence multiple target nodes.
>
> We had multiple datastores even before NMDA. The when expression
> could be true in candidate but false in running.
>
> /martin
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
