On 08/22/2016 08:27 PM, Martin Bjorklund wrote:
Vladimir Vassilev <vladi...@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
