Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

The intention in this case is obviously to evaluate the 'must' statement if
the container contains any values; what would break if we said that

   A non-presence container exists in the data tree if and only if it has
   any children which exist in the data tree.

thus disallowing the existence of empty NP-containers in the data tree?

________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Vladimir Vassilev <vladimir@transpacket.com>
Sent: Tuesday, 23 August 2016 7:41 a.m.
To: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

On 08/22/2016 08:27 PM, Martin Bjorklund wrote:
> Vladimir Vassilev <vladimir@transpacket.com> wrote:
>> On 08/22/2016 06:45 PM, Martin Bjorklund wrote:
>>> I disagree.  If the model needs to have some semantic validation
>>> rules, the designer is going to put them in a place such that they are
>>> evaluated when the need to be evaluated.
>> So designers augmenting /interfaces/interface with non-presence
>> container with child leaves should just pick one of the leaves in YANG
>> 1.1 and put the must statements there instead of the parent
>> container.
> Sorry I can't parse this.  What is "leaves in YANG 1.1"?
Well for example the designer wants to add container with multiple leaf
children (leaves) to /interfaces/interface. Assume there is only 1 of
the 96 interfaces on a switch that can have inet address for the purpose
of managing the device:

augment "/if:interfaces/if:interface" {
     container inet {
         must "../name = 'me0'" {
             description
                  "The inet container is only valid for the management
('me0') interface.";
         }
         leaf address {
             type inet:ip-prefix;
         }
     }
}

So in this example the must expression will be evaluated not only for
interfaces the user attempts to create
/interfaces/interface/inet/address but for all those he does not attempt
to create it. This is not the case in YANG 1.0 and this is example how
processing of validation expressions increases in YANG 1.1

In this case the designer can copy the must expression to the address
leaf and it will be evaluated only when the user attempts to create that
leaf ... however when it is not a single leaf in the container the
workaround can get trickier.

>
> My point is that must expressions don't just exist w/o any reason for
> the sake of theoretical arguments.  If there is a YANG 1.1 model with
> a must expression in an NP-container, then there is probably a reason
> for it - the designer wants it to be evaluated if its parent exist.
Well this would be the case in YANG 1.1. In YANG 1.0 the designer wants
it to be evaluated if the non-presence container itself exists not its
parent. Now this changes because of the "clarification" from Y41.
> If we change the rules for when must expressions are evaluated, the
> module designer will have to figure out some other way to add these
> must expressions, and the performance will be the same.  So your
> argument that many must expressions can lead to performance issues is
> not really a problem in itself.
We are changing the rules from YANG 1.0. Auto evaluation of all
non-presence containers must statements is now mandatory when their
parent container exists. I still don't see how there is no problem with
the increased must statement processing and believe there is
misunderstanding somewhere.

Vladimir
>
>
> /martin
>
>> Yes this might work. There is no problem adding extra "../"
>> in the Xpath expressions. But what is the justification of all that
>> except the "If a container does not have a "presence" statement and
>> the last child node is deleted, the NETCONF server MAY delete the
>> container." text?
>>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod