Subject: Re: [netmod] Action and RPC statements

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Nov 2017 11:24:39 +0000

On 01/11/2017 06:36, Phil Shafer wrote:
> Robert Wilton writes:
>> ii) However, as far as I can see, it doesn't make sense for an action to
>> directly affect the contents of any configuration datastore, that should
>> be done via a purpose built rpc (like edit-config).
> An example action would be to retrieve the  fingerprint of an ssh
> key.  I might want to get the fingerprint of a key in <candidate>
> before I commit it.
>
> Or I could have an action that sets the SNMPv3 auth key to a random
> value, and I want to invoke that action against <candidate>.
>
> Seems like <startup> might also be an interesting place to target
> actions, but I can't think of a good example.
>
> There are always scenarios where something is useful, and the problem
> with ruling it out is that it becomes needed at some later point.
> We've a habit of ruling out things and later wishing we had them.
Yes, I have this concern.

>
> Is the easy fix to just put a datastore leaf under rpc/action and
> have it default to operational?  Any specific RPC can define its
> own datastore leaf of hard-code the database in the description
> (explicitly or implicitly <operational>), but the <action> RPC only
> gets this if we make a new parameter for it.

I think that an action/rpc statement should indicate in the schema where 
its input/output arguments are resolved against.  I.e. "configuration", 
"state", or "client-provided".  This would be specified by a new 
optional "resolve-to" YANG sub-statement to action/rpc, that defaults to 
"state" if not specified.

(i) Actions/rpcs that "resolve-to state" would resolve against 
<operational> (the default behaviour).
(ii) Actions/rpcs that "resolve-to configuration" would probably resolve 
against <intended>.
(iii) Actions/rpcs that "resolve-to client-provided" would require that 
an explicit datastore be specified as an input parameter to the action/rpc.

Actions of type "resolve-to client-provided" would be required to be 
invoked with a new <datastore-action> RPC that has a new target 
datastore input parameter.

RPCs of type "resolve-to client-provided" would be required to have an 
input parameter named "datastore" that is a leafref to a datastore.

Finally, I would propose that we defer defining the new "resolved-to" 
YANG statement and <datastore-action> RPC to YANG/NETCONF/RESTCONF 2.0, 
so that for the moment actions/rpcs always resolve against <operational> 
because that will be the default behaviour today, but with the 
understanding that this could be extended in future.

Thanks,
Rob

> Thanks,
>   Phil
> .

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Nov 2017 09:44:44 -0700

Hi,

So a server will be required to guess the correct datastore until it
finds the right one that matches the action instance?

   <action>
       <top>
          <list1>
             <key>10</key>
             <do-test>
                <datastore>candidate</datastore>
             </do-test>
          </list1>
        </top>
    </action>

The server will guess the datastore in some proprietary order and parse
instances of /top/ and /top/list1.  Then it finds the <do-test> action
and parses the input to get to the datastore and find out the real datastore
to use.  If the server guessed wrong, then it reparses the <action> against
the requested datastore.  Hopefully the schema trees match up.

Will vendors do all the extra work required to support this sort of thing?
I doubt it.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Nov 2017 17:16:29 -0400

Sorry, if I wasn't clear.  I meant the <datastore> element would
be directly under <action>, so the system knows where to start
looking for data.  Guessing is bad.

Thanks,
 Phil

