Subject: [Netconf] Global lock - is it good - do you implement it?

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Oct 2013 17:43:10 +0200

Hello,
Maybe this has been asked already, in this case sorry?
We see a number of problems with the global lock
- you might want multiple operators working on different part of the 
system, global lock can't be used
- data set by automation (on-board or off-board)/SON/SDN  conflicts with 
a global lock, If you lock the datastore the automated algorithms stop
- access control for global locking is a problem. You either don't use 
lock or you need to give every operator the right to block configuration 
of the full node. Neither is good.
- many systems have database style automatic implicit locking, these 
don't need explicit locking, it just makes life difficult

Considering all these, why is explicit global locking mandatory? Also do 
you really implement it?
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Oct 2013 18:00:43 +0200

On Thu, Oct 17, 2013 at 05:43:10PM +0200, Balazs Lengyel wrote:

[...]
 
> Considering all these, why is explicit global locking mandatory?
> Also do you really implement it?

I do not understand the question. Global locks are mandatory to
implement, not mandatory to use. If partial locks (RFC 5717) work
better for you, then use them. Or is the question you really want to
get at whether partial locks should be mandatory? That question I
would understand given your motiviation (that I trimmed).

/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/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Oct 2013 09:23:36 -0700

Hi Balazs,

You are mixing apples and oranges.
NETCONF locking provides a crude exclusive write access mechanism.
It does not provide any concurrent writing features. Its sole purpose
is to prevent concurrent writes on a datastore.

An architecture that provides implicit locking and concurrent writes
is difficult to integrate into the current NETCONF locking model.
I haven't figured that part out.  I don't think it is possible.

BTW, you forgot to mention that global locks also cause a security hole
because a user with no write access can still (by default) lock any
datastore.

And you forgot my other pet problem with global locks -- client deadlock,
because a client can only lock 1 datastore at a time.  E.g.

   - server supports candidate and running
   - client 1 gets a lock on running
   - client 2 gets a lock on candidate
   - client 1 is blocked trying over and over to get a lock on
     candidate (or it releases running and starts over)
   - client 2 is also stuck, but waiting for the lock on running to clear

Andy

On Thu, Oct 17, 2013 at 8:43 AM, Balazs Lengyel <[email-masked]
> wrote:

> - data set by automation (on-board or off-board)/SON/SDN  conflicts with a
> global lock, If you lock the datastore the automated algorithms stop
> lock or you need to give every operator the right to block configuration of
> the full node. Neither is good.
> - many systems have database style automatic implicit locking, these don't
> need explicit locking, it just makes life difficult
>
> ______________________________**_________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Oct 2013 19:18:23 +0200

> because a user with no write access can still (by default) lock any

Simply deny the lock operation.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Oct 2013 10:25:39 -0700

> Simply deny the lock operation.

I suppose.  Actually, taking a lock if the session has read access
to the datastore is fine.  I meant to say that a session with no
read or write access at all is very likely to have exec access to <lock>.
This is the NACM default.

Andy