lock

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

Hi,

In section 7.5 <lock>, the draft says:

      A lock MUST not be granted if any of the following conditions are
      true:

      [...]

      *  the target configuration has already been modified and these
         changes have not been committed or rolled back

I assume that this mean that the last condition applies only to the
candidate configuration, since this is the only target configuration
that can be committed through NETCONF. So the text could have been:

      *  the target configuration is 'candidate' and it has already
         been modified and these changes have not been committed or
         rolled  back.

Is this correct?


What is the purpose of this condition?  Suppose user A is a good
citizen and takes a lock and modifies the candidate, then releases the
lock.  Then, before committing, A wants to do another change.  So A
tries to grab the lock again - but this will fail since there are
uncommitted changes.  So A has to do the changes w/o the lock or do
discard-changes, take the lock, redo all original modifications, do
the new modifications, and then commit.

Section 8.3.1 also says:

   The candidate configuration may be shared among multiple sessions.
   [...] It is therefore prudent for a client to lock the candidate
   configuration before modifying it.


Is the intention that you have to commit after each modification?



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