Subject: [Netconf] lock/unlock on candidate

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 15:29:06 -0000 (GMT)

The section 8.3.1 in RFC 4741 says:
"The candidate configuration may be shared among multiple sessions."

and the section 8.3.5.2 says:
" When a client fails with outstanding changes to the candidate
configuration, recovery can be difficult.  To facilitate easy recovery,
any outstanding changes are discarded when the lock is released, whether
explicitly with the <unlock> operation or implicitly from session
failure."

Even though candidate may be shared, it's impossible that a session A
prepares a part of candidate configuration, taking advantage of the
locking mechanism, and later releases the lock (no commit) and shares
result's of its work with a session B that may want to complete the
candidate and perform <commit>. According to the RFC, as the result of the
<unlock> operation performed by session A, any outstanding changes must be
discarded when the lock is released. IMO, it's a serious limitation.

Another point, what does it mean "discarded?
1) the state of the <candidate> must be the same as before <lock>
2) resetting the candidate configuration with the content of the running
   configuration (like in <discard-changes> operation)

If the 2nd is true, that means that just only <lock/> and <unlock/>
operations on an empty candidate configuration, cause that after all the
candidate's content magically changes.

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 21:20:23 +0100 (CET)

Hi,

> discarded when the lock is released. IMO, it's a serious limitation.

Yes.  If you want the other behavior, you can use <partial-lock>.

>    configuration (like in <discard-changes> operation)

It means 2 (it should be clarified in 4741bis).

> candidate's content magically changes.

Yes.  This is only an issue if the box supports :candidate and
:writable-running.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 21:20:23 +0100 (CET)

Hi,

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 02 Dec 2008 11:14:10 +0100

> Yes.  If you want the other behavior, you can use <partial-lock>.

What is an advantage of such behavior. Could you explain usefulness of this?

> Yes.  This is only an issue if the box supports :candidate and

It's very illogical. Is it done on purpose or is kind of side effect? Lock and unlock operation should not have anything in common with copying
configuration. These operation should only allow or disallow editing the data.

One more thing. One session is able to forbid do a lock on candidate for another session simply by doing any change on candidate. That's also
very surprising. If a configuration is not locked any session should be able to do the changes on it.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 02 Dec 2008 11:14:10 +0100

Tomasz

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Dec 2008 13:37:48 -0500

Tomasz Mikolajczyk writes:
>It's very illogical. Is it done on purpose or is kind of side effect?

These questions all relate to the model with which locks are used.
The current NETCONF model is that there are two cases.  Either the
applications treat the datastore as "owned" by one client, where
only that clients is permitted to make changes, or the datastore
is open to all applications, and these appplications can make changes
at any time.

In the first model, the lock is used to prevent other applications
from changing the config while my application is changing it.  This
model lends itself to theFrom [email-masked]  Tue Dec  2 10:44:41 2008
To: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 2 Dec 2008 13:37:48 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

Tomasz Mikolajczyk writes:
>It's very illogical. Is it done on purpose or is kind of side effect?

These questions all relate to the model with which locks are used.
The current NETCONF model is that there are two cases.  Either the
applications treat the datastore as "owned" by one client, where
only that clients is permitted to make changes, or the datastore
is open to all applications, and these appplications can make changes
at any time.

In the first model, the lock is used to prevent other applications
from changing the config while my application is changing it.  This
model lends itself  candidate datastore, where I can make
changes, check them, record them, and/or commit them as my app sees
fit.  I can use the "confirmed commit" mechanism to ensure that my
change (and the box) are working well before releasing the lock to
allow other applications to make changes.  My changes can be logged
accurately and the responsibility for any errors can be placed at
the foot of my app.

The the second model, many applications can make changes to the
datastore without concern for their interactions.  This concern may
be addressed in out-of-band mechanisms, or could be the outcome of
the network management architecture in use by the network provider,
but no locking is needed.  This model works well with the running
datastore, where the config changes immediately affect the device
and the audit mechanism would be tailored to a single <edit-config>
payload.

Partial locking takes a hybrid approach, where the applications
aren't concerned with each other, but still want some measure of
assuredness that no one is changing the parts of the datastore the
app consider it's own.  One could view it as "trust but verify",
but IMHO it leaves the server open to long term locks that aren't
condusive to simple clients that want to perform simple operations
like "backup";  an app parked with a the partial lock prevents the
client from getting the global lock needed to be able to save the
complete config accurately.

Thanks,
 Phil

