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

[Vladimir Vassilev <[e-mail]>]

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

Vladimir

>
>
>
> Andy
>
>
> On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev 
> <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>