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.
Andy
On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev <[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]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