to the candidate datastore, where I can make
changes, check them, record them, and/or commit them as my app sees
fit.  I can use the "confirmed commit" mechanism to ensure that my
change (and the box) are working well before releasing the lock to
allow other applications to make changes.  My changes can be logged
accurately and the responsibility for any errors can be placed at
the foot of my app.

The the second model, many applications can make changes to the
datastore without concern for their interactions.  This concern may
be addressed in out-of-band mechanisms, or could be the outcome of
the network management architecture in use by the network provider,
but no locking is needed.  This model works well with the running
datastore, where the config changes immediately affect the device
and the audit mechanism would be tailored to a single <edit-config>
payload.

Partial locking takes a hybrid approach, where the applications
aren't concerned with each other, but still want some measure of
assuredness that no one is changing the parts of the datastore the
app consider it's own.  One could view it as "trust but verify",
but IMHO it leaves the server open to long term locks that aren't
condusive to simple clients that want to perform simple operations
like "backup";  an app parked with a the partial lock prevents the
client from getting the global lock needed to be able to save the
complete config accurately.

Thanks,
 Phil

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 04 Dec 2008 10:25:09 +0100

Phil Shafer wrote:
> model lends itself to the candidate datastore, where I can make

I clearly understand these cases.
However I still don't feel what is the purpose of the issues:
1) Lock must fail if "The target configuration is <candidate>, it has already been
   modified, and these changes have not been committed or rolled back"
2) As the result of the <unlock> operation performed by session A, any outstanding changes must be
   discarded when the lock is released

I can't find their advantages. The server shouldn't be wiser than a user. Server should do whatever user want to do.
No matter if the application (i.e. a client) knows that "owns" the datastore, or
there are simultaneously sessions that may be interested in the same datastore area,
a particular session should be able to do a lock anytime wants to (unless configuration is already locked).
Moreover, the session that owns the lock is responsible what is left in the config after unlock.
The session holding the lock is an active ruler and if wants to commit the candidate, executes commit explicitly.
If wants to leave the candidate the same as running, explicit copying must be performed.

What about a session timeout, I mean if the timeout occurs on a session owning the lock. Let's say Admin
was preparing a huge and complicated candidate all morning and went for a cup of coffee before commit.
In the meantime timeout occurred. According to the RFC, unlock must be released and running must be copied to candidate.
What if running contains hundreds of managed objects and thousands of their instances? Have you ever thought about performance?

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 04 Dec 2008 10:25:09 +0100

Tomasz

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2008 09:29:24 -0500

>   modified, and these changes have not been committed or rolled back"

The client application shouldn't need to understand what outstanding
changes are in the config.  If there are uncommitted changes, then
something's wrong and someone smarter than my app should be required
to do something.

>   discarded when the lock is released

If an application crashes or network connectivity iFrom [email-masked]  Thu Dec  4 06:37:37 2008
To: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 4 Dec 2008 09:29:24 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

>   modified, and these changes have not been committed or rolled back"

The client application shouldn't need to understand what outstanding
changes are in the config.  If there are uncommitted changes, then
something's wrong and someone smarter than my app should be required
to do something.

>   discarded when the lock is released

If an application crashes or network connectivity is losts lost, we
want the server to recover back to a known state.  Discarding
changes does this.  When the client reconnects, it can reacquire
the lock (which is possible since changes have been discarded),
and redo any changes needed.

>iguration is already locked).

Multiple sessions can be interested in the same datastore, but the
lock forces their write (edit and commit) operations to be performed
in series.

>If wants to leave the candidate the same as running, explicit copying must be 

But what we want to avoid is where the changes are left on the
candidate and the next client has no idea what's changed or
why, and can't decide what to do with them (commit or discard).

>was preparing a huge and complicated candidate all morning and went for a cup 

NETCONF locks are meant to be short-lived and are not designed
for applications that take coffee breaks.

>In the meantime timeout occurred. According to the RFC, unlock must be release
>d and running must be copied to candidate.
>What if running contains hundreds of managed objects and thousands of their in
>stances? Have you ever thought about performance?

"ever"?  Sure, once ;^)

But the more important issue is about allowing clients to perform
their changes without needing artificial intelligence (or wise humans)
to find their way.

(Are you really arguing for both performance and coffee breaks? ;^)

Thanks,
 Phil

, we
want the server to recover back to a known state.  Discarding
changes does this.  When the client reconnects, it can reacquire
the lock (which is possible since changes have been discarded),
and redo any changes needed.

>iguration is already locked).

