Subject: [netmod] augment YANG 1.0 with YANG 1.1 OK?

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Oct 2017 13:11:22 -0700

Hi,

RFC 7950 has no text at all that addresses this specific point:

module if-aug {
  yang-version 1.1;
  namespace "http://netconfcentral.org/ns/if-aug";
  prefix ifa;
  import ietf-interfaces { prefix if; }
  revision "2017-10-14";

  augment "/if:interfaces-state/if:interface" {
    action reset {
      description "Reset this interface";
    }
  }
}

Both pyang and yangdump-pro accept this module with no warnings or errors.
Sec. 12 should address this issue.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 15 Oct 2017 09:52:06 +0200 (CEST)

> Sec. 12 should address this issue.

The intention was that this is legal, but as you note, for some reason
there is no explicit text in 7950 about this.

This was issue Y60, see
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 15 Oct 2017 12:56:42 -0700

> there is no explicit text in 7950 about this.

that's what I thought.

Can you spot the NMDA problem above?
Actually, it exists for in-line definitions, not just augment.

Once you collapse the interfaces-state tree into /interfaces, there is no
way to
specify whether an action is intended for <operational> or a configuration
datastore,
or all datastores.

The parent container or list may be config=true just because the foo-state
tree
was taken away, and the moved action effectively changed from config=false
to config=true.

There is no way for the YANG action-stmt to specify a datastore (or
config-stmt)
There is no way for the <action> operation to specify a datastore.

This was issue Y60, see

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Oct 2017 16:36:51 +0200

On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> Once you collapse the interfaces-state tree into /interfaces, there
> is no way to specify whether an action is intended for <operational>
> or a configuration datastore, or all datastores.
 
I think operations (both RPCs and actions) by default always execute
in the context of the operational state datastore. This is consistent
with the way we define the xpath context. An operation that operates
on other datastores needs to carry this information in its semantics
and typically requires special arguments to select the datastores
affected. This is how <get-config> and <edit-config> work. Hence, a
reset action defined for an interface by default applies to the
operational state datastore. And this default makes likely sense for
most actions and RPCs.

If an action or RPC is expected to operate on a different datastore,
the description must explain this and there may be a need to pass a
datastore identifier to the operation. [Yes, in retrospect, one might
have designed the protocol differently so that there would always be a
datastore parameter at the protocol level but its too late for that.]

/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, 18 Oct 2017 09:29:37 -0700

> operational state datastore. And this default makes likely sense for

OK -- seems correct

> datastore parameter at the protocol level but its too late for that.]

 A top-level RPC can also be used if a datastore parameter is needed,
or an <action2> wrapper can be defined.

The draft should be clear that the ability to invoke an action (within
a config=true parent data node) is removed. This is under-specified
in YANG so it is not really breaking anything.

/js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Oct 2017 13:26:30 -0700

> datastore parameter at the protocol level but its too late for that.]

IMO this needs to be simple and deterministic.
All YANG actions in an NMDA server are invoked against <operational>.

/js
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Oct 2017 23:32:33 +0200

> in YANG so it is not really breaking anything.

I do not know what 'within a config=true parent data node' means since
a config=true schema node can exist in different datastores. I assume
you mean 'a config=true data node in a configuration datastore".

Yes, it is not really defined in YANG today what an action under a
config=true schema node means (i.e., what you really act upon) but I
would rather leave it to an update of the YANG specification to
clarify this.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Oct 2017 23:36:01 +0200

> All YANG actions in an NMDA server are invoked against <operational>.

Well, yes, like all RPC operations - except that we have RPC
operations that do act on other datastores. ;-) But the generic
mechanism including any xpath contexts is against operational.  If the
semantics of the operation that say 'interpret parameter 5 as a
datastore name and act on that datastore', well then this is what the
designer wanted. This is how edit-config and friends work today.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Oct 2017 15:16:03 -0700

> designer wanted. This is how edit-config and friends work today.

Except this approach is ad-hoc and sub-optimal.
That's why NMDA <get-data> is better (because it is extensible yet not
ad-hoc).
IMO an <action2> wrapper would be a good addition for a YANG update

  <action2>
     <datastore>rd:running</datastore>
     <top>
         <foo>
           <test-action>
               ...
          </test-action>
        </foo>
   </top>
  </action2>

