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

[Andy Bierman <[e-mail]>]

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

> Hi Andy
>
> On 9/12/2016 11:33 AM, Andy Bierman wrote:
>
>
>
> On Mon, Sep 12, 2016 at 8:35 AM, Ladislav Lhotka < <[e-mail]>
> [e-mail]> wrote:
>
>>
>> > On 12 Sep 2016, at 15:33, Juergen Schoenwaelder <
>> [e-mail]> wrote:
>> >
>> > 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.
>>
>> 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)
>
>
> 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
>
>



   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.



The following properties are true in a *valid data tree*:
>
> ... The must statement is listed here
>
>
>
> -Xiang
>
>
Andy


>
>
>> 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
>>
>>
>
> Andy
>
>
>> >
>> > /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 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>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
>> >
>> >> _______________________________________________
>> >> netmod mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >
>> >
>> > --
>> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> > Fax:   [phone]         < <http://www.jacobs-university.de/>
>> http://www.jacobs-university.de/>
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>