Vladimir Vassilev <[email protected]> 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.
>
> [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?
>
> [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.
>
> [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)";
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
