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

Ladislav Lhotka <lhotka@nic.cz> Thu, 26 September 2019 06:50 UTC

Return-Path: <lhotka@nic.cz>
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 2BD8712004C for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 23:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 sYYsNMFRDCGD for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 23:50:06 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 77F16120045 for <netmod@ietf.org>; Wed, 25 Sep 2019 23:50:05 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id D1D191821292; Thu, 26 Sep 2019 08:51:37 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id EE2FE1821290; Thu, 26 Sep 2019 08:51:17 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
In-Reply-To: <CABCOCHQRReksw-TWqdVLPEpuB05Un4bHts7asHxQtb9YKcvMMg@mail.gmail.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> <CABCOCHQCs093B0j6XpGvNH+idrs+PZHAcOhe=KYDN3RpccqgZw@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBE4@dggemm513-mbx.china.huawei.com> <CABCOCHRGzVpSOLue5bOx=5-ONWE=d1Hcn4RZ1=ZRAOx_sRqQLg@mail.gmail.com> <5756FB984666AD4BB8E1D63E2E3AA3D001F2D325@dggemm513-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABAA92F70D5@dggeml511-mbx.china.huawei.com> <VI1PR07MB398192BDD1C0BD1212FA15A69B870@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQRReksw-TWqdVLPEpuB05Un4bHts7asHxQtb9YKcvMMg@mail.gmail.com>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Sterne\, Jason \(Nokia - CA\/Ottawa\)" <jason.sterne@nokia.com>, "netmod\@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Date: Thu, 26 Sep 2019 08:49:43 +0200
Message-ID: <87h84z4kmw.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/UcC9cu_kecQW8MUmuknleCRNAF8>
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: Thu, 26 Sep 2019 06:50:11 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> jason.sterne@nokia.com> wrote:
>
>> Processing order should not matter. The evaluation of the 'when' statement
>> should be done assuming an atomic application of the edit-config.
>>
>>
>>
>> I agree that a standards compliant server should do as Rob said:
>>
>>
>>
>> - 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.
>>
>>
>>
>> From an implementation that may indeed mean processing the 'when' after a
>> first pass that sets the various leafs to tentative values. But that's
>> implementation detail.
>>
>>
>>
>> IMO the auto-clearing behavior of 'when' may be complicated but that is
>> how it is defined (same with 'choice'). Clients can and should depend on
>> things being automatically deleted. If you want validation errors (i.e.
>> force the client to clear all the dependant leafs instead of auto-clearing)
>> then use a 'must' statement.
>>
>>
>>
>
> +1
>
> YANG clearly defines "must" and "when" with different behavior.
> A server that does not implement the auto-delete aspects of when-stmt is
> not compliant to the RFC.

I don't agree with this. RFC 7950 says in sec. 8.1:

   The following properties are true in all data trees:

   ...

   o  There MUST be no nodes tagged with "when" present if the "when"
      condition evaluates to "false" in the data tree.

This can also be prevented if the server rejects an edit operation that would create such a situation.

Lada


