On Wed, Sep 14, 2016 at 10:08 AM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev < > [email protected] > > > wrote: > > > > > On 09/13/2016 06:48 PM, Andy Bierman wrote: > > > > > > Hi, > > > > > > I am not in favor of changing when-stmt so it works like must-stmt. > > > I prefer it work as designed. It is like choice-stmt, where a new case > > > will cause objects from the previously selected case to be > automatically > > > deleted. > > > > > > There is no text in RFC 7950 that actually says an error is returned > > > if a when-stmt is false because an anyxml or anydata input parameter > > > was converted to top-level YANG nodes and reprocessed. > > Hmm, I agree that the text could be more precise. But note that > section 8.3 says: > > For configuration data, there are three windows when constraints MUST > be enforced: > > So the entire section 8.3 is all about configuration data, which is > manipulated by various RPCs. > > Section 8.3.2 specifically talks about "applying the data to the > configuration > datastore", and that "unknown-element" is returned for a request that > modifies a node tagged with "when". > > You mean this sentence: o 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>. Consider this example: leaf foo { type int32; when "../bar=20"; } So the text only applies to modifications to the /foo leaf, right? Create and delete operations do not cause an error. Edits to other nodes (e.g., /bar) do not cause an error. This does not seem to do anything because the objects specified in the when-stmt are not allowed to be part of the object affected by the when-stmt. o If the "when" statement is a child of any other data definition statement, the accessible tree is tentatively altered during the processing of the XPath expression by replacing all instances of the data node for which the "when" statement is defined with a single dummy node with the same name, but with no value and no children. If no such instance exists, the dummy node is tentatively created. The context node is this dummy node. So I do not see how I can edit /foo and cause /foo to be deleted. According to the text, if I alter /bar (not /foo) then /foo can be silently deleted and this is not an error. > /martin > > > Andy > > > > > > > > > The text only covers direct when-stmts like below: > > > > > > rpc plot-point { > > > input { > > > leaf point-type { > > > type enumeration { > > > enum 2d; > > > enum 3d; > > > } > > > mandatory true; > > > } > > > leaf X { type int32; mandatory true; } > > > leaf Y { type int32; mandatory true; } > > > leaf Z { > > > when "../point-type = '3d'; > > > mandatory true; > > > type int32; > > > } > > > } > > > } > > > > > > > > > If the client sets point-type to '2d' and provides a Z leaf, then an > error > > > is returned. > > > This is the only type of usage the text in question actually covers. > > > > > > It is <edit-config> RPC that has started the thread (the 'when' > validation > > > in <plot-point> is much clearer and I agree with all you say above). > There > > > was the original example by Yves (changed when "A" to when "../A"): > > > > > > container root { > > > leaf A { > > > type empty: > > > } > > > leaf B { > > > when "../A"; > > > type uint32; > > > } > > > } > > > ... and the netconf <edit-config>: > > > > > > <rpc message-id="101" > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > <edit-config> > > > <target> > > > <running/> > > > </target> > > > <config> > > > <root xmlns="http://dummy.com"; <http://dummy.com>> > > > <A/> > > > <B> > > > 3 > > > </B> > > > </dummy> > > > </config> > > > </edit-config> > > > </rpc> > > > > > > There is consensus the 'when' statement is satisfied in this case which > > > answers his original question. > > > > > > However if we make change to the original example by assuming the > target > > > is not 'running' but 'candidate' and /root/A is already present before > the > > > following <edit-config> is processed: > > > > > > <rpc message-id="101" > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > <edit-config> > > > <target> > > > <candidate/> > > > </target> > > > <config> > > > <root xmlns="http://dummy.com"; <http://dummy.com>> > > > <B> > > > 3 > > > </B> > > > </dummy> > > > </config> > > > </edit-config> > > > </rpc> > > > > > > My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the > > > 'when' statement is satisfied since when the <edit-config> is applied > to > > > the 'candidate' configuration the result will be valid 'candidate' > > > configuration state and this is what matters. If there is consensus on > that > > > I have nothing to add. > > > > > > > > > > > > > > Here is the YANG for <edit-config>. > > Note that there is no when-stmt at all in the entire definition. > > The claims that RFC 7950 actually says enforce the when-stmts that > > are implied by the objects represented in the <config> anyxml subtree > > are just not careful readers. > > > > > > > > > > > > rpc edit-config { > > description > > > > > > "The <edit-config> operation loads all or part of a specified > > configuration to the specified target configuration."; > > > > reference "RFC 6241, Section 7.2 > > <https://tools.ietf.org/html/rfc6241#section-7.2>"; > > > > input { > > container target { > > description > > "Particular configuration to edit."; > > > > choice config-target { > > mandatory true; > > description > > "The configuration target."; > > > > leaf candidate { > > if-feature candidate; > > type empty; > > description > > "The candidate configuration is the config target."; > > } > > leaf running { > > if-feature writable-running; > > type empty; > > description > > "The running configuration is the config source."; > > } > > } > > } > > > > leaf default-operation { > > type enumeration { > > enum merge { > > description > > "The default operation is merge."; > > } > > enum replace { > > description > > "The default operation is replace."; > > } > > enum none { > > description > > "There is no default operation."; > > } > > } > > default "merge"; > > description > > "The default operation to use."; > > > > leaf test-option { > > if-feature validate; > > type enumeration { > > enum test-then-set { > > description > > "The server will test and then set if no errors."; > > } > > enum set { > > description > > "The server will set without a test first."; > > } > > > > enum test-only { > > description > > "The server will only test and not set, even > > if there are no errors."; > > } > > } > > default "test-then-set"; > > description > > "The test option to use."; > > } > > > > leaf error-option { > > type enumeration { > > enum stop-on-error { > > description > > "The server will stop on errors."; > > } > > enum continue-on-error { > > description > > "The server may continue on errors."; > > } > > enum rollback-on-error { > > description > > "The server will roll back on errors. > > This value can only be used if the 'rollback-on-error' > > feature is supported."; > > } > > } > > default "stop-on-error"; > > description > > "The error option to use."; > > } > > > > choice edit-content { > > > > mandatory true; > > description > > "The content for the edit operation."; > > > > anyxml config { > > description > > "Inline Config content."; > > } > > leaf url { > > if-feature url; > > type inet:uri; > > description > > "URL-based config content."; > > } > > } > > } > > } > > > > > > > > > Vladimir > > > > > > > > > > > > > > > Andy > > > > > > > > > On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev < > > > [email protected]> wrote: > > > > > >> On 09/13/2016 01:26 PM, Juergen Schoenwaelder wrote: > > >> > > >>> On Tue, Sep 13, 2016 at 01:19:02PM +0200, Vladimir Vassilev wrote: > > >>> > > >>>> I am wondering in which cases this is useful. Consider a candidate > > >>>>> datastore - why would a 'when' expression have to true after each > > >>>>> edit? Why do we force clients to send edits in such a way that > 'when' > > >>>>> expressions are true after each edit? > > >>>>> > > >>>> For example command line <TAB> completion in /interfaces/interface > can > > >>>> evaluate all 'when' statements in child data nodes and > augmentations and > > >>>> come up with relevant list of container and leaf child completions > > >>>> based on > > >>>> the already created /interfaces/interface/type (same applies for the > > >>>> options > > >>>> a user is presented with in a GUI after specifying the 'name' and > > >>>> 'type' of > > >>>> the interface). It is the same with 'if-feature' evaluations. The > 'must' > > >>>> statements however can be more complicated since they are only > checked > > >>>> when > > >>>> the interactive incremental edit process is complete and <commit> is > > >>>> attempted. > > >>>> > > >>>> I do not see what <TAB> completion has to do with the processing of > > >>> edit-config on the server. Are people implementing <TAB> completion > by > > >>> sending edit-configs to a server? But yes, trying to enforce > > >>> constraints while doing <TAB> completion may lead to surprises for > > >>> people not understanding the constraints being enforced via > > >>> incremental <TAB> completion. > > >>> > > >> Well it means that the 'candidate' configuration can not be in a state > > >> where any of the 'when' statements fail (since it is modified only > with > > >> <edit-config>). This is significant reduction of the entropy and thus > can > > >> be utilized for automation. In my example that fact is used for <TAB> > > >> completion. > > >> > > >> Vladimir > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > > > > > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
