On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@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. > Jason > Andy > > > *From:* netmod <netmod-boun...@ietf.org> *On Behalf Of *Qin Wu > *Sent:* Tuesday, September 10, 2019 10:33 PM > *To:* Fengchong (frank) <frank.fengch...@huawei.com>; Andy Bierman < > a...@yumaworks.com> > *Cc:* netmod@ietf.org; Yangang <yang...@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-boun...@ietf.org <netmod-boun...@ietf.org>] > *代表 *Fengchong (frank) > *发送时间**:* 2019年9月11日 9:29 > *收件人**:* Andy Bierman <a...@yumaworks.com> > *抄送**:* netmod@ietf.org; Yangang <yang...@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.fengch...@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:a...@yumaworks.com <a...@yumaworks.com>] > *发送时间**:* 2019年9月10日 10:56 > *收件人**:* Fengchong (frank) <frank.fengch...@huawei.com> > *抄送**:* Rob Wilton (rwilton) <rwil...@cisco.com>; netmod@ietf.org; > Yangang <yang...@huawei.com> > *主题**:* Re: [netmod] Please clarify implementation about ‘when’ > > > > > > > > On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) < > frank.fengch...@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.fengch...@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:a...@yumaworks.com] > *发送时间**:* 2019年9月10日 10:19 > *收件人**:* Fengchong (frank) <frank.fengch...@huawei.com> > *抄送**:* Rob Wilton (rwilton) <rwil...@cisco.com>; netmod@ietf.org; > Yangang <yang...@huawei.com> > *主题**:* Re: [netmod] Please clarify implementation about ‘when’ > > > > > > > > On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) < > frank.fengch...@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.fengch...@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:a...@yumaworks.com] > *发送时间**:* 2019年9月10日 1:14 > *收件人**:* Rob Wilton (rwilton) <rwil...@cisco.com> > *抄送**:* Fengchong (frank) <frank.fengch...@huawei.com>; netmod@ietf.org; > Yangang <yang...@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) <rwil...@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-boun...@ietf.org> *On Behalf Of *Fengchong (frank) > *Sent:* 06 September 2019 08:19 > *To:* netmod@ietf.org > *Cc:* Yangang <yang...@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
