> On 22 Aug 2016, at 14:56, Vladimir Vassilev <[email protected]> wrote: > > On 08/22/2016 01:56 PM, Ladislav Lhotka wrote: >> 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. > 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:
This would effectively remove the distinction between presence and non-presence containers, and I am not in favour of doing so. In any case, this is not something to introduce in the AUTH48 stage. > --- > 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. This wasn't clear in cases like my example. > 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. I don't agree with this conclusion. NACM probably needs to be updated anyway. >> >>> [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 I don't see it as a workaround and I don't think there is ANY limitation whatsoever due to this. The rules are now clear, which is a good thing. Lada > > 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 >>> [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
