Re: [netmod] 'when' statement in edit-config payload parsing

[Vladimir Vassilev <[e-mail]>]

On 09/13/2016 12:57 PM, Juergen Schoenwaelder wrote:
> On Tue, Sep 13, 2016 at 12:42:07PM +0200, Vladimir Vassilev wrote:
>> On 09/13/2016 10:25 AM, Juergen Schoenwaelder wrote:
>>> On Tue, Sep 13, 2016 at 09:34:33AM +0200, Ladislav Lhotka wrote:
>>>>> On 13 Sep 2016, at 09:01, Yves Beauville <[e-mail]> wrote:
>>>>>
>>>>> 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".
>>>>
>>> I agree that this bullet in section 8.3.1 looks odd. Perhaps Martin
>>> recalls why this was written in the first place?
>>>
>>> /js
>>>
>>>
>> IMO it is that bullet that sets apart 'when' from 'must' statements. With
>> the current text 'when' statements should be evaluated along with
>> 'range',..., 'if-feature' etc. 8.3.1 specified validation statements upon
>> every <edit-config> while 'must' statements should be evaluated only upon
>> <commit> along with the rest of "description" statement validation checks
>> done. The designer should take care to not specify 'when' statements that
>> hinder incremental editing of the 'candidate' configuration.
>>
>> I use 'when' statements in models utilizing lists often with 'identity'
>> leafs in the parent chain of data nodes and only testing for the values of
>> those 'identity' leafs or the keys. Anything else IMO requires 'must'
>> statements with proper dedicated error messages. Following this rule
>> prevents situations where you need to have a single <edit-config> creating
>> multiple leafs with complicated dependency to satisfy the 'when' statements.
>>
>> Probably a clarification that the 'when' statement should evaluate to 'true'
>> after the <edit-config> is applied (e.g. to a copy of the edited
>> configuration for example) and not based only on the data content of the
>> <edit-config> RPC is what is needed.
> 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.

The usability of that is somewhat dependent on users not getting too 
creative with 'when' statements. In that case it will be hard to see why 
certain leafs and containers can not be created. Not even upon 'commit' 
since "unknown-element" is all the user gets. Carefully reading the 
models is the only solution in that case.

Vladimir