It is better to keep the YANG model decoupled from datastores,
and use a protocol parameter to make it explicit.

/js

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Oct 2017 16:34:53 +0100

Hi Andy,

To try and formally close this issue: We propose that no changes are 
made to the NMDA draft.

I think that you have raised two issues in this thread:

(1) All YANG actions in an NMDA server are invoked against <operational>.

We generally agree that module defined actions, and module defined RPCs 
and notifications, will generally apply to the operational state of a 
system, but this won't necessarily universally hold.  In particular it 
may not hold for any YANG modules that are defining generic behaviour 
(e.g. inactive configuration, templating solutions, I2RS, etc).  We 
don't think that this needs to be specified in the NMDA datastores 
draft, but would be better documented in a future revision of YANG.

(2) Define <action2>:

I'm not convinced that this is really required/helpful, given that most 
actions are likely to only apply to operational.  If it turns out that 
this is particularly useful then I would propose that this is deferred 
until a future revision of NETCONF, particularly because we are trying 
to keep the NETCONF NMDA and RESTCONF NMDA drafts as small as possible.

Is this OK?

Thanks,
Rob

On 18/10/2017 23:16, Andy Bierman wrote:
>
>
> On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > [email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
>     <http://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Oct 2017 10:13:35 -0700

On Tue, Oct 24, 2017 at 8:34 AM, Robert Wilton <[email-masked]> wrote:

> Hi Andy,
>
> To try and formally close this issue: We propose that no changes are made
> to the NMDA draft.
>
> system, but this won't necessarily universally hold.  In particular it may
> not hold for any YANG modules that are defining generic behaviour (e.g.
> inactive configuration, templating solutions, I2RS, etc).  We don't think
> that this needs to be specified in the NMDA datastores draft, but would be
> better documented in a future revision of YANG.
>
>
>

IMO the more complex NMDA is to implement, the less likely it will be
implemented.
If you want the tools to figure out the correct datastore(s) from
description-stmts
instead of something deterministic and machine-usable, NMDA is less likely
to be implemented.

Given that the same objects can be defined differently in each datastore in
NMDA,
it is especially useful to know which set of YANG modules applies, before
parsing instance
data against those modules.

(2) Define <action2>:
> actions are likely to only apply to operational.  If it turns out that this
> is particularly useful then I would propose that this is deferred until a
> future revision of NETCONF, particularly because we are trying to keep the
> NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
>
> Is this OK?
>

The NMDA theme has been to declare things that are possible in pre-NMDA
but not supported in post-NMDA to be not useful, so this can be left to
vendors I guess.

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Oct 2017 19:21:25 +0200

On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> 
> IMO the more complex NMDA is to implement, the less likely it will
> be implemented.  If you want the tools to figure out the correct
> datastore(s) from description-stmts instead of something
> deterministic and machine-usable, NMDA is less likely to be
> implemented.

There is nothing machine readable today that tells you which argument
of get-config identifies the datastore that is being accessed by
get-config. Our reasoning is that for most actions that default is
going to do the right thing. If there is a need to have further
language support to handle the cases where operations may relate to
datastores different than operational, then this should be taken up by
a future version of YANG.

> Given that the same objects can be defined differently in each
> datastore in NMDA, it is especially useful to know which set of YANG
> modules applies, before parsing instance data against those modules.

I am not sure I parse this correctly.

> but not supported in post-NMDA to be not useful, so this can be left to

Not sure I understand this either.

If you have a concrete change proposal, perhaps the discussion becomes
more concrete and productive.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Oct 2017 11:21:54 -0700

> a future version of YANG.
There is only 1 schema tree now in pre-NMDA so it is easy to parse
instance data against the one and only set of modules.

> I am not sure I parse this correctly.

The new YANG library requires the implementation to know the datastore
to pick the correct set of modules for the datastore used in the operation.
Module sets are allowed to overlap, so the same module can be different
in <running> vs. <operational>.

Developers unaware of the new NMDA complexities should read the drafts
again.

> this

I already said to declare that <action> is invoked in <operational>. Period.
No description-stmt exceptions.

If another datastore is needed, use rpc-stmt instead of action-stmt.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Oct 2017 13:08:51 +0200

It seems we are jumping between topics. I will skip over comments
concerning the YANG library and whether it is OK or not OK that YANG
library allows different schemas in different datastores.

> If another datastore is needed, use rpc-stmt instead of action-stmt.

So you are fine if for RPCs description statements can define which
datastores are affected by an RPC? I probably did not get that you
make a distinction between actions and RPCs here.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 08:54:39 -0700

> library allows different schemas in different datastores.
\
\

Actually, this is the only issue that matters.

I decided that no special text is needed because the YANG library is
violating a MUST requirement
in RFC 7950 and needs to be changed.

There can only be one implementation of a module per server, not per
datastore.
Therefore a module MAY appear in multiple module-sets, but it MUST NOT
be different.  The exact same revision, features, and deviations MUST be
present
in each instance.

Andy

> > > > > future revision of NETCONF, particularly because we are trying to
> keep
> > > the

---

From: Robert Wilton <[email-masked]>
Date: Wed, 25 Oct 2017 18:05:37 +0100

Hi Andy,

On 25/10/2017 16:54, Andy Bierman wrote:
>
>
> On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder 
Are you referring to this text, or something else:

5.6.5.  Implementing a Module

    A server implements a module if it implements the module's data
    nodes, RPCs, actions, notifications, and deviations.

    A server MUST NOT implement more than one revision of a module.

If, so, then we still agree with this constraint, and this hasn't 
changed for NMDA.  I think that YANG library should make this clear in 
the list of modules.

But I don't think that text specifically prevents different deviations 
or features for different datastores ...

> be different.  The exact same revision, features, and deviations MUST 
> be present
> in each instance.

The NMDA draft already states that the schema for all conventional 
configuration datastores must be the same (meaning that all deviations 
and features must be the same as well):

5.1. Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that share exactly the same schema, allowing data to be
    copied between them.

So, I think that the main question is about how the schema for 
<operational> can differ from the configuration datatstores.

We want to allow different features to be supported in running vs 
operational, so that feature statements can be useful to turn off 
features that may be supported by a device, but might not be externally 
configurable (e.g router-id).  But we could partially constrain their 
use.  So I propose that we add the following extra sentence to the NMDA 
draft on section 5.3  The Operational State Datastore (<operational>).

My proposed NEW text is:

If a YANG feature is supported for a module in any configuration 
datastore then it SHOULD also be supported in <operational>.  This is to 
allow the applied configuration and any other operational state 
associated with that feature to be available.  The inverse constraint 
does not hold, a server MAY support a feature in <operational> without 
also supporting it in any configuration datatstore.

I'm not sure that it makes sense to constrain deviations to be the same 
for all datastores, since these are the mechanism for reporting why a 
server doesn't conform to the standard ...

Thanks,
Rob

>     > > > > is particularly useful then I would propose that this is
>     deferred
>     > > until a
>     > > > > future revision of NETCONF, particularly because we are
>     trying to keep
>     > > the

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Oct 2017 19:14:13 +0200 (CEST)

Hi,

Robert Wilton <[email-masked]> wrote:
> features that may be supported by a device, but might not be
> externally configurable (e.g router-id).  But we could partially
> constrain their use.  So I propose that we add the following extra
> sentence to the NMDA draft on section 5.3  The Operational State
> Datastore (<operational>).
> 
> My proposed NEW text is:
> 
> datastore then it SHOULD also be supported in <operational>.  This is

I think this should be a MUST; if something is supported in the
conventional datastores, then the same schema must be used for the
applied config.

> to allow the applied configuration and any other operational state

I agree.

> I'm not sure that it makes sense to constrain deviations to be the
> same for all datastores, since these are the mechanism for reporting
> why a server doesn't conform to the standard ...

I agree.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 10:50:28 -0700

> > also supporting it in any configuration datatstore.

I disagree

> > why a server doesn't conform to the standard ...
I disagree

Features and deviations are are part of the one implementation.
Features are not mentioned in the cited text because they are inherently
optional and do not have to be implemented.

There is no text in RFC 7950 that supports the notion that an
if-feature-stmt
or a deviation-stmt can apply to a specific datastore.  It applies to the
object.

Good luck getting client developers to support conflicting schema trees
for the same module. Good luck comparing <running> to <operational>.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 11:09:34 -0700

On Wed, Oct 25, 2017 at 10:05 AM, Robert Wilton <[email-masked]> wrote:

> If, so, then we still agree with this constraint, and this hasn't changed
> for NMDA.  I think that YANG library should make this clear in the list of
> modules.
>
> But I don't think that text specifically prevents different deviations or
> features for different datastores ...
>

I think NMDA is creating much more complexity and disruption than is
required.
The original issue was the OpenConfig-style config/state trees.
The WG agreed that an RPC-based solution was needed so that the
YANG modules would not need to change (far too disruptive!).

Then the IETF proceeds to redo all the YANG modules anyway.
Now the server is allowed to implement the same module differently in each
datastore.
Now comparing the configured and operational value is even harder than
before.

None of this added complexity was in the OpenConfig proposal.
It was not even possible to have different features and deviations for the
same object in that proposal.

Andy

> configuration datastores must be the same (meaning that all deviations and
> features must be the same as well):
>
> operational, so that feature statements can be useful to turn off features
> that may be supported by a device, but might not be externally configurable
> (e.g router-id).  But we could partially constrain their use.  So I propose
> that we add the following extra sentence to the NMDA draft on section 5.3
> The Operational State Datastore (<operational>).
>
> My proposed NEW text is:
>
> If a YANG feature is supported for a module in any configuration datastore
> then it SHOULD also be supported in <operational>.  This is to allow the
> applied configuration and any other operational state associated with that
> feature to be available.  The inverse constraint does not hold, a server
> MAY support a feature in <operational> without also supporting it in any
> configuration datatstore.
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Oct 2017 21:49:29 +0200 (CEST)

> same object in that proposal.

Actually, this is not correct.  In both OC and the old IETF split tree
solutions, the configuration and operational state were modelled with
duplicate nodes, and you could certainly deviate these nodes
differently.

This said, I share your concern about complexity.  I also agree that
the only model that makes the client simple is that if all objects in
the config are also available with the same types in operational
state.  Otherwise comparison won't work (or be complicated).

But at the same time, the converse is not true.  I.e., if an object is
present in operational, it doesn't have to be configurable.

So what I think we want is that the schema for the conventional
datastore is a subset of the schema for operational.

This would allow an implementation that cannot support configuration
of let's say the MTU, to deviate the mtu with "not-supported" in the
conventional datastore, but it will still be available for inspection
in operational.

Does this make sense?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 14:21:57 -0700

> duplicate nodes, and you could certainly deviate these nodes
No, you cannot deviate the same schema node in different ways.
You can define or deviate 2 different schema nodes.
That is the unacceptable change to YANG and why I like the OC solution
better.

> state.  Otherwise comparison won't work (or be complicated).

Agreed.
A vendor can provide unusable APIs with any YANG module,
given the right deviations, so this cannot be a factor.
But the OC solution did not allow features to be different at all.

> present in operational, it doesn't have to be configurable.
Correct but maybe irrelevant.

I am only concerned with the same schema node being different in multiple
datastores.  This was never part of the OC requirement.

Each datastore can implement a specific subset of all the server modules.
That part is well-defined and the framework allows for lots of innovation
here
without modifying YANG at all.

> conventional datastore, but it will still be available for inspection

Non-overlapping subsets are fine.
Overlapping subset but the details are the same for each module are fine.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Oct 2017 18:46:45 -0700

> conventional datastore, but it will still be available for inspection

OK -- deviations for not-supported make sense per datastore
to resolve the missing-object ambiguity problem.
It is not realistic to expect every object in a module to be able
to report its operational state in the same release.
It is better to report not-supported than return nothing or return the
configured value as a guess.

If the admin-state and oper-state objects are different, 2 objects should
be used instead of per-datastore deviations of the syntax of 1 object.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Oct 2017 12:10:26 +0200 (CEST)

Agreed.

So based on this, how about this text:

  The schema for <operational> MUST be a superset of the combined
  schema used in all configuration datastores except that YANG nodes
  supported in a configuration datastore MAY be omitted from
  <operational> if a server is not able to accurately report them.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 26 Oct 2017 18:44:53 +0100

Hi ,

Separating out the issue regarding which datastore action and RPC apply 
to, we propose the following NEW text to the datastores draft:

6.2 Invocation of Actions and RPC Operations

   This section updates section 7.15. of RFC 7950.

   In YANG data models, the "action" statement may appear under "config
   true" and "config false" schema nodes.  While instances of both
   schema nodes may appear in <operational>, instances of "config true"
   schema nodes may also appear in other datastores.

   An NMDA compliant server MUST execute all actions in the context of
   <operational>.  Likewise, an NMDA compliant server MUST invoke all RPC
   operations in the context of <operational>, unless the RPC is explicitly
   defined as affecting other datastores (e.g., <edit-config>).

OK?

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 26 Oct 2017 18:53:07 +0100

Hi,

A refined version of the proposed text is below (because "schema" isn't 
defined):

>    <operational> if a server is not able to accurately report them.
Given that "schema" isn't defined, we propose using "datastore schema" 
instead:

NEW:

schema node - A node in the schema tree.  The formal definition is in 
RFC 7950.

datastore schema - is the combined set of schema nodes for all modules
supported by a particular datastore, taking into consideration any
deviations and enabled features for that datastore.

The below text is changed from "schema" to "datastore schema":

    The conventional configuration datastores are a set of configuration
    datastores that share exactly the same datastore schema, allowing
    data to be copied between them.  The term is meant as a generic
   umbrella description of these datastores.  The set of datastores 
include:

The proposed new text for operational would change to:

The datastore schema for <operational> MUST be a superset of the combined
datastore schema used in all configuration datastores except that YANG
nodes supported in a configuration datastore MAY be omitted
from <operational> if a server is not able to accurately report them.

Thanks,
Rob

> .

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 26 Oct 2017 11:22:54 -0700

Hi -

>    defined as affecting other datastores (e.g., <edit-config>).

A question - I understand the motivation for the "unless" for RPC
operations, but wonder why there is no similar "unless" for actions.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Oct 2017 11:42:26 -0700

> operations, but wonder why there is no similar "unless" for actions.

The <rpc> is not really in a datastore at all.
It may have input and output parameters with leafref and must/when
statements.
These are evaluated in the <operational> context.
The <rpc> may in fact be something like <edit-config>
which has parameters (like <config> to apply to
a specific datastore.

The action node is embedded within some data that has to be parsed
in a specific datastore before the action is processed.
This data is required to be in <operational>.
It also has XPath and leafref that needs to be resolved (same as <rpc>).

The side effects of the <rpc> or <action> can impact other datastores.
This would be defined in the description-stmt and this is not a problem.

Randy
Andy

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 26 Oct 2017 13:42:15 -0700

Hi -

On 10/26/2017 11:42 AM, Andy Bierman wrote:
> 
> 
> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi -
> 
>         Separating out the issue regarding which datastore action and
>         RPC apply to, we propose the following NEW text to the
>         datastores draft:
> 

Thus my question.  I don't see a substantial difference between
"impact" and "affect" when side effects are permitted.  It seems
that the scope of what is affected (think about the consequences
for someone formulating an access control policy) in both cases
MUST be documented in in the description-stmt.  The fact that the
action is bound to a particular chunk of data is only the tip of
the iceberg, and doesn't seem to make a difference in terms of what
the description-stmt needs to spell out.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Oct 2017 10:33:41 +0200 (CEST)

> This would be defined in the description-stmt and this is not a problem.

This is exactly right.  We need to capture this in the text.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 31 Oct 2017 14:14:20 +0000

Hi,

Here is another attempt for proposed text for Actions/RPC statements in 
NMDA.

<new>

6.2 Invocation of RPC Operations

This section updates section 7.14 of RFC 7950.

RPCs MAY be defined as affecting the contents of a specific datastore,
any configuration datastore (e.g., <edit-config>), or any datastore
(e.g., <get-data>).  The RPC definition specifies how the RPC input
data is interpreted by the server.

RPCs definitions that do not explicitly state an affected
datastore(s) modify the general operational state of the server.
Hence, if any RPC input data relates to data node instances then
those would generally resolve to data node instances in the
<operational> data tree.

6.3 Invocation of Actions

This section updates section 7.15 of RFC 7950.

Actions are always invoked on a data node instance that exist in the
<operational> data tree.  The behavior defined by an action statement
is generally expected to affect the operational state of the server
rather than directly modifying the contents of any configuration
datastore.

</new>

On a related note, I also want to confirm that it is right that RPC 
input data is always checked against operational:

Section 6.1. of the NMDA draft states:

    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 and all operational state
       in the server.  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.

Is <operational> always the right datastore to evaluate RPC input/output 
data relative to?  For most RPCs this seems to be the right choice by 
default but it also seems plausible that someone may wish to define an 
RPC that wants to validate its input parameters against the contents of 
another datastore.

An example could be an "is-applied" RPC that takes a path to a subtree 
in <running> or <intended> and checks whether the configuration for that 
subtree is fully represented in <operational>.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Oct 2017 16:14:15 +0100

On Tue, Oct 31, 2017 at 02:14:20PM +0000, Robert Wilton wrote:

> default but it also seems plausible that someone may wish to define an RPC
> that wants to validate its input parameters against the contents of another
> datastore.

Yes.
 
> An example could be an "is-applied" RPC that takes a path to a subtree in
> <running> or <intended> and checks whether the configuration for that

How is this different from say partial locks (RFC 5717)? Note that in
your example, you carry an xpath value as part of the RPC invocation
to the server and the RPC code on the server then is interpreting the
xpath value; this is not the same has having an xpath expression in
the definition of the RPC itself (e.g., as part of a constraint).

I believe we previously concluded that xpath expressions that are part
of the schema definition of an RPC / action are evaluated against
<operational>. I think this is a reasonable interpretation and we
can't affort a vaguely defined xpath context here.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 31 Oct 2017 15:35:38 +0000

Hi Robert,

> data is interpreted by the server. 

s/MAY/may/? - is this draft providing for this, or should it come from
e.g., RFC 7950?

> those would generally resolve to data node instances in the 

I reordered first sentence, and added a comma to the second:

RPCs modify the general operational state of the server, unless
explicitly defined to affect other datastores. Hence, if any RPC
input data relates to data node instances, then those would
generally resolve to data node instances in the <operational>
data tree. 

> schema nodes may also appear in other datastores. 

okay

> rather than directly modifying the contents of any configuration 

fixed plurality issue in first sentence, and removed wishy-washy 
language from the rest:

Actions are always invoked on a data node instance that exists in the 
<operational> data tree.  Action statements affect the operational
state of the server.

What do you think?

Kent // contributor

---

From: Robert Wilton <[email-masked]>
Date: Tue, 31 Oct 2017 15:56:51 +0000

> s/MAY/may/? - is this draft providing for this, or should it come from
I think that I prefer MAY because we are stating what RPCs are allowed 
to do, but don't feel strongly on this ...

> generally resolve to data node instances in the <operational>
Also OK with me.

> <operational> data tree.  Action statements affect the operational
This wishy-washy language is the tricky bit:

i) Actions are allowed to have any operational impact on the device 
(just as RPCs are), their behavior is not constrained in any way.

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

My text was aimed to allow (i) but not encourage (ii)  ...  If your text 
is sufficient for this then it is fine with me - I agree that it is 
simpler, and simpler is preferable.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Oct 2017 17:49:56 +0100

> generally resolve to data node instances in the <operational>

- s/the general operational state/the operational state/
- I also do not think that RPC generally modify state.

Or simply:

  References to data nodes in RPC description statements etc. are
  interpreted as references to data nodes in <operational> unless
  specified otherwise.
 
> <operational> data tree.  Action statements affect the operational

OR:

  References to data nodes in action description statements etc. are
  interpreted as references to data nodes in <operational> unless
  specified otherwise.

I think that the data node an action is bound to must exist in
operational state - this is consistent with the xpath context. But
what the other parameters mean is a matter of the action/RPC
semantics, as defined in the description statement. Or is there a
_technical_ reason to restrict this?

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 31 Oct 2017 17:12:57 +0000

> the definition of the RPC itself (e.g., as part of a constraint).
OK, thanks for the explanation, I get the distinction.

But what about if the input parameter was an instance-identifier (that 
you want to be resolved against the configuration datastore)? Wouldn't 
RFC 7950 section 9.13 + NMDA Sec 6.1 force that leaf in the input data 
to be resolved against <operational> instead?

> can't affort a vaguely defined xpath context here.
I don't think that it would necessarily be vaguely defined, instead it 
would be the description that defines the XPath context to use, 
defaulting to operational if not specified otherwise.

However, having said that, I can't think of a realistic example of when 
a must/when statement for an RPC against a configuration datastore would 
be useful ...

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Oct 2017 10:14:19 -0700

On Fri, Oct 27, 2017 at 1:33 AM, Martin Bjorklund <[email-masked]> wrote:

> ....
I don't think the new text is very clear.
The system side effects are irrelevant, but both the same for rpc and
action.

The only issues relevant to YANG are:
   - datastore used to evaluate action ancestor nodes
   - datastore used to evaluate input parameter leafref, must, when
   - datastore used to evaluate output parameter leafref, must, when

These properties cannot be modified by description-stmt.
Not now, not ever. Not for rpc. Not for action.

It is irrelevant to NMDA whether the rpc or action modifies a datastore,
starts a playlist on a jukebox, or makes some toast.

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 31 Oct 2017 10:22:49 -0700

Hi -

On 10/31/2017 10:14 AM, Andy Bierman wrote:
...
> The system side effects are irrelevant, but both the same for rpc and 

Knowing what the system side effects are is *ESSENTIAL* if these
things are to be of any use operationally.

> starts a playlist on a jukebox, or makes some toast.

But from the an operational or interoperabilty perspective,
that information is crucial.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Oct 2017 10:31:39 -0700

> that information is crucial.
I am not saying that the description-stmt is not needed.
Of course I need to know if the system will start a jukebox,
make toast, or delete all config in all datastores owned by user "fred".

The old text about resolving YANG for rpc and action is outdated.
Instead of <running> + config=false floating in space, it is all
well-defined
to be in the <operational> datastore now. That is all NMDA needs to convey.

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 31 Oct 2017 17:36:06 +0000

Hi Rob,

A few comments, inline

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Tuesday, October 31, 2017 7:14 AM
To: Martin Bjorklund <[email-masked]>; [email-masked]; [email-masked]; Randy Presuhn <[email-masked]>
Subject: Re: [netmod] Action and RPC statements

Hi,

Here is another attempt for proposed text for Actions/RPC statements in NMDA.

<new>

<ALEX> why “e.g., <get-data>”?  Does <get-data> affect the contents of the datastore – I thought it just gets data, hence this example is not ideal.

There is also no mention about the source of the “in” parameters.  It probably makes sense to mention that explicitly.

Perhaps something along the lines of “RPCs MAY be defined as _relating_ to the contents of a specific datastore….   Input data resolves to <operational>, as does output data, as do RPC side effects“.  Then below

“RPCs definitions that do not explicitly state an affected
datastore(s) _refer_to_  the general operational state of the server.”

One other comment, it would be good to also indicate that when an RPC leads to modification of data nodes, what the “origin” of those modifications is.

</ALEX>

On a related note, I also want to confirm that it is right that RPC input data is always checked against operational:

Is <operational> always the right datastore to evaluate RPC input/output data relative to?  For most RPCs this seems to be the right choice by default but it also seems plausible that someone may wish to define an RPC that wants to validate its input parameters against the contents of another datastore.

An example could be an "is-applied" RPC that takes a path to a subtree in <running> or <intended> and checks whether the configuration for that subtree is fully represented in <operational>.

Thanks,
Rob

Andy Bierman <[email-masked]><mailto:[email-masked]> wrote:

[email-masked]<mailto:[email-masked]>> wrote:

Hi -

Hi ,

   operations in the context of <operational>, unless the RPC is

explicitly

OK?

statements.

a specific datastore.

/martin

netmod mailing list

[email-masked]<mailto:[email-masked]>

.

---

From: Phil Shafer <[email-masked]>
Date: Wed, 1 Nov 2017 02:36:31 -0400

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

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.

Thanks,
 Phil