On Mon, Aug 22, 2016 at 07:21:06PM +0200, Vladimir Vassilev wrote:
> 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.
What we need is a clear problem statement people can agree on and a
clear proposal how to resolve the problem that people can also agree
on. I think we are not even close to a clear problem statement since
logic often appears circular.
> > 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?
RFC 6536 says:
o Create: allows the client to add a new data node instance to a
datastore.
o Update: allows the client to update an existing data node instance
in a datastore.
For me, this means that create and update are different operations and
in the context of a container, update does not really make any sense
since a container node does not have a value that can be updated.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
