Re: Questions on Confirmed commit

[Martin Bjorklund <mbj@tail-f.com>]

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> Hello,
> What happens in the following sequence:
> 
> 1) Operator A modifies the candidate datastore
> 2) Operator A successfully uses confirmed commit on candidate
> 3) Operator B successfully locks the running datastore
> 4) The confirmed commit times out
> 
> 5a) The locked running datastore is reverted to the previous version
> even though it's locked 
> 
> 5b) Nothing as due to the locked the running datastore can not be changed

I think you found an interesting case, and this should be clarified if
we ever see a rfc4741bis.

Anyway, I think that 5a must not happen - if the db is locked it
cannot be modified.  And 5b must not happen either, since it
contradicts the semantics of confirmed commit.  So, I think that 3
should not be allowed.  Essentially this would mean that when a user
invokes a confirmed commit it takes an (implicit) lock.


> ------------------------------------------------
> 
> When the node revert it's configuration due to an expired confirmed
> commit will it restore the candidate datastore. to it's previous
> state as well or only the running datastore?

Just running.


/martin

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>