On Wed, Sep 14, 2016 at 1:42 PM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > 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. > > The intention was that also create/delete would cause this error. > > > Edits to other nodes (e.g., /bar) do not cause an error. > > Yes. > > > 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. > > Agreed. > > > According to the text, if I alter /bar (not /foo) then /foo can be > silently > > deleted and this is not an error. > > Yes. > > Customers have asked for this to be an error. We have a CLI parameter to turn on/off the error. It is generally considered a client programming error if the edit payload contains any nodes that get immediately deleted because of false when-stmts. In generally indicates that the client's notion of the existing config is incorrect. > /martin > Andy > > > > > > > > > > > > /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
