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

[Vladimir Vassilev <[e-mail]>]

On 08/22/2016 08:27 PM, Martin Bjorklund wrote:
> Vladimir Vassilev <[e-mail]> 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?
>>