Re: lock

[Phil Shafer <phil@juniper.net>]

Martin Bjorklund writes:
>Since I didn't get any replies on this I'll try to rephrase.

Sorry.  Actually your original wording was fine.

>The only way to save the changes done after a lock is to
>commit.

Well, you could <copy-config>, but most likely you'll commit or
discard.

>This means that the candidate can only be used by a single
>client before committing to running.

This is the intent.  See more below....

>Martin Bjorklund <mbj@tail-f.com> wrote:
>> 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?

Yes, this is correct.

>> What is the purpose of this condition?

To prevent applications from (a) stealing the lock while a human
user is in the process of making changes, and (b) preventing the
script from committing changes which it did not make.

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

"A" would have no idea what changes are outstanding when it re-aquired
the lock.  Its changes could have been discarded, committed, or added
to.  If you could release the lock with outstanding changes or aquire a
lock with outstanding changes the application would have no idea of the
state of the configuration.

Thanks,
 Phil

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