[Netconf] #17: Unspecified aspects of confirmed commit

["Netconf" <trac@tools.ietf.org>]

#17: Unspecified aspects of confirmed commit
-----------------------------------------+----------------------------------
 Reporter:  balazs.lengyel@ericsson.com  |       Owner:     
     Type:  defect                       |      Status:  new
 Priority:  major                        |   Milestone:     
Component:  RFC4741                      |     Version:     
 Keywords:  confirmed commit locking     |  
-----------------------------------------+----------------------------------
 What happens in the following sequence:[[BR]]
 1) Operator A modifies the candidate datastore[[BR]]
 2) Operator A successfully uses confirmed commit on candidate[[BR]]
 3) Operator B successfully locks the running datastore[[BR]]
 4) The confirmed commit times out[[BR]]
 [[BR]]
 5a) The locked running datastore is reverted to the previous version
 even though it's locked [[BR]]
 [[BR]]
 5b) Nothing as due to the lock the running datastore can not be
 changed[[BR]]

 ----

 Proposed answer:[[BR]]
 5a) must not happen - if the db is locked it cannot be modified. [[BR]]
 5b) must not happen either, since it contradicts the semantics of
 confirmed commit.  [[BR]]
 3) should not be allowed.  Essentially this would mean that when a user
 invokes a confirmed commit it takes an (implicit) lock.[[BR]]

 ----

 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?[[BR]]

 ----

 Proposed answer:[[BR]]
 Only the running datastore is reverted, the candidate is not.

-- 
Ticket URL: <http://tools.ietf.org/wg/netconf/trac/ticket/17>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Group�������zǧu���Ơz�z�����l���0����ۧ����z)ڲ)�b�欶�z����w&�r�zm����������w