Subject: [netmod] 'when' statement in edit-config payload parsing

From: Yves Beauville <[email-masked]>
Date: Mon, 12 Sep 2016 13:27:52 +0200

Hi,

I am trying to interpret this statement in Section 8.3.1 Payload Parsing 
of RFC 6020.

    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.

With the context node defined Section 7.19.5. The when Statement

    o  If the context node represents configuration, the tree is the 
data in the NETCONF datastore where the context node exists. The XPath 
root node has all top-level configuration data nodes in all modules as 
children.

I am providing this dummy module to illustrate my question:

module dummy {
   namespace "http://dummy.com";
   prefix "du";

   container root {
     leaf A {
       type empty:
     }
     leaf B {
       when "A";
       type uint32;
     }
   }
}

And I consider the following <edit-config> request, while A & B do not 
exist yet in the current datastore.

      <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">
              <A/>
              <B>
                3
              </B>
            </dummy>
          </config>
        </edit-config>
      </rpc>

During the parsing of the payload of the <edit-config>, leaf "A" is not 
yet present in the running datastore. The "when" statement that controls 
"B" evaluates to false.

Does this mean that the above edit-config request should be rejected 
with an "unknown-element" error-tag in the rpc-error? Or am I 
misinterpreting the RFC?

Yves

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2016 15:33:54 +0200

Hi,

I think Section 8.3.3. provides an answer:

   When datastore processing is complete, the final contents MUST obey
   all validation constraints.  This validation processing is performed
   at differing times according to the datastore.  If the datastore is
   <running/> or <startup/>, these constraints MUST be enforced at the
   end of the <edit-config> or <copy-config> operation.  If the
   datastore is <candidate/>, the constraint enforcement is delayed
   until a <commit> or <validate> operation.

/js

On Mon, Sep 12, 2016 at 01:27:52PM +0200, Yves Beauville wrote:
> Hi,
> 
> I am trying to interpret this statement in Section 8.3.1 Payload Parsing of
> RFC 6020.
> 
>    o  If the context node represents configuration, the tree is the data in
> the NETCONF datastore where the context node exists. The XPath root node has
> all top-level configuration data nodes in all modules as children.
> 
> And I consider the following <edit-config> request, while A & B do not exist
> yet in the current datastore.
> 
>      <rpc message-id="101"
> During the parsing of the payload of the <edit-config>, leaf "A" is not yet
> present in the running datastore. The "when" statement that controls "B"
> evaluates to false.
> 
> Does this mean that the above edit-config request should be rejected with an
> "unknown-element" error-tag in the rpc-error? Or am I misinterpreting the
> RFC?
> 
> Yves

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Sep 2016 17:35:03 +0200

> On 12 Sep 2016, at 15:33, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 

But sec. 8.1 lists "when" conditions among properties that must be true in all data trees, so it can never be false in <candidate/> either.

My answer to Yves' question is that the edit-config has to be applied atomically, and the constraints verified of the final result (a tentative version of "running") in which A is already present, so the edit is accepted.

Note, however, that the "when" expression should be

    when "../A";

The one in the "dummy" module is always false.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Sep 2016 09:33:08 -0700

On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka <[email-masked]> wrote:

> But sec. 8.1 lists "when" conditions among properties that must be true in
> all data trees, so it can never be false in <candidate/> either.
>
>

Both these statements seem wrong.
The "when" statement is applied to candidate.
It is not deferred at all.

Each tree (candidate, running, startup) can have different contents.
This will impact the evaluation of when-stmts.  No tree can have any
nodes that require when-stmt evaluation, and that evaluation result is
"false".
(May not be the same result as in other trees)

> My answer to Yves' question is that the edit-config has to be applied
> atomically, and the constraints verified of the final result (a tentative
> version of "running") in which A is already present, so the edit is
> accepted.
>

Andy

> yet
> with an

---

From: Xiang Li <[email-masked]>
Date: Mon, 12 Sep 2016 12:12:12 -0500

Hi Andy

On 9/12/2016 11:33 AM, Andy Bierman wrote:
>
>
> On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On 12 Sep 2016, at 15:33, Juergen Schoenwaelder
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi,
>     >
>     But sec. 8.1 lists "when" conditions among properties that must be
>     true in all data trees, so it can never be false in <candidate/>
>     either.
>
>
>

