Subject: [Netconf] lock and commit operations

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 09:41:05 -0700

Hi,

A careful reading of 4741bis, sec. 7.5, para 4 reveals
that the the "candidate" portion of the database architecture
is seriously broken.

The <lock> operation does not affect the <commit> operation at all.
Martin already pointed this out.  Even if I lock every database
on the box, anybody can just login at anytime and issue <commit>,
and ruin the 'database transaction' I am trying to complete.
(Note the quotes, as to not offend any database experts
out there who know NETCONF does not support real transactions.)

If I am doing a confirmed-commit, anybody who logs in and invokes <commit>
will confirm my commit, instead of letting me decide
to keep or cancel the recent changes to running.
Even though I have every database globally locked.

Since <partial-lock> does not work on the candidate database at all,
there is no need to worry about how <commit> works with partial locking.

I don't think a :confirmed-commit.1.1 capability can fix
all these problems.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Jul 2009 12:53:16 -0400

Andy Bierman writes:
>Martin already pointed this out.

This is a mistake that needs to be repaired in -bis.  The
intent was that commit would fail if the candidate is locked
by another session.  This is definitely what we do in JUNOS.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 10:24:49 -0700

> by another session.  This is definitely what we do in JUNOS.

Good.
Let's just declare it a bug in 4741 and not worry
about backward compatibility.  The new text needs
to go in 8.3.4.1 or 7.5.

I do not remember any intent at the time 4741 was written to
allow <commit> to bypass all locking.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2009 11:22:58 -0700

> by another session.  This is definitely what we do in JUNOS.

I just looked my code, and it checks to see if
either candidate or running is locked before allowing <commit>.

Part of the commit operation involves re-synching
the candidate with running.  I suppose, in theory,
the candidate should be the same as running at this point,
but the code that refreshes the candidate runs anyway.

So add another issue:
Does the lock on candidate have any affect on <commit>?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 30 Jul 2009 21:15:41 +0200 (CEST)

> either candidate or running is locked before allowing <commit>.

I checked my code and it did the same.

> Does the lock on candidate have any affect on <commit>?

Yes, this needs to be spelled out.  I don't remember, but since both
of us do this check (even though it is not clearly specified), maybe
this has been discussed on the ML earlier?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 30 Jul 2009 19:17:15 -0400

>Does the lock on candidate have any affect on <commit>?

Absolutely.   The lock on config controls the commit.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 17:09:24 +0200 (CEST)

[resend]

> Absolutely.   The lock on config controls the commit.

This is not obvious so it needs clarification.  <commit> does not
modify the candidate, so why does a lock on candidate prevent me from
committing?  If running is locked it is obvious since running will be
modified by the commit.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Jul 2009 16:55:27 +0200 (CEST)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jul 2009 09:48:38 -0700

> committing?  If running is locked it is obvious since running will be

Agreed.  It is obvious a lock on the running config should stop
a commit. Candidate is not obvious at all because it should
never change (OK or error) because of commit.

I am wondering if 'running' is the only lock that should prevent a commit.

The lock on candidate should prevent edit-config, delete-config,
copy-config, and discard-changes.

Andy