[netmod] 答复: Please clarify implementation about ‘when’

"Fengchong (frank)" <frank.fengchong@huawei.com> Tue, 10 September 2019 02:50 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 37A88120025 for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 19:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 P0OOpY8fn_gf for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 19:50:12 -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 9FC32120020 for <netmod@ietf.org>; Mon, 9 Sep 2019 19:50:11 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EF8B1F1C90D594FD0F08 for <netmod@ietf.org>; Tue, 10 Sep 2019 03:50:09 +0100 (IST)
Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 10 Sep 2019 03:50:09 +0100
Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 10 Sep 2019 03:50:09 +0100
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 10 Sep 2019 03:50:08 +0100
Received: from DGGEMM513-MBX.china.huawei.com ([169.254.1.120]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Tue, 10 Sep 2019 10:50:01 +0800
From: "Fengchong (frank)" <frank.fengchong@huawei.com>
To: Andy Bierman <andy@yumaworks.com>
CC: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Thread-Topic: =?utf-8?B?W25ldG1vZF0gUGxlYXNlIGNsYXJpZnkgaW1wbGVtZW50YXRpb24gYWJvdXQg?= =?utf-8?B?4oCYd2hlbuKAmQ==?=
Thread-Index: AQHVZxRY9YCq6AlKlkifU9HZTydEwqcjD5kAgAEZNBD//4T/gIAAhv8A
Date: Tue, 10 Sep 2019 02:50:00 +0000
Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBF8@dggemm513-mbx.china.huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D001F20F2C@dggemm513-mbs.china.huawei.com> <MN2PR11MB4366224F81AD9884FA130B37B5B70@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHRc2R0ZBV25LRO6-FxV4GOf6HfN2NWzk9dEeNby3XVdUw@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBA8@dggemm513-mbx.china.huawei.com> <CABCOCHQb8UubX=Evte0oCc6HE5wrToqqaCfh81mxfkGRhdEB4Q@mail.gmail.com>
In-Reply-To: <CABCOCHQb8UubX=Evte0oCc6HE5wrToqqaCfh81mxfkGRhdEB4Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.40.226]
Content-Type: multipart/related; boundary="_004_5756FB984666AD4BB8E1D63E2E3AA3D001F2CBF8dggemm513mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lhgu6TApLwTM6ivJVYoLbHwImAA>
Subject: [netmod] =?utf-8?b?562U5aSNOiAgUGxlYXNlIGNsYXJpZnkgaW1wbGVtZW50?= =?utf-8?b?YXRpb24gYWJvdXQg4oCYd2hlbuKAmQ==?=
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: Tue, 10 Sep 2019 02:50:15 -0000

Andy,

Do you think when conditions should be evaluated during validation phase, for example when user issues validate operation or edit-config operation with ‘test-then-set’ test-option?

________________________________
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名:冯冲
手  机:13776612983
电子邮件:frank.fengchong@huawei.com
公司网址:www.huawei.com
________________________________
 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

发件人: Andy Bierman [mailto:andy@yumaworks.com]
发送时间: 2019年9月10日 10:40
收件人: Fengchong (frank) <frank.fengchong@huawei.com>
抄送: Rob Wilton (rwilton) <rwilton@cisco.com>om>; netmod@ietf.org; Yangang <yangang@huawei.com>
主题: Re: [netmod] Please clarify implementation about ‘when’

Hi,

I see you are asking about when the server removes data nodes with false when-stmts.
Our server would accept scene 1 and reject scene 2.
The when-stmts are evaluated against the desired datastore (same as leafref validation)
after all the modifications are considered.

Andy


On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <frank.fengchong@huawei.com<mailto:frank.fengchong@huawei.com>> wrote:
Hi andy,

You only talk about the constraints on rpc operation’s parameter?

Do you have any opinion about my question?

________________________________
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名:冯冲
手  机:13776612983
电子邮件:frank.fengchong@huawei.com<mailto:frank.fengchong@huawei.com>
公司网址:www.huawei.com<http://www.huawei.com>
________________________________
 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

发件人: Andy Bierman [mailto:andy@yumaworks.com<mailto:andy@yumaworks.com>]
发送时间: 2019年9月10日 1:14
收件人: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
抄送: Fengchong (frank) <frank.fengchong@huawei.com<mailto:frank.fengchong@huawei.com>>; netmod@ietf.org<mailto:netmod@ietf.org>; Yangang <yangang@huawei.com<mailto:yangang@huawei.com>>
主题: Re: [netmod] Please clarify implementation about ‘when’

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<mailto: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<mailto:netmod-bounces@ietf.org>> On Behalf Of Fengchong (frank)
Sent: 06 September 2019 08:19
To: netmod@ietf.org<mailto:netmod@ietf.org>
Cc: Yangang <yangang@huawei.com<mailto: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>.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>.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>.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<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod