Dear Juergen Schoenwaelder,
On 08/22/2016 11:25 AM, Juergen Schoenwaelder wrote:
On Sat, Aug 20, 2016 at 07:18:42PM +0200, Vladimir Vassilev wrote:
Hello,
I have strong objection to the text proposed as solution to issue #41:
Dear Vladimir Vassilev,
please note that we YANG 1.1 is in AUTH48 state, that is YANG 1.1 has
passed WG last call, IETF last call, and IESG approval. In other
words, we are way beyond the state in the IETF process where we
discuss the resolution of individual issues. As far as I recall from
the logs, issue #41 was closed about two years ago.
/js
I wrote my proposal for errata as if the RFC was published hoping it
would gain agreement on the bug and the proposed fix and hopefully get
addressed during the editing/auth48 stage so we do not have to post an
RFC with already known defects. I interpreted your mail as invitation
for people with opinion on the issue to post their concrete proposals
which is what I did.
On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:
: It is possible that people will find more bugs while this I-D sits in
: the RFC editor queue. My idea is to treat them pretty much in the way
: we treat errata of published RFCs (they need to be clearly written up,
: discussed on the list, there needs to be agreement on the bug and the
: proposed fix). If we get pre-publication errata with consensus, I hope
: we can address them during the editing/auth48 stage so we do not have
: to post an RFC with already known defects. Does this make sense to
: you?
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.
/js
Why is the "defect description and proposed bug fix" I propose not a
candidate for consideration for a AUTH48 change?
Can someone with alternative opinion comment on the issues [1-4] I list.
I really hope I am wrong and those are not as significant problems as it
currently seems to me.
On 08/20/2016 07:18 PM, Vladimir Vassilev wrote:
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.
[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?
[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.
[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
[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
Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
