On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <[email protected]> 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 > 电子邮件：[email protected] > 公司网址：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:[email protected]] > *发送时间:* 2019年9月10日 1:14 > *收件人:* Rob Wilton (rwilton) <[email protected]> > *抄送:* Fengchong (frank) <[email protected]>; [email protected]; > Yangang <[email protected]> > *主题:* 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) <[email protected]> > 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 <[email protected]> *On Behalf Of *Fengchong (frank) > *Sent:* 06 September 2019 08:19 > *To:* [email protected] > *Cc:* Yangang <[email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
