Re: [netmod] Please clarify implementation about ‘when’

Andy Bierman <andy@yumaworks.com> Mon, 09 September 2019 17:14 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 0EA8E1201EA for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 10:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SGn7Fi6f43_n for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 10:13:58 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 CEB40120018 for <netmod@ietf.org>; Mon, 9 Sep 2019 10:13:57 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id h2so7025409ljk.1 for <netmod@ietf.org>; Mon, 09 Sep 2019 10:13: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 :cc; bh=7gXhB01YFL6U8SumCzpIp4STBJey+HKiIpTKlyO7JBc=; b=Rs5CUEIoMTjRO3gyp7k8S20vgeEzPwf4OlTq2WCFtuchJIctSMMR4HC4rkmggmiB3p dU6W/78icgcJlrt0iDWRQbZfR65JZhEtZ0UXsf6LIazLunRvY9mv3Ede0YM2XVS0OHcn bYLwL818U5IEkbS1Vk0LtxXdHjq5Zrn+K6acnAl1QmWSj2tO9snO0Muaid0Xc+5pg2Np vaSGY4YNjCEQVSO5rH11NS4JaAX8C3Ysm1GgD50vxuZ7yOCWm5rHAEoKhR47RBdrnb7B PWRJpckQ1H6sLz0Bb+pY6hnOlaGag8Aa2HSP5Gzr8GAQkYy2z9C+qqKtINrH28UstT/y mJ6w==
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:cc; bh=7gXhB01YFL6U8SumCzpIp4STBJey+HKiIpTKlyO7JBc=; b=eYkpwntXlvHuJ9bviIdAwkMG9D8+X7BLvQsy4+S5sUtcKnDrlbyzUFPJUXdeFd1J3R 5/jq8Het1N7kCJ6ZwScxBrg+pCfXKKONvhBhu55kaNlD4G25YG/1e/5EMqM2Ogij7XS2 mx4M8aTdVt3GhFjV8upcmdcA+4R8+ISkyp9XRJRci9vjuMca/GNBlT9oEasLzyFFPf4O MPYaIjuW0jKqOZ2VZCABtQy30NgDkfEc5SzVsjyO321GwV8yrtFUv2gmpaUBbjR4386C fTGakYS63rMrw4zXRox4xVl+jslooCHj68cfFvU/dh0/52etjRhYDXCyRYBrpVECIdNw t43g==
X-Gm-Message-State: APjAAAXTPwfy2qaikJ1OGKHXIDl4CULfuwKqVjNVHx7zoRMf+g4aE2WG 0XtVFCWqUWCkxrzg6yNpgcNKp9NS6KGRxD96tLitCQ==
X-Google-Smtp-Source: APXvYqwNfkVza5S/v+Irx3Dq84ndUJbRKA48/g2bTFv3J4EsQAmVZWDIgDEFJInE7EANgROen8yoU8i7B39DjoiA7Ig=
X-Received: by 2002:a05:651c:282:: with SMTP id b2mr16200390ljo.50.1568049235801; Mon, 09 Sep 2019 10:13:55 -0700 (PDT)
MIME-Version: 1.0
References: <5756FB984666AD4BB8E1D63E2E3AA3D001F20F2C@dggemm513-mbs.china.huawei.com> <MN2PR11MB4366224F81AD9884FA130B37B5B70@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366224F81AD9884FA130B37B5B70@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 09 Sep 2019 10:13:44 -0700
Message-ID: <CABCOCHRc2R0ZBV25LRO6-FxV4GOf6HfN2NWzk9dEeNby3XVdUw@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: "Fengchong (frank)" <frank.fengchong@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000b0d266059221e9ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2g3cl5TIsGMVpnVU4Q1iAmdq68Y>
Subject: Re: [netmod] Please clarify implementation about ‘when’
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: Mon, 09 Sep 2019 17:14:01 -0000

Hi,

None of the operations that accept or return datastore contents expose the
datastore objects
in the RPC parameters.  They are always anyxml or anydata. This means that
there are no descendant data nodes defined at all according to the RPC
operation
and therefore the constraints on those nodes do not exist in the RPC
operation either.



On Mon, Sep 9, 2019 at 6:41 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

