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>.
/js
--
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
