Subject: lock

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Dec 2005 16:16:05 +0100 (CET)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 11 Dec 2005 23:41:10 +0100 (CET)

Hi again,

Since I didn't get any replies on this I'll try to rephrase.

It is recommended that locks are used when working on the candidate.
But the candidate is reverted to the running as soon as the lock is
released.  The only way to save the changes done after a lock is to
commit.  This means that the candidate can only be used by a single
client before committing to running.

From the rest of the text (e.g. section 9 and 8.3.1) I don't think
this is the intention?

Why isn't the special semantics of lock of the candidate (8.3.5.1 and
7.5) simply removed?

[Ok, I realize that you _can_ get the same effect by using a local URL
- clients always write with locks to a local file.  When it's time to
commit, you first copy-config from the local file to the candidate,
then issue a commit command, possibly w/ a timeout.]

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sun, 11 Dec 2005 23:44:56 -0500

>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

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

>>          been modified and these changes have not been committed or

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 12 Dec 2005 07:36:22 -0500

Hi,

I think this is correct for version 1. 

There may be more than one possible candidate in future versions, and
specifying that "the target configuration is 'candidate'" would be
incompatible with those future versions.

David Harrington
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 12 Dec 2005 09:13:19 -0800

>>>>> On Mon, 12 Dec 2005 07:36:22 -0500, "David B Harrington" <[email-masked]> said:

David> There may be more than one possible candidate in future versions, and
David> specifying that "the target configuration is 'candidate'" would be
David> incompatible with those future versions.

Nah...  You'd just have "candiate1" being different than
"candidate"...  Actually they'll like be named and the "unnamed"
category will have be a special one for backwards compatibility.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Dec 2005 20:59:54 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> This is the intent.

Ok.

> script from committing changes which it did not make.

I thought that (a) would be avoided by making the CLI/WebUI/whatever
take a lock as well.

But a script is allowed to make changes and even comitting w/o taking
a lock.  Since the draft talks about the candidate as possibly being
"shared among multiple sessions" and also the text in section 9; I
assume that the intention is that sometimes NETCONF locks will be used
on the candidate and sometimes not?  So a script can decide by itself
if it wants to commit changes it didn't make or not.

I'm just a bit surprised - I thought that the candidate was a
persistent, shared, "scratchpad" configuration which could be made
consistent using locks.  As it is now, it behaves differently if locks
are used or not - if locks are not used, it's a persistent shared
scratchpad configuration which may or may not be consistent, but if
locks are used it's a way of doing a transaction for a single client.

Wouldn't it be more clean to separate these two functions?

> state of the configuration.

"A" would have to do a get-config first of course, just as it would
have to do if the changes were committed - after a commit, anyone
could have made the changes you describe above.

thanks

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 12 Dec 2005 13:22:40 -0800

>>>>> On Sun, 11 Dec 2005 23:44:56 -0500, Phil Shafer <[email-masked]> said:

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

Martin> What is the purpose of this condition?

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

Martin: Note that the case you brought up about a user locking himself
out of his own changes is one of many examples where locking can
actually be misused.  The more interesting cases, IMHO, are the ones
where user B has made changes to the candidate config that user A
isn't allowed to change.  In this case, A can no longer commit the
changes, get a lock, discard the changes, etc.  IE, B doesn't have to
lock the candidate configuration in order to make user A loose all
ability to deal with the candidate configuration set in any useful way.

>>> tries to grab the lock again - but this will fail since there are

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

Phil> Thanks,
Phil> Phil

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 12 Dec 2005 17:22:19 -0500

>I thought that (a) would be avoided by making the CLI/WebUI/whatever

We're trying to make something that will integrate easily
with existing implementations and existing usage scenarios.
So there's no "making [ancient users] take a lock".  Users
will enter and perform their ritual tasks in the Temple of
the CLI without changing their actions.  Forcing a new world
order on them is a non-starter.

>if it wants to commit changes it didn't make or not.

The suggestion is that locks always be used, but we make allowances
for folks that avoid locking (for unknown reasons).  Most of this
is fallout from earlier drafts when locking was (for unknown
reasons) an optional capability.

>locks are used it's a way of doing a transaction for a single client.

Yup, those are your choices.  You can use it as a transaction mechanism
for a single client, given protection and predictability to your world, or
you can use it as a shared workspace, with the assumption that all those
sharing the resource are sane and well-behaved.

>could have made the changes you describe above.

We don't want to force anyone to do a full get-config.  If you
just want to make a couple of minor changes, you don't need to
traffic the entire config.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Dec 2005 23:37:48 +0100 (CET)

> order on them is a non-starter.

Agreed.  But the CLI engine etc could do that for the user.  The CLI
engine must be aware of NETCONF locks anyway, as defined in the specs
(7.5).

Ok.

> sharing the resource are sane and well-behaved.

They don't have to be evil, you can get strange results if no locks are
used just by bad timing.

> traffic the entire config.

Thanks for the clarifications!  Maybe some of these clarifications you
just sent could go into the specs to make the intentions more clear
for new readers?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 12 Dec 2005 17:54:10 -0500

>engine must be aware of NETCONF locks anyway, as defined in the specs

The CLI could lock the config when the user does their first config
change, but that would foil the scenario where two users are working
together and don't want locks.  And the CLI won't know whether the
user wants to share the candidate with the NETCONF session or not.
So we pseudo-lock the config from NETCONF by failing the lock if
there are outstanding changes.  Ensures that humans and applications
can live in peace.

>They don't have to be evil, you can get strange results if no locks are

Absolutely.

>just sent could go into the specs to make the intentions more clear

Amen.

Thanks,
 Phil