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

Andy Bierman <andy@yumaworks.com> Thu, 26 September 2019 03:57 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 034A9120170 for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 20:57:42 -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 qJczKq21uAdv for <netmod@ietfa.amsl.com>; Wed, 25 Sep 2019 20:57:38 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 2421C1200DF for <netmod@ietf.org>; Wed, 25 Sep 2019 20:57:37 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id l21so609583lje.4 for <netmod@ietf.org>; Wed, 25 Sep 2019 20:57:37 -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=RZ93amr+3qBn/UyWldbkFPQ6hr6QSzAMoAqKcxqCyxo=; b=Z6URi5M3vWv1iUYSY0iZnb7EcWQTR4vHq4KgLCtZzM+SqcejPHsecoDRKaXwyYcwc+ H4xDYMNuPFQwjjt36qsljYocM1Z2Zi47QbrBxzggRrcfFCzz3p6jNukkHMNjpRvJ49/g 8HTFMo42s5WofyhE4ZZRRkWpk6yguZ5k5j8vVcwNClnjM+RWHHY6uOLk8/6uPsHy9Dvo xJT7O1hF0bIQMrvWa8MRQA382ox1FyhoeKnAicPjHhIVnSHE5OMdEjHSDP8ONoh40cNj LQhHTLaWm2UzjIBZXEXg59IBLusksq4YxdpHshpXi+CEP4xIbCGjfQyqSa+0vxDuzdAF 7eWw==
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=RZ93amr+3qBn/UyWldbkFPQ6hr6QSzAMoAqKcxqCyxo=; b=JcIrRd6bEW58wfOwzaX2NBznkbfAYcJvgjiPSzY2736J+1a2EUE3RQZa/thbX9ycOm hgu9h1RkW8hrmvxsLTJFUFGrLxn1yjOrRyZPjCSu/u0Xt+qMSEq0OG8RW1eW8QBhcwHP ERCICuX07V2/rjuX45qr49bDmND4AHXo6N6Jx5Lr77GhhJTIKB7SqKoTOfXEXDtokM0o rvFhfGEgaMQnJbP8FFSXbi96V98Qvb8YFGklRlhdpp3wamCpTmuDP+2sDa8cJK7khGvC iV7Nu+hBqMSjiRvHcKfAcotQ1iR7ADnOfEivS8bQHv8G8DJo0UnNxeov3WsZJHAKyPcj 1c2A==
X-Gm-Message-State: APjAAAVSdSiOMJC7N+5M1pYgt8likm7B39q80vDzqJ07v2x2c79cbvk3 Riby6s4RjF+SOroixfKrMklYMPRcsnG9qy9rUY+ygA==
X-Google-Smtp-Source: APXvYqyYNof1DOQgdwAxFAa29RG5/3UwsaY4D/IuDB1UHlX4kP5+rm3uvB9GQYiWMWV6acACnRQa0/0bfq04axM1bco=
X-Received: by 2002:a2e:b00b:: with SMTP id y11mr979203ljk.50.1569470255009; Wed, 25 Sep 2019 20:57:35 -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> <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> <CABCOCHQcdz-5eNm+WZyFw7++XBtgk1xomuxKindsLavrpy3fGQ@mail.gmail.com> <B8F9A780D330094D99AF023C5877DABAA932351C@dggeml511-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA932351C@dggeml511-mbs.china.huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Sep 2019 20:57:23 -0700
Message-ID: <CABCOCHSNY12_esOW-Oh4YW8oLtf=6QMGm6MkRuf9CW9P-WAoaQ@mail.gmail.com>
To: Qin Wu <bill.wu@huawei.com>
Cc: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "Fengchong (frank)" <frank.fengchong@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, Yangang <yangang@huawei.com>
Content-Type: multipart/related; boundary="000000000000099a0a05936cc565"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/n6dy8jSo6aoziPtI6uZFNdtvh34>
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 03:57:42 -0000

On Wed, Sep 25, 2019 at 7:54 PM Qin Wu <bill.wu@huawei.com> wrote:

> *发件人:* Andy Bierman [mailto:andy@yumaworks.com]
> *发送时间:* 2019年9月26日 0:00
> *收件人:* Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> *抄送:* Qin Wu <bill.wu@huawei.com>; Fengchong (frank) <
> frank.fengchong@huawei.com>; netmod@ietf.org; Yangang <yangang@huawei.com>
> *主题:* Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’
>
>
>
>
>
>
>
> On Wed, Sep 25, 2019 at 8:59 AM Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
>
>
> 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.
>
>
>
> [Qin]: Good clarification.
>
>
>
> +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.
>
>
>
>
>
>
>
> oops -- s/must-stmt/when-stmt/
>
>
>
> [Qin]: implement the auto-delete aspects of must-stmt is a must for server
> or implement client force delete aspects of must stmt is a must for a
> server?
>
> So for both  “scene 1” and “scene 2”, the client will not receive
> validation error unless when statement is replaced with must statement in
> the below example model?
>
> I thought validation error will still be received when the config change
> is reject in “scene 2”.
>


sorry for the confusion. it was right the first time.
when-stmt has auto-delete.
must-stmt has error instead of auto-delete.

 Andy

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
>
>