Multiple sessions can be interested in the same datastore, but the
lock forces their write (edit and commit) operations to be performed
in series.

>If wants to leave the candidate the same as running, explicit copying must be 

But what we want to avoid is where the changes are left on the
candidate and the next client has no idea what's changed or
why, and can't decide what to do with them (commit or discard).

>was preparing a huge and complicated candidate all morning and went for a cup 

NETCONF locks are meant to be short-lived and are not designed
for applications that take coffee breaks.

>In the meantime timeout occurred. According to the RFC, unlock must be release
>d and running must be copied to candidate.
>What if running contains hundreds of managed objects and thousands of their in
>stances? Have you ever thought about performance?

"ever"?  Sure, once ;^)

But the more important issue is about allowing clients to perform
their changes without needing artificial intelligence (or wise humans)
to find their way.

(Are you really arguing for both performance and coffee breaks? ;^)

Thanks,
 Phil

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Thu, 4 Dec 2008 18:58:24 -0000 (GMT)

Phil Shafer wrote:
>>1) Lock must fail if "The target configuration is <candidate>, it has
>> already
>>been
>>2) As the result of the <unlock> operation performed by session A, any
>> outstan
>>ding changes must be
> If an application crashes or network connectivity is lost, we
>>No matter if the application (i.e. a client) kFrom [email-masked]  Thu Dec  4 10:58:35 2008
Date: Thu, 4 Dec 2008 18:58:24 -0000 (GMT)
From: "Tomasz Mikolajczyk" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

Phil Shafer wrote:
>>1) Lock must fail if "The target configuration is <candidate>, it has
>> already
>>been
>>2) As the result of the <unlock> operation performed by session A, any
>> outstan
>>ding changes must be
> If an application crashes or network connectivity is lost, we
>>No matter if the application (i.e. a clinows that "owns" the
>> datastore,
>>or
>>there are simultaneously sessions that may be interested in the same
>> datastore
>> area,
>>a particular session should be able to do a lock anytime wants to (unless
>> conf
>>iguration is already locked).
>

Yes, I agree. Lock and unlock are very important to unable other sessions
to do simultaneous changes.

>>If wants to leave the candidate the same as running, explicit copying
>> must be
>>performed.
>

I don't agree. I guess that the first operation that the next client would
execute after lock candidate is either delete-config on candidate, or
copy-config running->candidate to make sure that candidate doesn't contain
any unwanted data. It's very probable that the next session doesn't know
anything what was happening before, i.e whether data in candidate comes
from running as the result of the previous client's unlock, or are there
because the previous session made some changes in candidate without lock.
Even if the next session knows that the last session made unlock or
commit, shouldn't assume that candidate still corresponds to running as
running can change on its own. That means that such automatic reverting
candidate as the result of unlock is totally unnecessary.
So I still don't understand what these rules are introduced for.

>>What about a session timeout, I mean if the timeout occurs on a session
>> owning
>> the lock. Let's say Admin
>>was preparing a huge and complicated candidate all morning and went for a
>> cup
>>of coffee before commit.
>

RFC doesn't say anything about lock duration.

>>stances? Have you ever thought about performance?

And?

> (Are you really arguing for both performance and coffee breaks? ;^)

So you assume client performing automatically lock and unlock.

Tomasz

ent) knows that "owns" the
>> datastore,
>>or
>>there are simultaneously sessions that may be interested in the same
>> datastore
>> area,
>>a particular session should be able to do a lock anytime wants to (unless
>> conf
>>iguration is already locked).
>

Yes, I agree. Lock and unlock are very important to unable other sessions
to do simultaneous changes.

>>If wants to leave the candidate the same as running, explicit copying
>> must be
>>performed.
>

I don't agree. I guess that the first operation that the next client would
execute after lock candidate is either delete-config on candidate, or
copy-config running->candidate to make sure that candidate doesn't contain
any unwanted data. It's very probable that the next session doesn't know
anything what was happening before, i.e whether data in candidate comes
from running as the result of the previous client's unlock, or are there
because the previous session made some changes in candidate without lock.
Even if the next session knows that the last session made unlock or
commit, shouldn't assume that candidate still corresponds to running as
running can change on its own. That means that such automatic reverting
candidate as the result of unlock is totally unnecessary.
So I still don't understand what these rules are introduced for.

>>What about a session timeout, I mean if the timeout occurs on a session
>> owning
>> the lock. Let's say Admin
>>was preparing a huge and complicated candidate all morning and went for a
>> cup
>>of coffee before commit.
>

