Re: [netmod] validating a YANG action

Andy Bierman <andy@yumaworks.com> Fri, 03 May 2019 16:43 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42571200F9 for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 09:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiPuLjmq_evE for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 09:43:57 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312581200D6 for <netmod@ietf.org>; Fri, 3 May 2019 09:43:57 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id e18so5780203lja.5 for <netmod@ietf.org>; Fri, 03 May 2019 09:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IP6CM2Rz9CGC/3LuDEFyscpacB9vCmJSW2gmH9mi8Cc=; b=KQ9uaXXpVG0Pk3bklIErcZnDmN3XRNSR7BVV6v1RW+O17t/UQCe6nDbYTqwEErMtoE dG2TgC/XxXyNRk1d4X72xXfPRwIQvb0IynuchXyGpJcNAZ0+JmwKYA6ApH/Y6uaGO+Cg Hf6Dbd4Q0yHl5uq/H4hqQMNq4wEk9BquElQc+kCK/EgQub6HcE8pxi6vL9UhjM5tpqRH Xg4TrXTPlO/TrAdU28BQnUk9gVgulqcwsbfzowS4a1qEMySYi7yvH2KdjM5mxJTC5YE3 xAX/I+9FfgQl4PFQPw2lXp51q96MpOaPcC5OItmAMCUOiFLC/zG5DTjmuEYjy8ZcxSP0 dHjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IP6CM2Rz9CGC/3LuDEFyscpacB9vCmJSW2gmH9mi8Cc=; b=k5MxtRmpLOUuZYS1qTMH4bPKw813OcSVqXi+Vj5UIcfFHVliba0QRAiN030PA9PSrM XV1EodP1XfXMmYF07c/DDZR84V0xovqeAzRn+YknbGLWKDAptaNKRMBYXHPqKXXx1DdR EUECsF5ytwnb3p5ZF72EVOzCLT9kpjYF0+CGUp5ywmJQ5FQiHNVNDh7Ca4ujgJXJzoO3 R/Ej/94QSxtNk2ROJtDqevhWFV9ejkrMolE2m7mGchK653yeJ9pZrECWdZwUXjZqTcBh 1r1v4QZ7Q3eBaFRSo18kUoWFjoe648k3/UFS0Awa0i8B7EA1KlEN7cz0X/wj3lsm9F9R nBVA==
X-Gm-Message-State: APjAAAVs0EES0yc2TqeaeX6kahYbAL5u4mKZ0usA24/ln6DYd52mqdBL Ih0XeABm9B0Vdder/pU9fNk5zFFZ5zbFHhvm21idwg==
X-Google-Smtp-Source: APXvYqyWX4XkJOrNJYOCwyu2SWGSHu7R8P+A/fKRWvKedjW8w8bNqRTn92zHhTg0cXaAMnUGgDfS0wljuct3/32NPaw=
X-Received: by 2002:a2e:9e4d:: with SMTP id g13mr5632889ljk.12.1556901835246; Fri, 03 May 2019 09:43:55 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHS-nwPfgF-NCNqp5tdS=G3Fz_9s7RkvGNvHbLVq=jYCsg@mail.gmail.com> <20190503055724.723voy7swdito3bv@anna.jacobs.jacobs-university.de> <CABCOCHThV5=re8-Mv8S0aLnFDrUoXvr_9nOgB2-zGoED+H2=oQ@mail.gmail.com> <20190503092012.gb2zzqggb2igzs37@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190503092012.gb2zzqggb2igzs37@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 03 May 2019 09:43:44 -0700
Message-ID: <CABCOCHQQDQMvphaxDmqjBvg3znhk-_7z2eGxU+qrfg8bL9eU1Q@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7238e0587fe749b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CVhTlz3HXFe-Mdpzda1ctk66pJY>
Subject: Re: [netmod] validating a YANG action
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2019 16:44:00 -0000

On Fri, May 3, 2019 at 2:20 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> 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 <
> > j.schoenwaelder@jacobs-university.de> 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.

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.

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.

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


/js
>
>
Andy


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