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 <[email protected]> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
