Subject: [netmod] accessible tree for rpcs?

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Aug 2017 15:37:36 +0000

RFC 7950, S6.4.1. (XPath Context) says:

   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.

Does it make sense for input/output to access "all state data in the
server, and the running configuration datastore"?  How would this be
used?

Kent  // contributor

---

From: Alex Campbell <[email-masked]>
Date: Tue, 1 Aug 2017 23:50:44 +0000

Why would it not make sense? Is your question about the datastores proposal?

Usually an action will refer to some object that is defined as configuration and/or state, and may depend on the particular properties of that object.
Here is a YANG fragment showing one possible application:

    list ospf-instance {
        config true;
        leaf id {type string;}
        leaf supports-graceful-restart {type boolean;}
    }

    rpc ospf-graceful-restart {
        input {
            leaf instance-id {type leafref {path "/ospf-instance/id";}}
            must "/ospf-instance[id=current()/instance-id]/supports-graceful-restart = 'true'" {
                error-message "Instance does not support graceful restart";
            }
        }
    }

As another application, a "mute transmitter" command might only apply to digital radio interfaces.

Alex

________________________________________
From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: Wednesday, 2 August 2017 3:37 a.m.
To: [email-masked]
Subject: [netmod] accessible tree for rpcs?

Kent  // contributor

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Aug 2017 14:51:52 +0000

Hi Alex,

> Why would it not make sense? 

Firstly, it seems outside the norm.  At least, I'm unaware of any other IDL that allows for such linkage.  Second, I'm trying to understand the value.  For instance, how does it benefit the module designer, the server developer, the client developer?  (more on this below)

While not in the subject, my question extends to notifications as well.  Section 6.4.1 says that the accessible tree is "the notification instance, all state data in the server, and the running configuration datastore".  Notifications are particularly interesting given their one-way communication property.  In this regard, notifications are a bit like <operational> in that the server will/should send truth, regardless what the validation might allow.

> Is your question about the datastores proposal?

I wasn't thinking about it originally, but you raise a good point. Looking at revised-datastores, we see that the XPath context rules are revised in S5.1.  It seems like that <running> is no longer included (better), but the concern raised in this thread persists.  Just thinking about <running> no longer being included, this seems to break backwards compatibility.  For RPC's, neither NETCONF nor RESTCONF provide a mechanism to address a datastore.  And for actions, NETCONF again doesn't address a datastore, though RESTCONF does.  What this means is that a legacy server also supporting NMDA is unable to differentiate between if it should use old or new behavior.  Maybe it's a mute point, in that <operational> is a subset of <running>, but there is a semantic difference between something configured versus applied.

BTW, the restconf-nmda draft currently doesn't say anything about action statements, but it seems that it should restrict them to just <operational> under the {+restconf}/ds/ resource.  We wouldn't want to support, for instance, {+restconf}/ds/ietf-datastores:candidate/foobar/restart.  

> Usually an action will refer to some object that is defined as configuration
> and/or state, and may depend on the particular properties of that object.