I agree.  RFC7950 section 8.1. "Constraints on Data", there is 
difference between
"all data trees" and "a valid data tree".

The following properties are true in *all data trees*:

...  The when statement is listed here

The following properties are true in a *valid data tree*:

... The must statement is listed here

-Xiang

>
>     My answer to Yves' question is that the edit-config has to be
>     applied atomically, and the constraints verified of the final
>     result (a tentative version of "running") in which A is already
>     present, so the edit is accepted.
>
>     >> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     >
>     >
>     > --
>     > Fax:   +49 421 200 3103       
>      <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>     --
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Sep 2016 10:33:33 -0700

On Mon, Sep 12, 2016 at 10:12 AM, Xiang Li <[email-masked]> wrote:

> On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka < <[email-masked]>
> [email-masked]> wrote:
>
>>
>> > On 12 Sep 2016, at 15:33, Juergen Schoenwaelder <
>> [email-masked]> wrote:
>> >
>> > Hi,
>> >
>> But sec. 8.1 lists "when" conditions among properties that must be true
>> in all data trees, so it can never be false in <candidate/> either.
>>
>>
>
> I agree.  RFC7950 section 8.1. "Constraints on Data", there is difference
> between

   o  There MUST be no nodes tagged with "when" present if the "when"
      condition evaluates to "false" in the data tree.

This text seems fine.
I can see how one might be confused by the text in 8.3.3

   When datastore processing is complete, the final contents MUST obey
   all validation constraints.  This validation processing is performed
   at differing times according to the datastore.  If the datastore is
   "running" or "startup", these constraints MUST be enforced at the end
   of the <edit-config> or <copy-config> operation.  If the datastore is
   "candidate", the constraint enforcement is delayed until a <commit>
   or <validate> operation takes place.

The last sentence refers to the 8.1 para 3 bullet list for a valid data
tree.

The distinction in 8.1 between "all data trees" and a "valid data tree" is
not obvious.
The intent of the former is that the constraint applies immediately (as
part of the
current edit operation).  The text could have been more direct that "all
data trees"
is really the candidate datastore tree.  All other standard data trees are
required
to be valid data trees at all times.

Andy

>> data in
>> >>           <root xmlns=" <http://dummy.com>http://dummy.com">
>> >>             <A/>
>> >>             <B>
>> >>               3
>> >>             </B>
>> >>           </dummy>
>> >>         </config>
>> >>       </edit-config>
>> >>     </rpc>
>> >>
>> > Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
>> http://www.jacobs-university.de/>
>> >
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Yves Beauville <[email-masked]>
Date: Tue, 13 Sep 2016 09:01:20 +0200

Hi Andi, Xiang, Juergen and Lada,

Thank you all for clarifying.

The scope of my original question was the context for evaluating a 
'when' expression during 'payload parsing' of an <edit-confg> RPC.

Both RFC 6020 and RFC 7950 are providing the same requirement in section 
'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.

Your replies provided clarifications on the validation, when the 
processing is complete. Do I understand it correctly that, for an 
<edit-config> RPC, I should ignore the above requirement during payload 
parsing and only consider the validation of when statements when 
processing is complete?

Thanks again,
Yves

On 9/12/2016 7:33 PM, Andy Bierman wrote:
>
>
> On Mon, Sep 12, 2016 at 10:12 AM, Xiang Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy
>
>>         But sec. 8.1 lists "when" conditions among properties that
>>         must be true in all data trees, so it can never be false in
>>         <candidate/> either.
>>
>>
>>
>>     nodes that require when-stmt evaluation, and that evaluation
>>     result is "false".
> The last sentence refers to the 8.1 para 3 bullet list for a valid 
> data tree.
>
> The distinction in 8.1 between "all data trees" and a "valid data 
> tree" is not obvious.
> The intent of the former is that the constraint applies immediately 
> (as part of the
> current edit operation).  The text could have been more direct that 
> "all data trees"
> is really the candidate datastore tree.  All other standard data trees 
> are required
>>         result (a tentative version of "running") in which A is
>>         already present, so the edit is accepted.
>>
>>          <http://www.jacobs-university.de/>
>>         >

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Sep 2016 09:22:52 +0200

