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 <rwil...@cisco.com> 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
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