Andy Bierman writes:
>--001a11411b0ad2d58d055cee96cb
>Content-Type: text/html; charset="UTF-8"
>Content-Transfer-Encoding: quoted-printable
>
><div dir=3D"ltr">Hi,<div><br></div><div>So a server will be required to gue=
>ss the correct datastore until it</div><div>finds the right one that matche=
>s the action instance?</div><div><br></div><div>=C2=A0 =C2=A0&lt;action&gt;=
></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;top&gt;</div><div>=C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0 &lt;list1&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0&lt;key&gt;10&lt;/key&gt;</div><div>=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;do-test&gt;</div><div>=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;datastore&gt;candidate&lt;/datas=
>tore&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;/do-=
>test&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;/list1&gt;</div><=
>div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;/top&gt;</div><div>=C2=A0 =C2=A0 &lt;/a=
>ction&gt;</div><div><br></div><div>The server will guess the datastore in s=
>ome proprietary order and parse</div><div>instances of /top/ and /top/list1=
>.=C2=A0 Then it finds the &lt;do-test&gt; action</div><div>and parses the i=
>nput to get to the datastore and find out the real datastore</div><div>to u=
>se.=C2=A0 If the server guessed wrong, then it reparses the &lt;action&gt; =
>against</div><div>the requested datastore.=C2=A0 Hopefully the schema trees=
> match up.</div><div><br></div><div>Will vendors do all the extra work requ=
>ired to support this sort of thing?</div><div>I doubt it.</div><div><br></d=
>iv><div><br></div><div>Andy</div><div><br></div><div><br></div><div><br></d=
>iv><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, O=
>ct 31, 2017 at 11:36 PM, Phil Shafer <span dir=3D"ltr">&lt;<a href=3D"mailt=
>o:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrote=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
>ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:<br>
>&gt;ii) However, as far as I can see, it doesn&#39;t make sense for an acti=
>on to<br>
>&gt;directly affect the contents of any configuration datastore, that shoul=
>d<br>
>&gt;be done via a purpose built rpc (like edit-config).<br>
><br>
>An example action would be to retrieve the=C2=A0 fingerprint of an ssh<br>
>key.=C2=A0 I might want to get the fingerprint of a key in &lt;candidate&gt=
>;<br>
>before I commit it.<br>
><br>
>Or I could have an action that sets the SNMPv3 auth key to a random<br>
>value, and I want to invoke that action against &lt;candidate&gt;.<br>
><br>
>Seems like &lt;startup&gt; might also be an interesting place to target<br>
>actions, but I can&#39;t think of a good example.<br>
><br>
>There are always scenarios where something is useful, and the problem<br>
>with ruling it out is that it becomes needed at some later point.<br>
>We&#39;ve a habit of ruling out things and later wishing we had them.<br>
><br>
>Is the easy fix to just put a datastore leaf under rpc/action and<br>
>have it default to operational?=C2=A0 Any specific RPC can define its<br>
>own datastore leaf of hard-code the database in the description<br>
>(explicitly or implicitly &lt;operational&gt;), but the &lt;action&gt; RPC =
>only<br>
>gets this if we make a new parameter for it.<br>
><br>
>Thanks,<br>
>=C2=A0Phil<br>
></blockquote></div><br></div></div></div>
>
>--001a11411b0ad2d58d055cee96cb--

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Nov 2017 14:35:32 -0700

> looking for data.  Guessing is bad.
Totally agree guessing is bad.
Did you see the <action2> proposal in a previous email?
That is exactly what I proposed, except I do not want to
overload <action> so the new template would be a different name.

I realize the expanded name of the datastore element prevents it from
being confused with top-level YANG nodes, but the conformance
is more clear with a new name.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Nov 2017 14:19:24 +0100 (CET)

Hi,

Trying to summarize this issue.

The problem is which datastore is used to:

    1a. evaluate action ancestor nodes
    1b. evaluate action input/output parameter leafref,
        instance-identifier, must, when
    2.  evaluate rpc input/output parameter leafref,
        instance-identifier, must, when

(Note that the side effects of an action/rpc is not part of this
issue)

I think it would be very weird if 1a and 1b were treated differently,
so I just label them as 1 below.

Possible solutions:

A.  Always use <operational> for 1 and 2.

    (This is what the current nmda draft says).