RFC doesn't say anything about lock duration.

>>stances? Have you ever thought about performance?

And?

> (Are you really arguing for both performance and coffee breaks? ;^)

So you assume client performing automatically lock and unlock.

Tomasz

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2008 15:03:18 -0500

"Tomasz Mikolajczyk" writes:
>any unwanted data.

If the changes are the result of a user sitting at the CLI, discarding
their changes is that very last thing you want to do.

>RFC doesn't say anything about lock duration.

7.5.  <lock>

   Description:

      The lock operation allows the client to lock the configuration
-->   system of a devicFrom [email-masked]  Thu Dec  4 12:12:34 2008
To: "Tomasz Mikolajczyk" <[email-masked]>
Date: Thu, 4 Dec 2008 15:03:18 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

"Tomasz Mikolajczyk" writes:
>any unwanted data.

If the changes are the result of a user sitting at the CLI, discarding
their changes is that very last thing you want to do.

>RFC doesn't say anything about lock duration.

7.5.  <lock>

   Description:

      The lock operation allows the client to lock the configuration
-->   system of a device.  Sue.  Such locks are intended to be short-lived and
      allow a client to make a change without fear of interaction with
      other NETCONF clients, non-NETCONF clients (e.g., SNMP and command
      line interface (CLI) scripts), and human users.

Thanks,
 Phil

ch locks are intended to be short-lived and
      allow a client to make a change without fear of interaction with
      other NETCONF clients, non-NETCONF clients (e.g., SNMP and command
      line interface (CLI) scripts), and human users.

Thanks,
 Phil

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 13:18:27 +0800

Hi,
> I can't find their advantages. The server shouldn't be wiser than 
> a user. Server should do whatever user want to do.
> a particular session should be able to do a lock anytime wants to 
> (unless configuration is already locked).
> The session holding the lock is an active ruler and if wants to 
> commit the candidate, executes commit explicitly.

A primary functionality of lock is to guarantee atomicity of a transaction or a series of operations, so unlock means either the transaction effect or not at all.
So IMHO, before <lock> candidate is the same as running, after <unlock> candidate is still same as running.

washam

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 13:18:27 +0800

Hi,

washam

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 08:31:01 +0100

> their changes is that very last thing you want to do.

What a difference if the other session doing modification for candidate without lock is
CLI session or NETCONF session? Why CLI session can't do lock if has access to candidate.
As I already described, it's the same when you do a lock on candidate and see data there. You are not sure
if these data come from running (previous session unlock) or are prepared by other sessions working without
lock (either CLI or NETCONF or whatever). If you can do a lock, do it and change whatever you want. It's another session
problem if their data disappears when they work without lock.

> -->   system of a device.  Such locks are intended to be short-lived and

Yes, You've right. I missed it.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 08:31:01 +0100

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 09:08:48 +0100

> So IMHO, before <lock> candidate is the same as running, after <unlock> candidate is still same as running.

I understand the purpose of lock and unlock. Atomicity guarantees that in transaction either all operations completely occur, or have no
effects. So that means that unlock should leave candidate configuration with the same state as before lock and not with the same state as
running. You can't be sure that before lock the state of candidate is the same of running. Consider the following scenario:

1) Session A starts:
1) [A] copy-config running->candidate
2) [A] series of edit-config on unlocked candidate (for example creates new interfaces, sets interfaces parameters)
3) Session B starts (session A still does changes on candidate)
4) [B] do a successful lock
5) [B] get-config on candidate. How B can be sure that the current candidate content is the same as running. Actually in this case candidate !=
running !!
6) [B] It can't be sure, so to make sure executes copy-config running->candidate. As is a lock holder doesn't care if other sessions uses
candidate or not
7) [B] series of edit-config
8) [B] unlock

What such unlock has in common with atomicity? See that after unlock state of candidate is completely different than before.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 09:08:48 +0100

1) Session A starts:

Tomasz

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 09:24:38 +0100

On Fri, Dec 05, 2008 at 09:08:48AM +0100, Tomasz Mikolajczyk wrote:
 
> What such unlock has in common with atomicity? See that after unlock
> state of candidate is completely different than before.

If you don't lock, you do not get any guarantees.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 09:24:38 +0100

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 09:49:43 +0100

> If you don't lock, you do not get any guarantees.

But the session [B] from the example did before any other operations.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 09:49:43 +0100

Tomasz

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 10:00:21 +0100

> But the session [B] from the example did before any other operations.

