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.
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?
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]
<mailto:[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]
<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
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] <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/>
>
> _______________________________________________
> 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] <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
