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

Martin Bjorklund <mbj@tail-f.com> Thu, 26 September 2019 06:57 UTC

Return-Path: <mbj@tail-f.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 269951200F6 for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 23:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 rCcFXoPGqNHe for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 23:57:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D823120815 for <netmod@ietf.org>; Wed, 25 Sep 2019 23:57:11 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 24A731AE018A; Thu, 26 Sep 2019 08:57:09 +0200 (CEST)
Date: Thu, 26 Sep 2019 08:56:44 +0200 (CEST)
Message-Id: <20190926.085644.1268671875357328723.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, jason.sterne@nokia.com, netmod@ietf.org, yangang@huawei.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <87h84z4kmw.fsf@nic.cz>
References: <VI1PR07MB398192BDD1C0BD1212FA15A69B870@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQRReksw-TWqdVLPEpuB05Un4bHts7asHxQtb9YKcvMMg@mail.gmail.com> <87h84z4kmw.fsf@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4aQKnTxDssDm5DL0XEhI8v4xg20>
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGlt?= =?utf-8?b?cGxlbWVudGF0aW9uIGFib3V0IOKAmHdoZW7igJk=?=
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:57:15 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> 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.

It also says in 8.2:

   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.


/martin

> 
> 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>om>; 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>om>; 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>om>; 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>om>; 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
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod