Hello,
I would propose:
Change
"If the XPath expression references any node that also has associated
"when" statements, these "when" expressions MUST be evaluated first."
To
"If the expression in a when statement is dependent on a data node
controlled by another when or choice statement, the order of evaluation
of this when and the other when/choice statement is implementation
dependent."
Result:
- As this makes such cases non-interoperable it effectively says: Don't
use them as the results are unpredictable.
- We should explicitly state this in 6087bis
- This takes away the most nasty side effects of autodelete (and
auto-usage of default values, which can be just as big problem.)
- This would make implementation easier
- It is YANG 1.0 compatible, as the same yang module (YAM) is still
accepted.
- It is YANG compatible as the to-be deleted sentence was only inserted
by YANG 1.1. It is not present in YANG 1.0.
- As Martin stated, this is anyway an unseen, crazy corner-case
regards Balazs
P.S.1. My preference would be to say that such case are not just
implementation specific but rather forbidden, but that might be
incompatible, although I would consider them as error, so don't care
about compatibility.
P.S.2. I still don't like autodelete.
On 2015-10-21 20:15, Martin Bjorklund wrote:
Andy Bierman <[email protected]> wrote:
[...]
But the "when-stmt" never causes an error for application within
a datastore.
The text in sec. 8 does not apply because the when-stmt is not
on any object in the RPC being processed.
Only this text applies:
The "when" statement makes its parent data definition statement
conditional. The node defined by the parent data definition
statement is only valid when the condition specified by the "when"
statement is satisfied.
The NETCONF specific text needs to change.
Simply putting , "For example, NETCONF ..." might be enough.
Can you be more specific - exactly where do you suggest this change?
/martin
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
