Thank you Lada. It makes perfect sense now.
Yves
On 9/13/2016 9:34 AM, Ladislav Lhotka wrote:
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