B.  Let the client specify the datastore for 1, and use <operational>
    for 2.

    (Note that this is trivial in RESTCONF (since the datastore is
    part of the URL), but would require a new parameter for NETCONF
    (or a new <action2>).
    
C.  Let the client specify the datastore for 1 and 2.

    This would require a new generic parameter for how RPCs are
    invoked in both NETCONF and RESTCONF.

D.  Like B, but let the description of the "rpc" statement optionally
    override this.

I prefer B and then D.

/martin

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Nov 2017 08:32:58 -0500

Martin,

If I have an RPC or action that changes state, how would the persistence of 
that state be indicated with an NMBA data stores.  I expected it to be 
related to the data store, but I read your mail below as saying otherwise
Thanks,
Lou

On November 6, 2017 8:20:12 AM Martin Bjorklund <[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Nov 2017 15:01:52 +0100

> D.  Like B, but let the description of the "rpc" statement optionally

I prefer A for now and I believe any of the other options may be
considered in the future (when we can provide proper support of YANG
and the protocols). I also believe that A covers a large number of
real-world use cases.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Nov 2017 15:49:13 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> Martin,
> 
> If I have an RPC or action that changes state, how would the
> persistence of that state be indicated with an NMBA data stores.  I
> expected it to be related to the data store, but I read your mail
> below as saying otherwise

The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of <edit-config>.  So with NMDA, this continues to work
like before.

/martin

> >> > ><div dir=3D"ltr">Hi,<div><br></div><div>So a server will be required
> >> > >to
> >> > gue=
> >> > >.=C2=A0 Then it finds the &lt;do-test&gt; action</div><div>and parses
> >> > >the
> >> > i=
> >> > >nput to get to the datastore and find out the real
> >> > >datastore</div><div>to
> >> > u=
> >> > >iv><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On
> >> > >Tue,
> >> > O=

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Nov 2017 10:03:30 -0500

So i guess this comes down to D listed below.  While i was expecting C, i 
think D is probably workable. How would you envision the override would be 
expressed?

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 6 Nov 2017 15:20:42 +0000

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.

Thanks,
Rob

On 06/11/2017 15:03, Lou Berger wrote:
> So i guess this comes down to D listed below.  While i was expecting 
> C, i think D is probably workable. How would you envision the override 
> would be expressed?
>
> Lou
>
>
>>> >> > >and parses the input to get to the datastore and find out the 
>>> real
>>> >> > datastore
>>> >> > >to use.  If the server guessed wrong, then it reparses the 
>>> <action>
>>> >> > against
>>> >> > >Will vendors do all the extra work required to support this 
>>> sort of
>>> >> > >thing?
>>> >> > >I doubt it.
>>> >> > >
>>> >> > >
>>> >> > >Andy
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >> >ii) However, as far as I can see, it doesn't make sense for 
>>> an action
>>> >> > to
>>> >> > >> >directly affect the contents of any configuration 
>>> datastore, that
>>> >> > should
>>> >> > >ss the correct datastore until it</div><div>finds the right 
>>> one that
>>> >> > matche=
>>> >> > ></div><div>=C2=A0 =C2=A0 =C2=A0 
>>> =C2=A0&lt;top&gt;</div><div>=C2=A0
>>> >> > =C2=A0 =
>>> >> > >=C2=A0 =C2=A0 =C2=A0&lt;key&gt;10&lt;/key&gt;</div><div>=C2=A0 
>>> =C2=A0
>>> >> > =C2=
>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 
>>> =C2=A0&lt;do-test&gt;</div><div>=C2=A0 =C2=A0
>>> >> > =C2=
>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>>> &lt;datastore&gt;candidate&lt;
>>> >> > /datas=
>>> >> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;/top&gt;</div><div>=C2=A0 
>>> =C2=A0
>>> >> > &lt;/a=
>>> >> > >ction&gt;</div><div><br></div><div>The server will guess the 
>>> datastore
>>> >> > in s=
>>> >> > >against</div><div>the requested datastore.=C2=A0 Hopefully the 
>>> schema
>>> >> > trees=
>>> >> > > match up.</div><div><br></div><div>Will vendors do all the 
>>> extra work
>>> >> > requ=
>>> >> > >o:[email-masked]" 
>>> target=3D"_blank">[email-masked]</a>&gt;</span>
>>> >> > wrote=
>>> >> > >&gt;ii) However, as far as I can see, it doesn&#39;t make 
>>> sense for an
>>> >> > acti=
>>> >> > >on to<br>
>>> >> > >&gt;directly affect the contents of any configuration 
>>> datastore, that
>>> >> > shoul=
>>> >> > >d<br>
>>> >> > >An example action would be to retrieve the=C2=A0 fingerprint 
>>> of an
>>> >> > >ssh<br>
>>> >> > >(explicitly or implicitly &lt;operational&gt;), but the 
>>> &lt;action&gt;
>>> >> > RPC =
>>> >> > >only<br>

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Nov 2017 10:51:23 -0500

