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