> On 12 Sep 2016, at 18:33, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> nodes that require when-stmt evaluation, and that evaluation result is "false".

That's exactly what I am saying, no?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Sep 2016 09:34:33 +0200

> On 13 Sep 2016, at 09:01, Yves Beauville <[email-masked]> wrote:
> 
> The scope of my original question was the context for evaluating a 'when' expression during 'payload parsing' of an <edit-confg> RPC.
> 
> Both RFC 6020 and RFC 7950 are providing the same requirement in section '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.

This section seems confusing. It makes no sense to evaluate "when" or "must" on the contents of a protocol message such as edit-config because accessible trees for XPath evaluations are defined in sec. 6.4.1 in terms of datastores and "all state data".  

> 
> Your replies provided clarifications on the validation, when the processing is complete. Do I understand it correctly that, for an <edit-config> RPC, I should ignore the above requirement during payload parsing and only consider the validation of when statements when processing is complete?

I would say so.

Lada

>> I agree.  RFC7950 section 8.1. "Constraints on Data", there is difference between
>> The last sentence refers to the 8.1 para 3 bullet list for a valid data tree.
>> 
>> The distinction in 8.1 between "all data trees" and a "valid data tree" is not obvious.
>> The intent of the former is that the constraint applies immediately (as part of the
>> current edit operation).  The text could have been more direct that "all data trees"
>> is really the candidate datastore tree.  All other standard data trees are required

---

From: Yves Beauville <[email-masked]>
Date: Tue, 13 Sep 2016 09:36:49 +0200

Thank you Lada. It makes perfect sense now.

Yves

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2016 10:25:26 +0200

> This section seems confusing. It makes no sense to evaluate "when" or "must" on the contents of a protocol message such as edit-config because accessible trees for XPath evaluations are defined in…

I agree that this bullet in section 8.3.1 looks odd. Perhaps Martin
recalls why this was written in the first place?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Sep 2016 01:43:56 -0700

On Tue, Sep 13, 2016 at 1:25 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > This section seems confusing. It makes no sense to evaluate "when" or
> "must" on the contents of a protocol message such as edit-config because
> accessible trees for XPath evaluations are defined in sec. 6.4.1 in terms
> of datastores and "all state data".
> >
>

I recall that I did not agree that this error was clearly defined.
The subtle difference this line calls out is the case where the client
provides a configuration data node that evaluates to false immediately,
vs. an existing node that becomes false after the new edit is applied.
(The former is an error and the latter is just a silent delete).

One major problem with this text (as I pointed out years ago)
is that the when-stmt does not actually exist in the strictest sense.
It is hidden in the schema behind an "anyxml" node <config>.
The literal YANG says a when-stmt in the RPC input, but there isn't any.
The when-stmt is in the implied schema of the node provided in the anyxml
subtree.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Sep 2016 10:51:03 +0200 (CEST)

> recalls why this was written in the first place?

No.  It is however the same in 6020 and 7950.  I think the fourth
bullet in 8.3.2 is probably more clear, at least for edit-config.  The
bullet in 8.3.1 also covers copy-config.  The problem with the bullet
in 8.3.1 seems to be that it is not clear that the condition is
checked after the whole message has been parsed.

/martin

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 13 Sep 2016 12:42:07 +0200

> recalls why this was written in the first place?
IMO it is that bullet that sets apart 'when' from 'must' statements. 
With the current text 'when' statements should be evaluated along with 
'range',..., 'if-feature' etc. 8.3.1 specified validation statements 
upon every <edit-config> while 'must' statements should be evaluated 
only upon <commit> along with the rest of "description" statement 
validation checks done. The designer should take care to not specify 
'when' statements that hinder incremental editing of the 'candidate' 
configuration.

I use 'when' statements in models utilizing lists often with 'identity' 
leafs in the parent chain of data nodes and only testing for the values 
of those 'identity' leafs or the keys. Anything else IMO requires 'must' 
statements with proper dedicated error messages. Following this rule 
prevents situations where you need to have a single <edit-config> 
creating multiple leafs with complicated dependency to satisfy the 
'when' statements.

