On 08/22/2016 06:37 PM, Juergen Schoenwaelder wrote:
On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:
On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
Which of the 3 issues pointed in the conclusion you don't agree with and why
{1. limited validation expression flexibility, 2. higher validation
workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
predetermined from the fact of the reduced entropy attributed to a
non-presence container - namely its existence now is determined by the
existence of its parent (which reduces flexibility in a very certain way).
Can someone explain to me what exactly breaks NACM? An example would
help me.
/js (as contributor)
"It is absolutely legal to configure "update" rights to /interfaces to a
group of users reserving the "create" right to the superuser. How is this
scenario handled by servers ignoring empty non-presence containers?" (this
is excerpt from an earlier post on that thread)
If a non-presence container always exits in YANG 1.1 this usage example is
not possible.
Should I read 'ignoring empty non-presence containers' as 'removing empty
non-presence containers (form the XML encoding)'?
Yes the original post targeted the text: "If a container does not have a
"presence" statement and the last
child node is deleted, the NETCONF server MAY delete the container."
There is nothing indicating it is concerning only the XML encoding which
I believe can be fixed with AUTH48 modification if we agree this is the
intention.
Isn't the idea that non-presence container always exits in YANG 1.1
for the purpose of validation, that is in the XPATH context.
You have a point. The YANG 1.1 text addresses only the 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. ".
However now we have introduced a separation between a data tree and
Xpath context tree which only serves the case where data tree
non-presence containers are removed from the data tree automatically
(and not only from the XML encoding as assumed above). Or do you see any
other justification? It is this logic that creates the confusion and the
impression YANG 1.1 advocates the NACM unfriendly case of non-presence
containers being auto deleted from the data tree.
Back to your example, what is the client going to update in
/interfaces if /interfaces is empty? Or is the scenario that the group
of users have create and update rights within /interfaces but no
create right on /interfaces? I am trying to understand what exactly
the situation is that you think causes problems.
/js
Here I might experience revelation I always assumed update on a
container means you can create children in it but you can not create it
if it does not exist already if you only have update rights but no
create rights. There is no text in NACM RFC 6536 detailing what updating
container means. Are you saying one can only replace values of leafs
that already exist?
Vladimir
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
