On 11/06/2017 11:41 AM, Robert Wilton wrote: > > > On 06/11/2017 15:51, Lou Berger wrote: >> >> >> On November 6, 2017 10:21:19 AM Robert Wilton <[email protected]> wrote: >> >>> Hi Lou, >>> >>> All of proposed solutions (A through D) allow the action or the RPC to >>> perform whatever behaviour that it wants. >>> >>> This issue is only about which datastore is used to evaluate and check >>> that the parameters for the action/rpc are valid. E.g. if the >>> parameters use when, must, leaf-ref, or instance-identifier. >>> >>> So, to take option "A" for example: "A. Always use <operational> for 1 >>> and 2." >>> >>> One can still define a RPC that modifies another datastore ("edit-data" >>> in the NETCONF NMDA draft is one such example). But to check whether >>> the edit-data request can be performed, any input parameter constraints >>> would be evaluated against <operational>. However, given that the input >>> parameters to edit-data don't contain any when, must, leaf-ref, or >>> instance-identifier statements then it makes absolutely no functional >>> difference which the datastore the parameters are evaluated in, since >>> the result will always be the same regardless. But perhaps it just >>> feels a little odd that they are conceptually evaluated against >>> operational, even though the RPC only even affects one of the editable >>> configurable datastores. >>> >> >> >> Yes, which is why I've been assuming we'd end up with c. > > But I think that to do C properly also requires a new optional statement > in YANG to indicate where the Action/RPC parameters are evaluated (with > the default being <operational> if the new statement isn't specified). > > Most RPCs/Action statements seem to naturally apply to <operational>. > > For the RPCs/Action statements that don't naturally apply to > <operational>, it seems that it mostly doesn't matter where the > parameters are evaluated. > > At the moment, the set of remaining RPCs/Actions (don't apply to > <operational> but do care about parameter evaluation) seems quite small: > (i) RFC7517, if it defined a YANG model for the <partial-lock> RPC > (ii) A partial datastore diff from a subtree in <intended> to > <operational> might be another - it would want an instance-identifier > path to the subtree in <intended>. > (iii) Perhaps I2RS and dynamic datastores may also throw up some new > examples.
The tags draft has an RPC to 'reset to default state'. I could see wanting the reset to be persistent or not depending on actual usage... Lou > > Thanks, > Rob > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
