Subject: Re: [Netconf] lock and commit operations

From: WashamFan <[email-masked]>
Date: Tue, 04 Aug 2009 17:51:43 +0800

Hi,

I agreed with Martin, letting lock on candidate control <commit>
breaks the sematics of lock.

Why we just constrain the behavior of <commit> in 8.3.4.1 stating
like:

<commit> can't take effect the changes in either candidate or 
running is locked.

washam

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Saturday, August 1, 2009 0:50 am
Subject: Re: [Netconf] lock and commit operations
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]

> Martin Bjorklund wrote:
>  > [resend]
>  > 
>  > Phil Shafer <[email-masked]> wrote:
>  >> Andy Bierman writes:
>  >>> Does the lock on candidate have any affect on <commit>?
>  >> 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.
>  > 
>  
>  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.
>  
>  
>  > 
>  > /martin
>  > 
>  
>  Andy
>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: WashamFan <[email-masked]>
Date: Tue, 04 Aug 2009 17:55:53 +0800

>  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 am afraid draft partial-lock does not preclude the candidate scenario,
please see 2.1.1.3

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

---

From: Phil Shafer <[email-masked]>
Date: Sat, 8 Aug 2009 10:29:17 -0400

Martin Bjorklund writes:
>committing?  If running is locked it is obvious since running will be
>modified by the commit.

So to make candidate work correctly, I'd need to lock both candidate
and running?  This is also not obvious.

IMHO we just need to add words that a lock on candidate blocks
the commit operation.  This is what we do in junos.

Thanks,
 Phil