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

"Fengchong (frank)" <frank.fengchong@huawei.com> Mon, 09 September 2019 12:28 UTC

Return-Path: <frank.fengchong@huawei.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 3D37412008D for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 05:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.631
X-Spam-Level:
X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, 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 G-b5zGT4fL96 for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 05:28:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782A6120047 for <netmod@ietf.org>; Mon, 9 Sep 2019 05:28:44 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EEA648EFF129CC8B5057 for <netmod@ietf.org>; Mon, 9 Sep 2019 13:28:41 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 9 Sep 2019 13:28:41 +0100
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 9 Sep 2019 13:28:41 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 9 Sep 2019 13:28:41 +0100
Received: from DGGEMM513-MBX.china.huawei.com ([169.254.1.120]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0439.000; Mon, 9 Sep 2019 20:28:37 +0800
From: "Fengchong (frank)" <frank.fengchong@huawei.com>
To: netmod <netmod@ietf.org>
Thread-Topic: [netmod] Please clarify implementation about ‘when’
Thread-Index: AdVkgxkxStdW26xJTo+kz8dBb3TuVgChwG4M
Date: Mon, 09 Sep 2019 12:28:37 +0000
Message-ID: 8ED84560-C18B-42ED-9AD3-5D297C40819E
References: <5756FB984666AD4BB8E1D63E2E3AA3D001F20F2C@dggemm513-mbs.china.huawei.com>
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001F20F2C@dggemm513-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/mixed; boundary="_004_8ED84560C18B42ED9AD35D297C40819E_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cBa6mthOSo6c1yYEDML0KglqBBU>
Subject: [netmod] FW: 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 12:28:47 -0000




--------------------------------------------------
冯冲 Feng Chong
Mobile: +86-13776612983<tel:+86-13776612983>
Email: frank.fengchong@huawei.com<mailto:frank.fengchong@huawei.com>
发件人:Fengchong (frank) <frank.fengchong@huawei.com>
收件人:netmod <netmod@ietf.org>
抄 送:Yangang <yangang@huawei.com>
时 间:2019-09-06 15:19:28
主题[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?