> On 12 Sep 2016, at 18:33, Andy Bierman <[email protected]> wrote:
>
>
>
> On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka <[email protected]> wrote:
>
> > On 12 Sep 2016, at 15:33, Juergen Schoenwaelder
> > <[email protected]> wrote:
> >
> > Hi,
> >
> > I think Section 8.3.3. provides an answer:
> >
> > When datastore processing is complete, the final contents MUST obey
> > all validation constraints. This validation processing is performed
> > at differing times according to the datastore. If the datastore is
> > <running/> or <startup/>, these constraints MUST be enforced at the
> > end of the <edit-config> or <copy-config> operation. If the
> > datastore is <candidate/>, the constraint enforcement is delayed
> > until a <commit> or <validate> operation.
>
> But sec. 8.1 lists "when" conditions among properties that must be true in
> all data trees, so it can never be false in <candidate/> either.
>
>
>
> Both these statements seem wrong.
> The "when" statement is applied to candidate.
> It is not deferred at all.
>
> Each tree (candidate, running, startup) can have different contents.
> This will impact the evaluation of when-stmts. No tree can have any
> nodes that require when-stmt evaluation, and that evaluation result is
> "false".
> (May not be the same result as in other trees)
That's exactly what I am saying, no?
Lada
>
>
> My answer to Yves' question is that the edit-config has to be applied
> atomically, and the constraints verified of the final result (a tentative
> version of "running") in which A is already present, so the edit is accepted.
>
> Note, however, that the "when" expression should be
>
> when "../A";
>
> The one in the "dummy" module is always false.
>
> Lada
>
>
>
> Andy
>
> >
> > /js
> >
> > On Mon, Sep 12, 2016 at 01:27:52PM +0200, Yves Beauville wrote:
> >> Hi,
> >>
> >> I am trying to interpret this statement in Section 8.3.1 Payload Parsing of
> >> RFC 6020.
> >>
> >> o If data for a node tagged with "when" is present, and the "when"
> >> condition evaluates to "false", the server MUST reply with an
> >> "unknown-element" error-tag in the rpc-error.
> >>
> >> With the context node defined Section 7.19.5. The when Statement
> >>
> >> o If the context node represents configuration, the tree is the data in
> >> the NETCONF datastore where the context node exists. The XPath root node
> >> has
> >> all top-level configuration data nodes in all modules as children.
> >>
> >> I am providing this dummy module to illustrate my question:
> >>
> >> module dummy {
> >> namespace "http://dummy.com";;
> >> prefix "du";
> >>
> >> container root {
> >> leaf A {
> >> type empty:
> >> }
> >> leaf B {
> >> when "A";
> >> type uint32;
> >> }
> >> }
> >> }
> >>
> >> And I consider the following <edit-config> request, while A & B do not
> >> exist
> >> yet in the current datastore.
> >>
> >> <rpc message-id="101"
> >> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >> <edit-config>
> >> <target>
> >> <running/>
> >> </target>
> >> <config>
> >> <root xmlns="http://dummy.com";>
> >> <A/>
> >> <B>
> >> 3
> >> </B>
> >> </dummy>
> >> </config>
> >> </edit-config>
> >> </rpc>
> >>
> >> During the parsing of the payload of the <edit-config>, leaf "A" is not yet
> >> present in the running datastore. The "when" statement that controls "B"
> >> evaluates to false.
> >>
> >> Does this mean that the above edit-config request should be rejected with
> >> an
> >> "unknown-element" error-tag in the rpc-error? Or am I misinterpreting the
> >> RFC?
> >>
> >> Yves
> >
> >> _______________________________________________
> >> netmod mailing list
> >> [email protected]
> >> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
