Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Thu, 26 October 2017 20:42 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
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 102C8139567 for <netmod@ietfa.amsl.com>; Thu, 26 Oct 2017 13:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 p173XgIGxV21 for <netmod@ietfa.amsl.com>; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) (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 D101313899A for <netmod@ietf.org>; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
Received: by mail-pg0-f51.google.com with SMTP id m18so3589912pgd.13 for <netmod@ietf.org>; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M05odCVu1Hti1tjgLIC2TSBsvR4VNQk7KiWSwyoMsAg=; b=bn6ebwSLC0CZwcI5jJ8K5heL7mP+sGKWa7EjX4pKO18d2UyZGDdlAeCWJZ7EIHVnV5 kQEZmLWhVrqhXwr2IVn3BDpKOv3R+bOCXAkEhnQ1SZvcRoR6kNsSMy7f2/aVOn8edJfs VKgzgsYBF2ygdeMgYYuf5dVMirfNYiy7kAJXP65PTpy0EMGMZBiFb/b4fAPAVP+Gcz1E aRoHbIB4LLdyphtkH9UbgxIkv8LD8kHpdJM1wxwBYUNrKrmEVfUMzgyhn//1BR2ZCJl3 0vkSfqJhBhRN3uxymILTR+0nPFuyiMoF8L7u9rv43FxgkiZ3YhNWCucdQ5YcxAxKyHPR Ye0g==
X-Gm-Message-State: AMCzsaWwnspgPFXnSpqX/8wEN9l0/9o/jWyNgSK4QFMNLjnnW/d8dyRu Ga3JPfBvGupiDPFNGPspeVBfCX+9I9U=
X-Google-Smtp-Source: ABhQp+S4LhNBXK5u9pSQZlKCWuKiLYbEDA9xhVijOak3iFxvzBb/U3G0YlnpySfW/tC/VGHh1xJL0A==
X-Received: by 10.98.65.11 with SMTP id o11mr6706846pfa.86.1509050537753; Thu, 26 Oct 2017 13:42:17 -0700 (PDT)
Received: from [192.168.1.102] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id f7sm9013247pgq.5.2017.10.26.13.42.16 for <netmod@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 13:42:17 -0700 (PDT)
To: "netmod@ietf.org" <netmod@ietf.org>
References: <20171015.095206.5556973134711466.mbj@tail-f.com> <CABCOCHR_q8DTF2agDi_VH9pSL8DWV1ttuX=ZZDO9OmNXhAeEsg@mail.gmail.com> <20171018143651.kdsf77r65ptlu4mq@elstar.local> <CABCOCHRVdkjV5PgQ+UtwJMKPLeFRKs_=ogAfTaCGZsWEdgP5uw@mail.gmail.com> <20171018213601.hdkt2qtqsno6vr4u@elstar.local> <CABCOCHS72TVrurJ1mTRi4eGQR3=G1=bx3wk_NK07NOB8OaZfKg@mail.gmail.com> <bacb34ef-d3d9-babd-467e-188146c1084d@cisco.com> <CABCOCHR6tSg9RRW7gZ50qp6F5frWGm-P1qK_0xEEQdiNursB7A@mail.gmail.com> <20171024172125.l6l3yhocakfkcoh2@elstar.local> <CABCOCHQ8nbf_H6eJxGFqwr=LHrdxyFWc3a4FfhLwR45bs-J19Q@mail.gmail.com> <20171025110851.wdoj2dbrqmxz5shd@elstar.local> <CABCOCHR22Ehryxu374a_-F6PFYayTgizReHuC0EaY4uBC7+vyg@mail.gmail.com> <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> <c544a19e-2534-9355-002e-18affd12ea5a@alumni.stanford.edu> <CABCOCHQdmMYObMBCxP=qWuH3RdCRi9q7Y6G0VsSnDeyg2qLc4w@mail.gmail.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <e71b3040-cb40-7be9-3913-5333f951db30@alumni.stanford.edu>
Date: Thu, 26 Oct 2017 13:42:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHQdmMYObMBCxP=qWuH3RdCRi9q7Y6G0VsSnDeyg2qLc4w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tnLpegMCH4_ajf3OaZEnnOW3i2A>
Subject: Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 26 Oct 2017 20:42:20 -0000

Hi -

On 10/26/2017 11:42 AM, Andy Bierman wrote:
> 
> 
> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn 
> <randy_presuhn@alumni.stanford.edu 
> <mailto:randy_presuhn@alumni.stanford.edu>> wrote:
> 
>     Hi -
> 
>     On 10/26/2017 10:44 AM, Robert Wilton wrote:
> 
>         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?
> 
> 
>     A question - I understand the motivation for the "unless" for RPC
>     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.

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