A lock means "nobody interferes with what you are doing as long as you
own the lock". A lock is a tool to implement an atomic transaction; it
is not an atomic transaction by itself. I find section 7.5 of RFC 4741
rather clear about what a lock does.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 10:00:21 +0100

/js

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 17:13:04 +0800

> > A primary functionality of lock is to guarantee atomicity of a 
> transaction or a series of operations, so unlock means either the 
> transaction effect or not at all.
> > So IMHO, before <lock> candidate is the same as running, after 
> <unlock> candidate is still same as running.
> > 
> > washam
> > 
> 
> I understand the purpose of lock and unlock. Atomicity guarantees 
> that in transaction either all operations completely occur, or 
> have no
> effects. So that means that unlock should leave candidate 
> configuration with the same state as before lock and not with the 
> same state as
> running. You can't be sure that before lock the state of candidate 
> is the same of running. Consider the following scenario:
> 
> 1) Session A starts:
> 2) [A] series of edit-config on unlocked candidate (for example 
> creates new interfaces, sets interfaces parameters)
> 5) [B] get-config on candidate. How B can be sure that the current 
> candidate content is the same as running. Actually in this case 
> candidate !=
> running !!
I am afraid [B] can't do a successful lock on a modified candidate datastore, which is one of the lock failure scenarios.
Well, partial lock allows it, I addressed the issue in thread "global vs. partial lock"

washam

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 17:13:04 +0800

washam

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 10:22:35 +0100

Juergen Schoenwaelder wrote:
> own the lock".

Yes, but you don't know the history, especially if the previous sessions did changes on candidate without lock/unlock
before your session using lock/unlock started. It means that those possible sessions don't interfere with what your session
is doing, because they may no longer exist.

> A lock is a tool to implement an atomic transaction; it
> is not an atomic transaction by itself. 

Yes, I agree. However, my scenario presented a few posts ago shows that unlock based on the current spec. can very easy break the atomicity.

I find section 7.5 of RFC 4741
> rather clear about what a lock does.

I agree sesion 7.5 is clear but 7.6. not. I mean unlock should be only unlock and not unlock and copy running->candidate.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 10:22:35 +0100

Tomasz

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 10:31:29 +0100

On Fri, Dec 05, 2008 at 10:22:35AM +0100, Tomasz Mikolajczyk wrote:
 
> Yes, I agree. However, my scenario presented a few posts ago shows
> that unlock based on the current spec. can very easy break the
> atomicity.

You might not like the unlock discard behaviour. That can be
debated. But claiming that unlock breaks atomicity is IMHO
non-sense. If a session does not lock candidate, anything can 
happen to the candidate datastore, including discard-config.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2008 10:31:29 +0100

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 11:14:18 +0100

> Well, partial lock allows it, I addressed the issue in thread "global vs. partial lock"

Yes, you've right. I forgot about this feature. So corrected version of the scenario:

1) Session A starts:
2) [A] get-config on running
3) [A] get-config on candidate (assumption: running==candidate)
4) someone removes manually interface from the device
5) [A] response get-config on running shows that one interface disappeared
6) Session B starts
7) [B] do a successful lock
8) [B] get-config on candidate. How B can be sure that the current candidate content is the same as running. Actually in this case candidate !=
running
9) [B] It can't be sure, so to make sure executes copy-config running->candidate. As is a lock holder doesn't care if other sessions uses
candidate or not
10) [B] series of edit-config
11) [B] unlock

As the unlock part, copy-config running->candidate is performed, and as a result candidate content before lock != candidate content after lock.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 11:14:18 +0100

1) Session A starts:

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 11:19:21 +0100

Juergen Schoenwaelder wrote:
> non-sense.

Yes, you've right. We cannot talking about atomicity. It's even not a transaction.

If a session does not lock candidate, anything can
> happen to the candidate datastore, including discard-config.

I absolutely agree. No matter if it's CLI session or NETCONF session.

Another point. If unlock means also copying running->candidate it means that for any reasons unlock may fail. What's then?
I expect that unlock must be successful. So does the unlock means copy running->candidate as much as you can?

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 05 Dec 2008 11:19:21 +0100

Tomasz

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 22:35:10 +0800

> 5) [A] response get-config on running shows that one interface 
> disappeared6) Session B starts
> 8) [B] get-config on candidate. How B can be sure that the current 

Do you mean candidate still keep the data about removed interface?
I don't know what impact this kind of inconsistency would have, but any change on the interface would make no sense to running.

