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