> Hi Frank,
>
>
>
> My interpretation of what the expected behaviour is as follows.
>
>
>
> For “scene 1”, the config change is accepted because the result of the
> config datastore after the edit-config has been applied is valid.
>
>
>
> For “scene 2”, the config change is rejected because the result of the
> config datastore after the edit-config has been applied is invalid.
>
>
>
> My interpretation is that the block of text in 8.3.1 payload parsing is
> primary intended to refer to RFC input.  E.g. if the RPC was defined
> something like below, then the ‘when’ rule in 8.3.1 would enforce that a
> zip-code can only be provided if the country is the USA.
>
>
>
>        rpc rock-the-house {
>
>          input {
>
>            leaf country {
>
>              type string;
>
>            }
>
>            leaf zip-code {
>
>              when “../country = ‘usa’”;
>
>              type string;
>
>            }
>
>          }
>
>        }
>
>
>
> Thanks,
>
> Rob
>
>
>
>
>
>
>
> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Fengchong (frank)
> *Sent:* 06 September 2019 08:19
> *To:* netmod@ietf.org
> *Cc:* Yangang <yangang@huawei.com>
> *Subject:* [netmod] Please clarify implementation about ‘when’
>
>
>
> Hi all,
>
>
>
> In RFC7950 secton 8, several description about when:
> In section 8.2 <https://tools.ietf.org/html/rfc7950#section-8.2>.
> Configuration Data Modifications
>
>    o  If a request modifies a configuration data node such that any
>
>       node's "when" expression becomes false, then the node in the data
>
>       tree with the "when" expression is deleted by the server.
> In 8.3.1 <https://tools.ietf.org/html/rfc7950#section-8.3.1>.  Payload
> Parsing
>
>    o  If data for a node tagged with "when" is present and the "when"
>
>       condition evaluates to "false", the server MUST reply with an
>
>       "unknown-element" <error-tag> in the <rpc-error>.
>
> In 8.3.2 <https://tools.ietf.org/html/rfc7950#section-8.3.2>.  NETCONF
> <edit-config> Processing
>
> Modification requests for nodes tagged with "when", and the "when"
>
>       condition evaluates to "false".  In this case, the server MUST
>
>       reply with an "unknown-element" <error-tag> in the <rpc-error>.
>
>
>
> YANG module:
>
> module foo {
>
>    namespace “http://foo.com”;
>
>    prefix “foo”;
>
> Leaf a {…}
>
> Leaf b {
>
>   When “a = 10”;
>
> }
>
> }
> Scene 1:
>
> The first edit-config request:
>
> <edit-config>
>
>    <target>
>
>       <candidate/>
>
>    </target>
>
>    <config>
>
>       <a xmlns= “http://foo.com”>3</a>
>
>    </config>
>
> </edit-config>
>
> This request will set a = 3.
>
>
>
> The second request:
>
> <edit-config>
>
>    <target>
>
>       <candidate/>
>
>    </target>
>
>    <config>
>
>       <a xmlns= “http://foo.com”>10</a>
>
>       <b xmlns= “http://foo.com”>5</b>
>
>    </config>
>
> </edit-config>
>
>
>
> According 8.3.1, in rpc payload parsing phase, the a’s value in candidate
> datastore is 3,so leaf b’s when condition is evaluated to false, server
> will report ‘unknown-element’ error.
>
> Is it expected by user?
> Scene 2:
>
> The first edit-config request:
>
> <edit-config>
>
>    <target>
>
>       <candidate/>
>
>    </target>
>
>    <config>
>
>       <a xmlns= “http://foo.com”>10</a>
>
>    </config>
>
> </edit-config>
>
> This request will set a = 10.
>
>
>
> The second request:
>
> <edit-config>
>
>    <target>
>
>       <candidate/>
>
>    </target>
>
>    <config>
>
>       <a xmlns= “http://foo.com”>3</a>
>
>       <b xmlns= “http://foo.com”>5</b>
>
>    </config>
>
> </edit-config>
>
> According 8.3.1, in rpc payload parsing phase, the a’s value in candidate
> datastore is 10, so leaf b’s when condition is evaluated to true, server
> will accept this request in payload parsing phase.
>
>
>
> In edit-config request processing phase, if leaf a’s modification is
> processed firstly, the a’s value will be changed to 3, so the b’s when
> condition will be false, when server process b’s modification, b will be
> treated as unknown-element, the edit-config request will fail.
>
> If leaf b’s modification is processed firstly, server will accept this
> modification ,because b’s when condition is true, and when server process
> a’s modification , this modification will be accepted, and b’s when
> condition will be evaluated to false, leaf b will be deleted automatically,
> the edit-config request will be OK.
>
>
>
> How server should process this situation?
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>