On 09/13/2016 06:48 PM, Andy Bierman wrote:
Hi,
I am not in favor of changing when-stmt so it works like must-stmt.
I prefer it work as designed. It is like choice-stmt, where a new case
will cause objects from the previously selected case to be
automatically deleted.
There is no text in RFC 7950 that actually says an error is returned
if a when-stmt is false because an anyxml or anydata input parameter
was converted to top-level YANG nodes and reprocessed.
The text only covers direct when-stmts like below:
rpc plot-point {
input {
leaf point-type {
type enumeration {
enum 2d;
enum 3d;
}
mandatory true;
}
leaf X { type int32; mandatory true; }
leaf Y { type int32; mandatory true; }
leaf Z {
when "../point-type = '3d';
mandatory true;
type int32;
}
}
}
If the client sets point-type to '2d' and provides a Z leaf, then an
error is returned.
This is the only type of usage the text in question actually covers.
It is <edit-config> RPC that has started the thread (the 'when'
validation in <plot-point> is much clearer and I agree with all you say
above). There was the original example by Yves (changed when "A" to when
"../A"):
container root {
leaf A {
type empty:
}
leaf B {
when "../A";
type uint32;
}
}
... and the netconf <edit-config>:
<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>
There is consensus the 'when' statement is satisfied in this case which
answers his original question.
However if we make change to the original example by assuming the target
is not 'running' but 'candidate' and /root/A is already present before
the following <edit-config> is processed:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<root xmlns="http://dummy.com";>
<B>
3
</B>
</dummy>
</config>
</edit-config>
</rpc>
My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the
'when' statement is satisfied since when the <edit-config> is applied to
the 'candidate' configuration the result will be valid 'candidate'
configuration state and this is what matters. If there is consensus on
that I have nothing to add.
Vladimir
Andy
On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev
<[email protected] <mailto:[email protected]>> wrote:
On 09/13/2016 01:26 PM, Juergen Schoenwaelder wrote:
On Tue, Sep 13, 2016 at 01:19:02PM +0200, Vladimir Vassilev wrote:
I am wondering in which cases this is useful. Consider
a candidate
datastore - why would a 'when' expression have to true
after each
edit? Why do we force clients to send edits in such a
way that 'when'
expressions are true after each edit?
For example command line <TAB> completion in
/interfaces/interface can
evaluate all 'when' statements in child data nodes and
augmentations and
come up with relevant list of container and leaf child
completions based on
the already created /interfaces/interface/type (same
applies for the options
a user is presented with in a GUI after specifying the
'name' and 'type' of
the interface). It is the same with 'if-feature'
evaluations. The 'must'
statements however can be more complicated since they are
only checked when
the interactive incremental edit process is complete and
<commit> is
attempted.
I do not see what <TAB> completion has to do with the
processing of
edit-config on the server. Are people implementing <TAB>
completion by
sending edit-configs to a server? But yes, trying to enforce
constraints while doing <TAB> completion may lead to surprises for
people not understanding the constraints being enforced via
incremental <TAB> completion.
Well it means that the 'candidate' configuration can not be in a
state where any of the 'when' statements fail (since it is
modified only with <edit-config>). This is significant reduction
of the entropy and thus can be utilized for automation. In my
example that fact is used for <TAB> completion.
Vladimir
_______________________________________________
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
