On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka <[email protected]> wrote:
>
> > On 12 Sep 2016, at 15:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de> 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)
> 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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
