Re: [netmod] validating a YANG action

[Juergen Schoenwaelder <[e-mail]>]

On Fri, May 03, 2019 at 09:43:44AM -0700, Andy Bierman wrote:
> On Fri, May 3, 2019 at 2:20 AM Juergen Schoenwaelder <
> [e-mail]> wrote:
> 
> > On Fri, May 03, 2019 at 01:10:58AM -0700, Andy Bierman wrote:
> > > On Thu, May 2, 2019 at 10:57 PM Juergen Schoenwaelder <
> > > [e-mail]> wrote:
> > >
> > > > On Thu, May 02, 2019 at 04:15:28PM -0700, Andy Bierman wrote:
> > > > > Hi,
> > > > >
> > > > > The text about invoking actions in RFC 7950, sec. 7.15 is not clear
> > > > > about whether the ancestor data nodes have to exist.
> > > > >
> > > > > sec 7.15.2, para 2:
> > > > >
> > > > >    The <action> element contains a hierarchy of nodes that identifies
> > > > > the node in the datastore.
> > > > >
> > > > >
> > > > > The RFC does not say anything about if the data node is required to
> > > > > exist or not.  There is no distinction between NP-container,
> > P-container,
> > > > > or list which are ancestors of the action node. It does not specify
> > > > > which datastore, and that is not supplied in the <action> RPC.
> > > > > The text specifies what must be in the <rpc> request, not in any
> > > > datastore
> > > > > or state data.
> > > > >
> > > > > It seems like the intent is that no instance test is specified at
> > all and
> > > > > the corresponding ancestor nodes to the action node do not have to
> > > > > exist for the action to be invoked. (The action may succeed or fail).
> > > > > The issue is whether there is an existence-test before invoking the
> > > > action.
> > > >
> > > > We discussed actions during the work on NMDA. RFC 8342 has this text
> > > > in section 6, in particular 6.1 says:
> > > >
> > > >    Actions are always invoked in the context of the operational state
> > > >    datastore.  The node for which the action is invoked MUST exist in
> > > >    the operational state datastore.
> > > >
> > > >
> > > This only applies to a server implementing NMDA.
> > > There is no requirement for a server implementing RFC 7950 to make this
> > > test.
> > >
> >
> > Yes, the behavior is unspecified in RFC 7950. However, note that RFC
> > 8342 formally updates RFC 7950 and the Introduction section says:
> >
> >    This document updates RFC 7950 by refining the definition of the
> >    accessible tree for some XML Path Language (XPath) context (see
> >    Section 6.1) and the invocation context of operations (see
> >    Section 6.2).
> >
> > This update may not affect your implementation but since you asked
> > whether there is an existence-test before invoking the action, I
> > thought a pointer to RFC 8342 is perhaps relevant.
> >
> >
> OK, but the update wrt/ action invocation is irrelevant unless the server
> implements the <operational> datastore.
> 
> This NMDA requirement means that a server MUST implement the
> operational values of config=true ancestor data nodes in order to
> implement an action nested within configuration.
> 
> If the server does not implement these operational values,
> and follows YANG library guidelines by omitting
> these ancestor schema nodes from the schema for <operational>,
> then the YANG action is not accessible on the server.
> 
> I don't think the YANG Library RFC makes it clear that an action must exist
> in the schema for <operational> in order for it to be accessible. This
> should be confirmed and an errata posted if needed.

I am not sure which text you propose or why YANG Library should say
something specific.

> This also means that any mechanism which disables configuration and
> therefore removes the corresponding data nodes from <operational>,
> also disables any actions within that configuration.

I think the model is that you invoke an action on an existing
resource.

> The keystore thread has already discussed the rather awkward procedures
> for waiting and confirming that <operational> has synched with <running>
> before being able to invoke an action.

Lets see what comes out of the discussion.

> Maybe YANG 1.2 can fix this mess, or maybe new protocol operations are
> needed.

It is not clear yet to me what 'this mess' is and hence what needs fixing.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>