[netmod] Reset tags RPC [was Re: Action and RPC statements]

[Robert Wilton <[e-mail]>]

Renaming this sub thread to avoid confusing the main discussion.


On 06/11/2017 16:48, Lou Berger wrote:
> 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...
OK, I don't understand why this RPC is needed at all.

If the tags are managed through config (which I think that they are), 
then calling the "reset to default state" RPC should be equivalent to a 
normal list entry delete for that module anyway.

Why do you need two methods to achieve the same thing?  Or does this RPC 
do something slightly different?

Personally, I think that it would be better if the only way of editing 
configuration is through an <edit-config/edit-data> RPC.

A couple of other nits on the tags draft:
  - the tree diagram in 6.1 doesn't cover the config, perhaps it is out 
of date.
  - I would put list module-tags into a container (e.g. to make it 
easier to delete, or replace, all tag information).
  - do the configured tags replace the devices list or merge with them 
(perhaps this could be clarified)?  If merge, then presumably you also 
need a way to delete existing entries.  E.g. perhaps "grouping 
module-tags" also needs a separate leaf-list of tags to delete (really 
hide) from the implementation?

Thanks,
Rob


>
> Lou
>> Thanks,
>> Rob
>>
>>
> .
>