On Wed, Sep 14, 2016 at 8:51 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Wed, Sep 14, 2016 at 07:48:17AM -0700, Andy Bierman 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. > > > > > > 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."; > > } > > } > > } > > } > > It the careful readers have determined that the text serves no > purpose, we should go and have an errata that the text is to be > ignored. The art of writing standards is to come up with text that > multiple people understand in the same way. > > Careless readers like me may indeed interpret 'data for a node tagged > with "when"' as refering to schema nodes for which data is present in > an RPC payload. > > 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>. > > The text is poorly written in this particular area. It is especially confusing to server implementors. anyxml config { description "Inline Config content."; } They see that the <config> input parameter has no when-stmts at all. Other text in the RFC says that only the anyxml node itself is allowed to have a when-stmt. The descendant nodes in an instance document for this <config> node are not data nodes. (Note "anyxml", not "anydata".) An error for adding data nodes to a datastore which are immediately removed because of false when-stmts does not exist in the RFC. It may be true that the WG wants this to be an error, but that seems like a refinement to the <edit-config> definition, not to YANG. It is certainly not a refinement to the when-stmt processing for anyxml parameters in RPC statements. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
