Re: [netmod] Please clarify implementation about ‘when’
Andy Bierman <andy@yumaworks.com> Tue, 10 September 2019 02:56 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 25E12120020 for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 19:56:47 -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 2zbZIVQJVKlw for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 19:56:43 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 929C2120048 for <netmod@ietf.org>; Mon, 9 Sep 2019 19:56:42 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id a22so14843465ljd.0 for <netmod@ietf.org>; Mon, 09 Sep 2019 19:56:42 -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=K97qk7MJnd+ttNabVqyzLGB5t8cQZ5jckH1PCKuU/3k=; b=t5e1vdjvJDjlRuTKFOReB9GurrkxQhjOXVzwrYIgtvkVYpL6sMTGBIEVrpgKhNT+6E KPO3UHIyqKc6zdW1kXQhFO1wL31SG+zhRQiiaDC2zIWuPhfoJkFxG4TQhoTAnsRwsw4U UVAm1soOjwind/+bEiE2QuXf23mCCGQ6F5VGt528EeKyzLZrlaF77VXI0fYDJVzf4Iqi 6S7rVMek0cEqPN7JK3aeSFgF101Yy1qKnTGwmKMGCol7n+4ofHJ0E5ANgp1tR3Dyyl+m myssFZQuRdhBkQVSX1Stl8NY6lwSIaAwfLuMgdHwEHkiWI9FcQD2EhmUtD5VF2W33afZ l0nA==
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=K97qk7MJnd+ttNabVqyzLGB5t8cQZ5jckH1PCKuU/3k=; b=DTw7/Z30nu7xMpkk0rDPTyV2HmEA96Xf4aN2DS8QybJYbtMkaKGMTuhlp0Qo9i2osW +qspNrDBkBdZCGgRnN2aLGSP+/Hsq3PgqkEGwjisRQriKCI43hwlFRJ4mysp0bxM4Uk+ NxWPwzG+FyGrnlrF3DyaVrFuM2LKeZCFHo7Tefz97QF7JGBMyvCcn2rdBTjFeTTvwRep oJykqUWyPQZZhYmJbUMNd0TeaIMyuHWMLgsnQlZJmj0YQbsSGr0p5v7Cu7y29RZb0uYG yMEEDMmX/6IfFqspIHMNLBi/3AE56e1fAa/+AWc9kAM65PKkcFBcd1cgjoJLD3bs2881 Z+zw==
X-Gm-Message-State: APjAAAXeUQKkI0mPREtLl7dCAo7yGM8qzcjgw5YLpFuBNiFp7Ql2oWRa WJNGJDo3t9uSkUYIk8fdxODro1LyH5dmbbNeYe0SEw==
X-Google-Smtp-Source: APXvYqxytJlSUatBnTRNSeAXkqTX66cyCdAlqXFMYyVDdsGqUJUK4btjbMcgJ84wGL3XYX/3yiLfmXF3zISLo/BUmAk=
X-Received: by 2002:a2e:990d:: with SMTP id v13mr11199297lji.146.1568084200668; Mon, 09 Sep 2019 19:56:40 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001F2CBE4@dggemm513-mbx.china.huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 09 Sep 2019 19:56:29 -0700
Message-ID: <CABCOCHRGzVpSOLue5bOx=5-ONWE=d1Hcn4RZ1=ZRAOx_sRqQLg@mail.gmail.com>
To: "Fengchong (frank)" <frank.fengchong@huawei.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Content-Type: multipart/related; boundary="000000000000c2672b05922a0d83"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YFzbmNhAiTf6TCqYnjRSHee7VVQ>
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: Tue, 10 Sep 2019 02:56:47 -0000
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] Please clarify implementation about ‘whe… Fengchong (frank)
- [netmod] FW: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Rob Wilton (rwilton)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- Re: [netmod] Please clarify implementation about … Andy Bierman
- [netmod] 答复: Please clarify implementation about … Fengchong (frank)
- [netmod] 答复: 答复: Please clarify implementation ab… Qin Wu
- Re: [netmod] 答复: 答复: Please clarify implementatio… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- [netmod] 答复: 答复: 答复: Please clarify implementatio… Qin Wu
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Schönwälder
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Rob Wilton (rwilton)
- Re: [netmod] 答复: 答复: Please clarify implementatio… Schönwälder
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Martin Bjorklund
- Re: [netmod] 答复: 答复: Please clarify implementatio… Ladislav Lhotka
- Re: [netmod] 答复: 答复: Please clarify implementatio… Andy Bierman
- [netmod] What's the problem with NMDA? was Re: 答复… tom petch
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman
- Re: [netmod] What's the problem with NMDA? was Re… Schönwälder
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman
- Re: [netmod] What's the problem with NMDA? was Re… tom petch
- Re: [netmod] What's the problem with NMDA? was Re… Rob Wilton (rwilton)
- Re: [netmod] What's the problem with NMDA? was Re… Andy Bierman