Re: [netmod] validating a YANG action

Andy Bierman <andy@yumaworks.com> Fri, 03 May 2019 17:17 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 85C231202DC for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 10:17:36 -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 Zb7CQrWV_FWK for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 10:17:34 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 7223D1202CD for <netmod@ietf.org>; Fri, 3 May 2019 10:17:33 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id s7so436231ljh.1 for <netmod@ietf.org>; Fri, 03 May 2019 10:17:33 -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=9yOU/slM8/lx9nstbfno0aCvlD/9MvHBT5TXitmhfqM=; b=wuiwRj+waU6yvvKG/X9XOEJIcZESY/Fjh6auKW9LA3PxePeO4c8zelJ/GZhrlJ8Rop mD/qgJV+5JNGK36fBNF81Jid+QUb9BpOAvRHaEcQyMii2Ga9tQGuBT4n2b8d/1K59iqG VuLsVokLFMiONrlCOAkgkAgB1sCfGwz6E/pZ90tIWv4+U9qjF/+/l4QoIad/2lZxK2cu eRjBAp6DxK0Ve0HlqSb5FsF1uXtLP4GB6jFXv0DeNa+p13994YgBideid44envLXGuOb VeR7RzK0lO5SjWmOfpnavx+vJq2aqR4L1+5cWoGwEusd1ewVT5EoKYPs5k1p9rukpTRu xNDw==
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=9yOU/slM8/lx9nstbfno0aCvlD/9MvHBT5TXitmhfqM=; b=rVyufxrfG6YUp7yr7BMmfoy44StP8JQ6Qh5scRy2bktrAsI4b2OwYiNi86pEFzjlhi OQMwLpVOatB13AmrjD+V+9fBfUPpljX3kTs1btaBuFmHOsG13Fr7uGTyPNyguNUFXVir ni1vIOMIWDbcM63BZPY78sQ1ZrQp09KHO8P/QkfNeWLk1yRBGOYxOUwarbf11QyLRd9Y JRlWI/i1YbmTjykAdnFxZUbTInJg5/htPl+or/SpEB7UY323H9nwhFLYQ4vQH7jGAQEb 0F48q+ZlQvMSi9NwyNZPygEzH5/YS1KXmnhFq9YpabSW7WaNUF2CaOVdoUiJwZXTzWFR 1jUQ==
X-Gm-Message-State: APjAAAXnOf6UNWFYW1l7hwyOoRyHaGHG7UWlso7hquNeTCYpBLoR7yh8 ZK6HHbDAUS8NKMq3sI5+JwPJd4ak/oYLoL75kCccAw==
X-Google-Smtp-Source: APXvYqwzdzlRd4vd/6RT2nD0TsY8k7PkBrV8Or4R1xzmeannXZzHwzTnSs2D1b8J/7zlz74shQx/9EiZ2GraTNS27vA=
X-Received: by 2002:a2e:9855:: with SMTP id e21mr983768ljj.180.1556903851514; Fri, 03 May 2019 10:17:31 -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> <CABCOCHQQDQMvphaxDmqjBvg3znhk-_7z2eGxU+qrfg8bL9eU1Q@mail.gmail.com> <20190503165345.spvrfu4zkin7er4y@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190503165345.spvrfu4zkin7er4y@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 03 May 2019 10:17:20 -0700
Message-ID: <CABCOCHQtymQN_ZoQFC19U2S=5BX_1WrPXRrNni7nv+owAVxw_A@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="00000000000004f5b50587feedf3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/q_bNvZ_apzYSLTHAOsuuZGc_Tks>
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 17:17:36 -0000

On Fri, May 3, 2019 at 9:53 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 03, 2019 at 09:43:44AM -0700, Andy Bierman wrote:
> > 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.
>
> 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.
>
>
The "mess" is that NMDA declared an action is always invoked in
<operational>
and this creates extra implementation burdens and complexity for clients
and servers.


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