> operational, even though the RPC only even affects one of the editable

Yes, which is why I've been assuming we'd end up with c.

Thanks,

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 6 Nov 2017 16:41:57 +0000

> 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.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 6 Nov 2017 11:48:23 -0500

>  (iii) Perhaps I2RS and dynamic datastores may also throw up some new

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Nov 2017 18:02:47 +0100

> wanting the reset to be persistent or not depending on actual usage...

In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 6 Nov 2017 17:08:19 +0000

Renaming this sub thread to avoid confusing the main discussion.

> 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

---

From: Lou Berger <[email-masked]>
Date: Mon, 6 Nov 2017 12:12:30 -0500

What's the standard way to reset a list to a default (based on
implementation)?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Nov 2017 09:15:54 -0800

> D.  Like B, but let the description of the "rpc" statement optionally

I prefer (A).

I do not see how this is transparent to non-NMDA clients that use actions
and/or rpcs.
The evaluation of config=true nodes change from <running> to <operational>.
This is a significant change that can break non-NMDA clients.

A non-NMDA client thinks the server is performing XPath evaluation according
to RFC 7950, sec. 6.4.1.

   o  If the XPath expression is defined in a substatement to an "input"
      statement in an "rpc" or "action" statement, the accessible tree
      is the RPC or action operation instance, all state data in the
      server, and the running configuration datastore.  The root node
      has top-level data nodes in all modules as children.
      Additionally, for an RPC, the root node also has the node
      representing the RPC operation being defined as a child.  The node
      representing the operation being defined has the operation's input
      parameters as children.

   o  If the XPath expression is defined in a substatement to an
      "output" statement in an "rpc" or "action" statement, the
      accessible tree is the RPC or action operation instance, all state
      data in the server, and the running configuration datastore.  The
      root node has top-level data nodes in all modules as children.
      Additionally, for an RPC, the root node also has the node
      representing the RPC operation being defined as a child.  The node
      representing the operation being defined has the operation's
      output parameters as children.

Andy

> > > >> >ii) However, as far as I can see, it doesn't make sense for an
> action
> > > to
> > > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;do-test&gt;</div><div>=C2=A0
> =C2=A0
> > > =C2=
> > > > match up.</div><div><br></div><div>Will vendors do all the extra
> work
> > > requ=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Nov 2017 18:17:07 +0100

What is default content of a list? Where is this coming from?

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 6 Nov 2017 17:20:22 +0000

> dislike custom operations that manipulate configuration datastores.
Yes.

I also dislike the idea of client managed persistent data that is not 
configuration.

E.g. I think that the subscriptions draft has this right:  It has 
configurable subscriptions, that are persistent; and rpc based dynamic 
subscriptions, that are not persistent.

If the tags draft defined RPCs to modify the module tags in a non 
persistent way then that would be OK with me (if this is actually 
useful), it is just that those actions/rpcs would end up only acting 
against the data in <operational>, and hence I think solution A would 
actually be sufficient for this case.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 6 Nov 2017 12:24:28 -0500

> What is default content of a list? Where is this coming from?
Whatever the vendor chooses in their code, and perhaps what gets defined
in future model definitions...
Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 6 Nov 2017 17:30:17 +0000

> in future model definitions...
This is mixing up config and state:

The device's default module tags wouldn't be in <running>, only in 
<operational>, [ and perhaps <intended>.]

Only the clients configured modification to the module tags ends up in 
<running>.  This is merged with the system module tags, and then the 
resultant set end up in <operational>.

Resetting the list to default is achieved by just deleting the list 
entry in <running>.  No special RPC is needed.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Nov 2017 13:45:49 -0500

Humm. I don't think this is how Chris is envisioning it. We can talk more 
next week when he presents.

Lou

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Nov 2017 13:06:35 -0000

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 06, 2017 2:01 PM
> and the protocols). I also believe that A covers a large number of

I prefer A.  I think it is the simplest and the one least likely to have
consequences that were not anticipated.  You could see this discussion
as being one of unanticipated consequences so I want the least change to
solve the problem, while thinking about what B (or C or D, roughly the
order of increasing uncertainty) really involves.

Tom Petch