Probably a clarification that the 'when' statement should evaluate to 
'true' after the <edit-config> is applied (e.g. to a copy of the edited 
configuration for example) and not based only on the data content of the 
<edit-config> RPC is what is needed.

Vladimir

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2016 12:57:11 +0200

On Tue, Sep 13, 2016 at 12:42:07PM +0200, Vladimir Vassilev wrote:
> IMO it is that bullet that sets apart 'when' from 'must' statements. With
> the current text 'when' statements should be evaluated along with
> 'range',..., 'if-feature' etc. 8.3.1 specified validation statements upon
> every <edit-config> while 'must' statements should be evaluated only upon
> <commit> along with the rest of "description" statement validation checks
> done. The designer should take care to not specify 'when' statements that
> hinder incremental editing of the 'candidate' configuration.
> 
> leafs in the parent chain of data nodes and only testing for the values of
> those 'identity' leafs or the keys. Anything else IMO requires 'must'
> prevents situations where you need to have a single <edit-config> creating
> multiple leafs with complicated dependency to satisfy the 'when' statements.
> 
> Probably a clarification that the 'when' statement should evaluate to 'true'
> after the <edit-config> is applied (e.g. to a copy of the edited

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?

/js

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 13 Sep 2016 13:19:02 +0200

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

The usability of that is somewhat dependent on users not getting too 
creative with 'when' statements. In that case it will be hard to see why 
certain leafs and containers can not be created. Not even upon 'commit' 
since "unknown-element" is all the user gets. Carefully reading the 
models is the only solution in that case.

Vladimir

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2016 13:26:48 +0200

On Tue, Sep 13, 2016 at 01:19:02PM +0200, Vladimir Vassilev wrote:
> 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.

/js

---

From: Vladimir Vassilev <[email-masked]>
Date: Tue, 13 Sep 2016 13:43:13 +0200

> 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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Sep 2016 09:48:48 -0700

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.

Andy

On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev <[email-masked]
> wrote:

>>> on
> <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
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 14 Sep 2016 14:29:06 +0200

On 09/13/2016 06:48 PM, Andy Bierman wrote:
> will cause objects from the previously selected case to be 
> automatically deleted.
>
> If the client sets point-type to '2d' and provides a Z leaf, then an 
> error is returned.
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"

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"
            <candidate/>

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.

Vladimir

>
>
>
> Andy
>
>
> On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Sep 2016 07:48:17 -0700

On Wed, Sep 14, 2016 at 5:29 AM, Vladimir Vassilev <[email-masked]

> 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;
>     }
>   }
>            <root xmlns="http://dummy.com" <http://dummy.com>>
>              <A/>
>              <B>
>                3
>              </B>
>            </dummy>
>          </config>
>        </edit-config>
>      </rpc>
>
> is not 'running' but 'candidate' and /root/A is already present before the
> following <edit-config> is processed:
>
>      <rpc message-id="101"
>            <root xmlns="http://dummy.com" <http://dummy.com>>
>              <B>
>                3
>              </B>
>            </dummy>
>          </config>
>        </edit-config>
>      </rpc>
>
> 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-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Sep 2016 17:51:00 +0200

>               "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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Sep 2016 09:06:35 -0700

On Wed, Sep 14, 2016 at 8:51 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> automatically
> error
> validation

The text is poorly written in this particular area.
It is especially confusing to server implementors.

            anyxml config {
             description

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Sep 2016 19:08:55 +0200 (CEST)

> > 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".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Sep 2016 12:47:03 -0700

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

Andy

> > >>>> statements however can be more complicated since they are only
> checked
> > >>>> when
> can

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Sep 2016 22:42:08 +0200 (CEST)

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

> So I do not see how I can edit /foo and cause /foo to be deleted.

Agreed.

> deleted and this is not an error.

Yes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Sep 2016 13:58:07 -0700

> > deleted and this is not an error.
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.

Andy

> > > > > in <plot-point> is much clearer and I agree with all you say
> above).
> > > There
> > > > > 'when' statement is satisfied since when the <edit-config> is
> applied
> > > to
> > > > >>>> For example command line <TAB> completion in
> /interfaces/interface
> > > can
> > > > >>>> 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'
> > > > >>> edit-config on the server. Are people implementing <TAB>
> completion
> > > by
> state