> 9) [B] It can't be sure, so to make sure executes copy-config 
> running->candidate. As is a lock holder doesn't care if other 
> sessions uses
> candidate or not
> 11) [B]From [email-masked]  Fri Dec  5 06:35:19 2008
Date: Fri, 05 Dec 2008 22:35:10 +0800
From: Washam Fan <[email-masked]>
To: Tomasz Mikolajczyk <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

> 5) [A] response get-config on running shows that one interface 
> disappeared6) Session B starts
> 8) [B] get-config on candidate. How B can be sure that the current 

Do you mean candidate still keep the data about removed interface?
I don't know what impact this kind of inconsistency would have, but any change on the interface would make no sense to running.

> 9) [B] It can't be sure, so to make sure executes copy-config 
> running->candidate. As is a lock holder doesn't care if other 
> sessions uses
> candidate or not
> 11) [B] unloc unlock

You didn't commit, so unlock means discard all the changes on candidate which has the same effect as copy-config running->candidate.

> As the unlock part, copy-config running->candidate is performed, 
> and as a result candidate content before lock != candidate content 
> after lock.
That's OK.IMHO, candidate should be synchronized with running at every failed <commit> or every <unlock>, candidate should be a mirror of running.

washam

k

You didn't commit, so unlock means discard all the changes on candidate which has the same effect as copy-config running->candidate.

> As the unlock part, copy-config running->candidate is performed, 
> and as a result candidate content before lock != candidate content 
> after lock.
That's OK.IMHO, candidate should be synchronized with running at every failed <commit> or every <unlock>, candidate should be a mirror of running.

washam

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 22:40:38 +0800

> Another point. If unlock means also copying running->candidate it 
> means that for any reasons unlock may fail. What's then?
> I expect that unlock must be successful. So does the unlock means 
> copy running->candidate as much as you can?

Failed commit means copying running->candidate,too. When users edit-config candidate, they think all the changes they've made on candidate would take effect on running eventually. A inconsistency candidate make no sense, IMHO.

washam

---

From: Washam Fan <[email-masked]>
Date: Fri, 05 Dec 2008 22:40:38 +0800

washam

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 08 Dec 2008 14:43:08 +0100

Hello,
IMHO the length of this discussion alone indicates to me, that it is not trivial to understand 
the lock functionality. (As I remember, Tomasz is not the first one who had 
questions/reservations about the side effects of lock.)
This is the reason why partial-lock does no less and no more then what its name indicates: 
"Lock part of the datastore". I think that is simple to understand.
Balazs

Washam Fan wrote:
>> means that for any reasons unlock may fail. WhatFrom [email-masked]  Mon Dec  8 05:43:18 2008
Date: Mon, 08 Dec 2008 14:43:08 +0100
From: Balazs Lengyel <[email-masked]>
To: [email-masked]
Subject: Re: [Netconf] lock/unlock on candidate
Sender: [email-masked]

Hello,
IMHO the length of this discussion alone indicates to me, that it is not trivial to understand 
the lock functionality. (As I remember, Tomasz is not the first one who had 
questions/reservations about the side effects of lock.)
This is the reason why partial-lock does no less and no more then what its name indicates: 
"Lock part of the datastore". I think that is simple to understand.
Balazs

Washam Fan wrote:
>> means that for any reasons unlock may fail. What's the's then?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

n?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Mon, 08 Dec 2008 15:07:55 +0100

Balazs Lengyel wrote:
> Hello,
> IMHO the length of this discussion alone indicates to me, that it is not
> trivial to understand the lock functionality. (As I remember, Tomasz is
> not the first one who had questions/reservations about the side effects
> of lock.)
> This is the reason why partial-lock does no less and no more then what
> its name indicates: "Lock part of the datastore". I think that is simple
> to understand.
> Balazs

But introducing new functionalities will not help when the foundations are not enough strong.

>> Failed commit means copying running->candidate,too. When users
>> edit-config candidate, they think all the changes they've made on
>> candidate would take effect on running eventually. A inconsistency
>> candidate make no sense, IMHO.
>>
>> washam

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Mon, 08 Dec 2008 15:07:55 +0100

Tomasz

---

From: Phil Shafer <[email-masked]>
Date: Mon, 8 Dec 2008 09:55:40 -0500

>"Lock part of the datastore". I think that is simple to understand.

The statement is simple, but the implications are the source
of the issues.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 8 Dec 2008 09:55:40 -0500

Thanks,
 Phil