On 08/22/2016 01:56 PM, Ladislav Lhotka wrote:
Vladimir Vassilev <vladi...@transpacket.com> writes:
On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
As document shepherd, I believe there is no strong agreement on the
problem and there is no concrete proposal with strong consensus for a
modification of the document (which is in AUTH48). In fact, there has
been no defect description and proposed bug fix at all on the NETMOD
mailing list.
Hello,
I have strong objection to the text proposed as solution to issue #41:
6.4.1 Xpath Context:
If a node that exists in the accessible tree has a non-presence
container as a child, then the non-presence container also exists in
the tree.
The description of the issue itself is:
Y41: clarification of "must" in NP-container <<Y41>>
I believe the 5 mails in the
http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did
not address all the negative consequences of such change in the rules
for evaluation of validation statements regarding non-presence
containers and the solution that was taken is not acceptable for the
following reasons:
[1] the proposed text is not a clarification as indicated in Y41 but a
backward incompatible change of the YANG validation statement evaluation
rules.
The charter doesn't limit YANG 1.1 to clarifications. The adopted
solution addresses ambiguous cases like this:
container top {
must "foo > 42";
leaf foo {
type uint8;
}
leaf bar {
type boolean;
default true;
}
}
If "top" doesn't exist, then according to sec. 7.6.1 of RFC 6020, the
default value of "bar" is in use, so somehow the NP-container "top"
should also be in use. The question then arises whether the "must"
constraint applies or not.
This example is based on the bug I propose to be fixed. If you looked at
the patch I propose in
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec.
7.1.6 of RFC 6020 is modified:
---
OLD:
7.6.1. The leaf's default value
The default value of a leaf is the value that the server uses if the
leaf does not exist in the data tree. The usage of the default value
depends on the leaf's closest ancestor node in the schema tree that
is not a non-presence container:
NEW:
7.6.1. The leaf's default value
The default value of a leaf is the value that the server uses if the
leaf does not exist in the data tree. The usage of the default value
depends on the leaf's closest ancestor node in the schema tree:
---
The patch removes the "MAY be deleted" text and all artifacts resulting
from poor attempts to cover the logical discontinuity it inflicts on
YANG. It is the only justification of all special case clarifications
regarding non-presence containers which are never going to be enough to
cover all private cases.
[2] the clarification introduces further confusion for models like NACM
where non-presence containers are used for access control and their
explicit creation and deletion is the only sane way to enforce the
configured rules. Always present non-presence containers that MAY be
auto deleted by servers ... how will this work exactly?
IMO the problem is in this auto-deletion option. I suspect my example
above may also be unclear from the NACM point of view - do the rules set
for "top" apply if "top" hasn't been explicitly configured?
+1 I do not know either. NACM is affected in a bad way. The "MAY be
deleted" text was not that bad since one would assume sane servers would
not auto delete data nodes which already have configured NACM rules.
[3] the proposed text leads to increased processing of large number of
validation checks which is very unlikely to bring real value to YANG. 20
non-presence containers with must statements per interface in
96-interface switch is already heavy Xpath evaluation task. A task that
in YANG 1.0 was not necessary if the containers were not explicitly
created.
Some implementations did it anyway and some didn't, which was considered
a problem.
The implementations that did it anyway were not conforming to YANG 1.0
since non-presence containers were not part of the configuration tree by
default unless they were explicitly created. By introducing the Y41
"clarification" now they are conforming which is the only benefit at the
cost of limited validation expression flexibility, higher validation
workload, broken NACM and probably some other issues we are about to
discover.
[4] the proposed text leads to less flexibility and excludes certain
practical validation models e.g.
https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html
Well... If the goal it to prevent np2_leaf from appearing when np1_leaf
is configured, then the most natural solution is to put a must statement on
np1_leaf:
leaf np1_leaf {
type string;
must "not(../../np2/np2_leaf)";
}
Or if you insisted on having it on the "np1" container, you can do this:
must "not(np1_leaf) or not(../np2/np2_leaf)";
Yes there are workarounds but the solution I propose is to remove the
cause leading to the limitation and the need to use workarounds. If it
is too late at least there will be a trace in the netmod mailing list
indicating the issue was recognized before the publication of the RFC
and something to consider in YANG 1.2
Vladimir
Lada
[5] the proposed text inflicts problems 1-4 and its clarification effect
is not working for me.
I have a concrete proposal for a solution on the issue - remove the
"non-presence containers MAY be deleted automatically" text from YANG
1.1 instead of opening Pandora's box:
Instead of building further the pipe dream of non-presence containers
that MAY be deleted automatically I propose that flexibility removed
from YANG 1.1. All non-presence containers have to be created explicitly
and the validation statements must be evaluated only for explicitly
created containers (so long there is no change from YANG 1.0) and these
containers MUST be deleted explicitly (replacing the "MAY be deleted
automatically" YANG 1.0 optimization attempt which is the origin of the
pipe dream) as one would logically expect. It is semantical meaning that
is not present not the container which still has its usage giving
structure to the data and especially in cases like NACM and validation
statements where without certain explicit create/delete rules things get
really confusing.
The concrete proposal in form of a patch to RFC6020 sent in this e-mail
to the netconf mailing list:
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html
There will be even more obsoleted clarification text that will be
irrelevant if the concept change is applied to YANG 1.1
Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