About this example, my first thought is that RPC input is probably the most defensible example - RPC output or notification examples make even less sense.  With this example, the YANG is doing two things: 1) asserting that the instance exists and 2) asserting that the instance supports graceful restarts.  So:

  From a module designer perspective:
    - it is more exact than a description statement (but just mildly so), and
      note that the 'leaf' and 'must' statements should have 'description' 
      statements too

  From a server developer perspective:
    - it moves a little more of the validation into the input-parsing logic,
      but I'm sure that the server would throw an error anyway if the
      instance didn't exist or if it didn't support graceful restart.

  From a client developer perspective:
    - again, the leafref/must statements are more exact than description
      statements, but I don't believe that there is any expectation that
      a client would perform validation prior to sending the RPC.  Of
      course it could if it had a copy of the server's datastores (e.g.
      peer mount), but that doesn't guarantee anything unless the client
      is also going to use locking (which doesn't exist in RESTCONF)
      around the syncing of the server's data and the execution RPC.

We can do similar exercises with RPC output and notifications, but my position is that we'll find even less value.  Again, these provisions seem like a lot of complexity for little gain...

Kent  // contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Aug 2017 08:11:25 -0700

Hi Kent,

I objected to this expansion of XPath context when YANG 1.1 was being
developed.
Then I realized the YANG constraints are totally worthless so no reason to
do anything
about it.

The server will NEVER use these constraints.  It does not run XPath
validation on its own output.
The client can NEVER reliably use these constraints because they need to be
evaluated at the instant
the RPC or notification output is generated, and the client does not have
that snapshot
of the running or operational datastores.

So just ignore these YANG details.  That's all real tools can do with them
anyway.

Andy

On Wed, Aug 2, 2017 at 7:51 AM, Kent Watsen <[email-masked]> wrote:

> Firstly, it seems outside the norm.  At least, I'm unaware of any other
> IDL that allows for such linkage.  Second, I'm trying to understand the
> value.  For instance, how does it benefit the module designer, the server
> developer, the client developer?  (more on this below)
>
> While not in the subject, my question extends to notifications as well.
> Section 6.4.1 says that the accessible tree is "the notification instance,
> all state data in the server, and the running configuration datastore".
> Notifications are particularly interesting given their one-way
> communication property.  In this regard, notifications are a bit like
> <operational> in that the server will/should send truth, regardless what
> the validation might allow.
>
>
> I wasn't thinking about it originally, but you raise a good point. Looking
> at revised-datastores, we see that the XPath context rules are revised in
> S5.1.  It seems like that <running> is no longer included (better), but the
> concern raised in this thread persists.  Just thinking about <running> no
> longer being included, this seems to break backwards compatibility.  For
> RPC's, neither NETCONF nor RESTCONF provide a mechanism to address a
> datastore.  And for actions, NETCONF again doesn't address a datastore,
> though RESTCONF does.  What this means is that a legacy server also
> supporting NMDA is unable to differentiate between if it should use old or
> new behavior.  Maybe it's a mute point, in that <operational> is a subset
> of <running>, but there is a semantic difference between something
> configured versus applied.
>
> BTW, the restconf-nmda draft currently doesn't say anything about action
> statements, but it seems that it should restrict them to just <operational>
> under the {+restconf}/ds/ resource.  We wouldn't want to support, for
> instance, {+restconf}/ds/ietf-datastores:candidate/foobar/restart.
>
>
>
> About this example, my first thought is that RPC input is probably the
> most defensible example - RPC output or notification examples make even
> less sense.  With this example, the YANG is doing two things: 1) asserting
> that the instance exists and 2) asserting that the instance supports
> graceful restarts.  So:
>
> We can do similar exercises with RPC output and notifications, but my
> position is that we'll find even less value.  Again, these provisions seem
> like a lot of complexity for little gain...
>
> Kent  // contributor
>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Aug 2017 17:20:11 +0200

> So just ignore these YANG details.  That's all real tools can do with them

I tend to agree when it comes to the output / notifications.  But
things are less clear on the input - a server can reject the execution
of an operation if a must constraint on the input is not satisfied.

But yes, constraints on config false data, operations and
notifications are likely much less useful than constraints on
config true data.

/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: Andy Bierman <[email-masked]>
Date: Wed, 2 Aug 2017 08:50:47 -0700

> notifications are likely much less useful than constraints on
That's what I meant.
RPC input MUST be honored by the server or it is not implementing <rpc>
correctly.

Constraints on RPC output and notification output are for documentation
purposes.
A client could try to evaluate them with its own copies of the server's
running and
operational datastore contents, but I think the YANG definition says the
constraint
is enforced on the server.

Maybe NMDA could clarify this issue.

/js

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 2 Aug 2017 18:21:05 +0000

> That's what I meant.
> RPC input MUST be honored by the server or it is not implementing <rpc> correctly.
>
> Constraints on RPC output and notification output are for documentation purposes.
> A client could try to evaluate them with its own copies of the server's running and
> operational datastore contents, but I think the YANG definition says the constraint

What would be the update?  Would you change the XPath context text in Section 5.1
to not include the additional datastore contexts, or just add a clarification that any such
constraints are just conceptual and primarily for description purpose?  And, if the latter,
shouldn't it be a clarification on RFC 7950?

Kent