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]
<mailto:[email protected]>> wrote:
> On 12 Sep 2016, at 15:33, Juergen Schoenwaelder
<[email protected]
<mailto:[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
The following properties are true in a *valid data tree*:
... The must statement is listed here
-Xiang
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] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/netmod
<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/ <http://www.jacobs-university.de/>>
>
> _______________________________________________
> netmod mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
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
