Re: [netmod] Action and RPC statements

[Lou Berger <[e-mail]>]

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 <[e-mail]> 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
> 
>