>
>
>> Jason
>>
>
> Andy
>
>
>>
>>
>> *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Qin Wu
>> *Sent:* Tuesday, September 10, 2019 10:33 PM
>> *To:* Fengchong (frank) <frank.fengchong@huawei.com>; Andy Bierman <
>> andy@yumaworks.com>
>> *Cc:* netmod@ietf.org; Yangang <yangang@huawei.com>
>> *Subject:* [netmod] 答复: 答复: Please clarify implementation about ‘when’
>>
>>
>>
>> Why processing order matter? My interpretation is both leaf node values
>> (i.e.,leaf a, leaf b) should be validated together and commit as a whole,
>>
>> RFC6241 said:
>>
>> “
>>
>> If the device is unable to commit all of the changes in the
>>
>>          candidate configuration datastore, then the running
>>
>>          configuration MUST remain unchanged.
>>
>> ”
>>
>> So validate the leaf node value in the edit-config request (message
>> content validation) is not important, validate the leaf node value that is
>> applied to <running> (datastore validation) is the key.
>>
>>
>>
>> I think what you want to raise is the server should hold on to send reply with an "unknown-element" <error-tag> in the <rpc-error> during payload parsing phase and NETCONF <edit-config>
>>
>> Processing until all validation complete, otherwise it seems server will
>>
>> Send multiple rply with "unknown-element" <error-tag> in the <rpc-error> which seems not reasonable.
>>
>>
>>
>> -Qin
>>
>> *发件人**:* netmod [mailto:netmod-bounces@ietf.org <netmod-bounces@ietf.org>]
>> *代表 *Fengchong (frank)
>> *发送时间**:* 2019年9月11日 9:29
>> *收件人**:* Andy Bierman <andy@yumaworks.com>
>> *抄送**:* netmod@ietf.org; Yangang <yangang@huawei.com>
>> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
>>
>>
>>
>> Andy,
>>
>>
>>
>> Whether different result would occur according different process order?
>>
>> According 8.3.2
>>
>> if server process ‘a= 3’ firstly, b will be deleted by system and becomes
>> a non-exist schema node, and then  when ‘b=5’ is processed , server will
>> report a ‘unknown-element’ error.
>>
>> But if server process ‘b=5’ firstly, it will be accepted by server, and
>> then when ‘a=3’ is processed, b will be deleted by system, but report OK.
>>
>>
>>
>> If sec 8.3.2 is not right. What is the right?
>>
>> When node a and node b in the same request, and b tagged when condition,
>> a’s value will cause b’s condition is evaluated to false, which is more
>> prior?
>>
>> According you and Rob’s interpretation , maybe node ’a’ is more prior? If
>> yes, why node ‘b’ should be processed later?
>>
>>
>>
>> I think whether in edit-config processing phase the configuration tagged
>> when should not be evaluated and be delayed to commit or validate?
>>
>> When commit or validate operation is issued,  the data node tagged when
>> will be evaluated, and if it’s evaluated to false, this data will be
>> deleted by system immediately, server should not report any error.
>>
>>
>>
>>
>> ------------------------------
>>
>> 华为技术有限公司 Huawei Technologies Co., Ltd.
>>
>> [image: 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 <andy@yumaworks.com>]
>> *发送时间**:* 2019年9月10日 10:56
>> *收件人**:* Fengchong (frank) <frank.fengchong@huawei.com>
>> *抄送**:* Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org;
>> Yangang <yangang@huawei.com>
>> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) <
>> frank.fengchong@huawei.com> wrote:
>>
>> Andy,
>>
>> Whether all constraints on content in <config> parameter will not be
>> evaluated in payload parsing phase, for example, a leaf’s value exceed
>> range?
>>
>> Netconf server should treat it as a block data?
>>
>>
>>
>>
>>
>> Field validation and datastore validation are 2 different things.
>>
>> when-stmt processing is neither. It is by far the hardest part of an
>> automated server to get right.
>>
>>
>>
>> Another question:
>>
>>
>>
>> In edit-config processing phase, whether constraints on content in
>> <config> parameter needs be evaluated?
>>
>> If yes, when  configuration modification cause when condition is evaluated
>> to false, the node tagged when will be automatically deleted by system.
>>
>> Then, in scene 2, whether different result would occur according different
>> process order?
>>
>>
>>
>>
>>
>> Since the <config> parameter is anyxml, the YANG constraints defined on
>> datastore contents
>>
>> are not enforced as part of RPC input validation.
>>
>>
>>
>> It would be nice if NETCONF defined behavior for providing <config> data
>> that will get deleted
>>
>> immediately by the server.  We have a CLI parameter for this since some
>> vendors want to
>>
>> treat this as an error and other just silently delete nodes.  Note that
>> when-stmt can silently
>>
>> delete existing nodes not included in the edit. (Lada does not agree this
>> is how it should work,
>>
>> so we need yang-next to decide. Maybe NETCONF needs a --force parameter
>> for this purpose.)
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> 华为技术有限公司 Huawei Technologies Co., Ltd.
>>
>> [image: 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:19
>> *收件人**:* Fengchong (frank) <frank.fengchong@huawei.com>
>> *抄送**:* Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org;
>> Yangang <yangang@huawei.com>
>> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <
>> 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?
>>
>>
>>
>> 8.3.1 does not apply to leaf 'b'.
>>
>> The RPC parameter is called 'config'.
>>
>> It has no when-stmts to evaluate.
>>
>> Rob is correct.
>>
>> His example shows what 8.3.1 would cover.
>>
>>
>>
>> Andy
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> 华为技术有限公司 Huawei Technologies Co., Ltd.
>>
>> [image: 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日 1:14
>> *收件人**:* Rob Wilton (rwilton) <rwilton@cisco.com>
>> *抄送**:* Fengchong (frank) <frank.fengchong@huawei.com>; netmod@ietf.org;
>> Yangang <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>
>> 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
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67