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

[Ladislav Lhotka <[e-mail]>]

On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <[e-mail]> wrote:
> > Andy Bierman <[e-mail]> writes:
> 
> > 
> 
> > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> 
> > > [e-mail]> 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.

Right. But the request won't modify a configuration data node because it is
rejected. So the premise of the above implication doesn't hold, and the
conclusion doesn't apply.

Lada 

> 
> 
> /martin
> 
> > 
> 
> > This can also be prevented if the server rejects an edit operation
> 
> > that would create such a situation.
> 
> > 
> 
> > Lada
> 
> > 
> 
> > 
> 
> > >
> 
> > >
> 
> > >> Jason
> 
> > >>
> 
> > >
> 
> > > Andy
> 
> > >
> 
> > >
> 
> > >>
> 
> > >>
> 
> > >> *From:* netmod <[e-mail]> *On Behalf Of *Qin Wu
> 
> > >> *Sent:* Tuesday, September 10, 2019 10:33 PM
> 
> > >> *To:* Fengchong (frank) <[e-mail]>; Andy Bierman <
> 
> > >> [e-mail]>
> 
> > >> *Cc:* [e-mail]; Yangang <[e-mail]>
> 
> > >> *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:[e-mail] <[e-mail]>
> ]
> 
> > >> *代表 *Fengchong (frank)
> 
> > >> *发送时间**:* 2019年9月11日 9:29
> 
> > >> *收件人**:* Andy Bierman <[e-mail]>
> 
> > >> *抄送**:* [e-mail]; Yangang <[e-mail]>
> 
> > >> *主题**:* [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
> 
> > >> 电子邮件：[e-mail]
> 
> > >> 公司网址：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:[e-mail] <[e-mail]>]
> 
> > >> *发送时间**:* 2019年9月10日 10:56
> 
> > >> *收件人**:* Fengchong (frank) <[e-mail]>
> 
> > >> *抄送**:* Rob Wilton (rwilton) <[e-mail]>; [e-mail];
> 
> > >> Yangang <[e-mail]>
> 
> > >> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) <
> 
> > >> [e-mail]> 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
> 
> > >> 电子邮件：[e-mail]
> 
> > >> 公司网址：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:[e-mail]]
> 
> > >> *发送时间**:* 2019年9月10日 10:19
> 
> > >> *收件人**:* Fengchong (frank) <[e-mail]>
> 
> > >> *抄送**:* Rob Wilton (rwilton) <[e-mail]>; [e-mail];
> 
> > >> Yangang <[e-mail]>
> 
> > >> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <
> 
> > >> [e-mail]> 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
> 
> > >> 电子邮件：[e-mail]
> 
> > >> 公司网址：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:[e-mail]]
> 
> > >> *发送时间**:* 2019年9月10日 1:14
> 
> > >> *收件人**:* Rob Wilton (rwilton) <[e-mail]>
> 
> > >> *抄送**:* Fengchong (frank) <[e-mail]>; [e-mail];
> 
> > >> Yangang <[e-mail]>
> 
> > >> *主题**:* 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) <[e-mail]>
> 
> > >> 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 <[e-mail]> *On Behalf Of *Fengchong (frank)
> 
> > >> *Sent:* 06 September 2019 08:19
> 
> > >> *To:* [e-mail]
> 
> > >> *Cc:* Yangang <[e-mail]>
> 
> > >> *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
> 
> > >> [e-mail]
> 
> > >> https://www.ietf.org/mailman/listinfo/netmod
> 
> > >>
> 
> > >>
> 
> > > _______________________________________________
> 
> > > netmod mailing list
> 
> > > [e-mail]
> 
> > > https://www.ietf.org/mailman/listinfo/netmod
> 
> > 
> 
> > -- 
> 
> > Ladislav Lhotka 
> 
> > Head, CZ.NIC Labs
> 
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> > 
> 
> > _______________________________________________
> 
> > netmod mailing list
> 
> > [e-mail]
> 
> > https://www.ietf.org/mailman/listinfo/netmod
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67