On 10/18/2015 8:31 AM, Ladislav Lhotka wrote:
Xiang Li <[email protected]> writes:
On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
On 16 Oct 2015, at 12:27, Balazs Lengyel <[email protected]> wrote:
IMHO YANG should define the behavoir, and I would want it to be the same on
Netconf/Restconf/CLI etc.
I agree that " 1) you get an error back" would be the best: because it is the
easiest to understand for the operator, with the fewest corner cases.
Also we must define if in the same transaction we set b=42 and a=2. which of
the 3 options are taken?
We should not leave such complex cases undefined, or alternatively state that
they are implementation dependant.
I might be difficult to say what is a complex case, unless we abandon XPath in
"when" statements and use something else - and considerably simpler.
Here is another interesting corner case - does it qualify as being complex?
leaf-list bar {
type uint8;
when "count(../*) > 1";
}
leaf foo {
type uint8;
}
Interesting example...
Assuming no instances exist, is this edit allowed? (This was essentially your
question.)
<bar>1</bar>
<foo>2</foo>
I think this should succeed
But what about this?
<bar>1</bar>
<bar>2</bar>
I think this should succeed too because the when is satisfied in the
data store after the edit-config.
According to the third bullet in sec. 7.21.5 of 6020bis, a validating
algorithm has to remove the existing "bar" instances, add a dummy
instance and then evaluate the XPath expression. If the result is true,
the existing "bar" instances will be put back, otherwise a validation
error will be reported - so in our case we will have only one "bar" node,
which is invalid.
Thanks you are right. I missed that...
The result of this change is that we (hopefully) made the processing of
"when" well-defined and unambiguous, but the cost in increased comlexity
is quite high - both for module readers and implementors of a validating
algorithm.
yes the clarification in sec. 7.21.5 of 6020bis does make this clearer.
In fact, when we discussed issue Y18, my understanding was that dummy
node manipulations will be used only if the context node is missing.
This is something that actually still confuses me! If a context node
exists why we
still need to replace it with a dummy node, especially if an edit-config
is performing a "merge" operation?
-Xiang Li
Lada
-Xiang Li
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
