> On 13 Sep 2016, at 09:01, Yves Beauville <[email protected]> wrote: > > Hi Andi, Xiang, Juergen and Lada, > > Thank you all for clarifying. > > The scope of my original question was the context for evaluating a 'when' > expression during 'payload parsing' of an <edit-confg> RPC. > > Both RFC 6020 and RFC 7950 are providing the same requirement in section > 'Payload Parsing': > 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.
This section seems confusing. It makes no sense to evaluate "when" or "must" on the contents of a protocol message such as edit-config because accessible trees for XPath evaluations are defined in sec. 6.4.1 in terms of datastores and "all state data". > > Your replies provided clarifications on the validation, when the processing > is complete. Do I understand it correctly that, for an <edit-config> RPC, I > should ignore the above requirement during payload parsing and only consider > the validation of when statements when processing is complete? I would say so. Lada > > Thanks again, > Yves > > On 9/12/2016 7:33 PM, Andy Bierman wrote: >> >> >> On Mon, Sep 12, 2016 at 10:12 AM, Xiang Li <[email protected]> wrote: >> Hi Andy >> >> On 9/12/2016 11:33 AM, Andy Bierman 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) >>> >> >> I agree. RFC7950 section 8.1. "Constraints on Data", there is difference >> between >> "all data trees" and "a valid data tree". >> The following properties are true in *all data trees*: >> >> ... The when statement is listed here >> >> >> >> >> >> o There MUST be no nodes tagged with "when" present if the "when" >> condition evaluates to "false" in the data tree. >> >> >> This text seems fine. >> I can see how one might be confused by the text in 8.3.3 >> >> 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 takes place. >> >> The last sentence refers to the 8.1 para 3 bullet list for a valid data tree. >> >> The distinction in 8.1 between "all data trees" and a "valid data tree" is >> not obvious. >> The intent of the former is that the constraint applies immediately (as part >> of the >> current edit operation). The text could have been more direct that "all >> data trees" >> is really the candidate datastore tree. All other standard data trees are >> required >> to be valid data trees at all times. >> >> >> >> The following properties are true in a *valid data tree*: >> >> ... The must statement is listed here >> >> >> >> -Xiang >> >> >> Andy >> >>> >>> 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 >> >> _______________________________________________ >> netmod mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > 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
