On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton <[email protected]> wrote:
> Hi Andy, > > On 16/02/2017 22:36, Andy Bierman wrote: > > > > On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm < > [email protected]> wrote: > >> There are actually a number of interesting implications with regards to >> NACM. NACM could indeed be a key to the solution if it provides sufficient >> flexibility with regards to articulating and enforcing authorization >> rules. Regarding this, I have a number of questions/comments: >> >> >> >> - If a subtree contains objects that a client does not have >> write privileges for, will the client be prevented from locking the >> subtree? How about the case when the client does not even have read >> privileges? >> > > locking and NACM are 2 different things. > NETCONF has datastore (global) locks and subtree (partial) locks. > There is no mechanism in NACM or elsewhere that constrains the values > that a particular client can use. (NACM controls access to the rpc, with no > control over specific input paramters). > > > >> >> The current NACM-bis draft states in section 3.7.2 that this is not the >> case – i.e. a client is able to lock an entire subtree, even in cases when >> there is not a single object in that subtree that the client actually has >> access privileges to. >> >> >> >> To me, this does not seem right. It just invites abuse. >> >> >> >> Now, there is still the possibility to restrict access to the operation >> overall. But again, this means that you have to give a users an >> all-or-nothing choice. Too inflexible. By the same token that partial >> locks were supported to avoid requiring anyone who needs the ability to >> conduct a transaction to lock down the entire server, there should be the >> ability to restrict access to the lock and partial-lock operation by >> targeted subtree. However, this capability is currently missing. >> > > > NACM was designed to be simple to implement. > Some complex features that were in VACM were intentionally left out of > NACM. > NETCONF locking is also intentionally simple. > > I would rather have NETCONF 2.0 use a mandatory implicit, optimistic > concurrent > locking model, rather than more band-aids on the optional explicit, > pessimistic > serialized locking model we have now. > > This is interesting. If you have time, then at some point, please can you > expand on this idea, perhaps on the NETCONF alias? > > NETCONF does not really support concurrent transactions. It supports serialized transactions with explicit locks. More than that is complicated, so it's probably not going to change any time soon. Thanks, > Rob > > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
