I believe that for partial lock on candidiate to work, you need a
corresponding partial commit.
This could be handled using an explicit command for partial commit.
It could be handled by allowing multiple candidiates, each containing a
partial config that is specified as a parameter to the partial lock (or
to a partial-copy-config), with what is effectively a global lock of the
partial config and a global commit of that partial config.
The lock and the commit need to match scope. If they do not match, you
will have problems.
If the WG chooses to not have a partial commit that corresponds to the
partial lock, or multiple candidiate sandboxes that can allow an
operator to independently lock, edit, and commit a partial config,
then I think the partial lock for candidate should be removed.
That is not my preferred solution, because I believe operators will need
to lock and modify and commit partial configs, but removing the partial
lock from candidiate is probably the easiest for now.
dbh
------------------------------------------------------------------------
*From:* netconf-bounces at ietf.org [mailto:netconf-bounces at ietf.org]
*On Behalf Of *Bert Wijnen (IETF)
*Sent:* Wednesday, June 03, 2009 7:29 AM
*To:* netconf at ietf.org
*Cc:* Ron Bonica
*Subject:* [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes
to AD andIETF Last Call
WG particpants,
Unfortunately, not too many people have given a clear statement of
their
opinion on the question if they could accept Balazs' reasoning
w.r.t. the
partial lock issues (see below).
But, based on the comments received, We (WG chairs) have asked
Balazs to do a new rev that explains as much as possible what can
and cannot be done and what impacts it has?
Balazs has now done so and
revision draft-ietf-netconf-partial-lock-08.txt
is now available. Revision 7 was already handed to our AD for review
and IETF Last Call, and we believe that this new revision addresses
(or at least explains) the last issues that came up before our AD could
do an IETF LC for rev 07.
We have asked Dan (our AD) to pick up revision 08 for IETF Last Call.
I assume all WG members are now OK with this revision. We have
(in the WG chairs views) consensus (at least rough) consensus.
If anyone still has concerns, you can always post them to our NETCONF
mailing list and.or raise them during IETF Last Call.
Thanks you all.
Bert and Mehmet
----- Original Message -----
*From:* Bert Wijnen (IETF)
*To:* Balazs Lengyel ; netconf mailing list
*Sent:* Tuesday, May 19, 2009 8:51 PM
*Subject:* Re: [Netconf] Partial-lock issues
Thanks Balazs for summarizing.
I believe I (as a technical contributer) can accept your reasoning.
Speaking as document shepherd and WG co-chair I would like to
urge all WG members to state their opinion (or comments) as well.
Bert
----- Original Message -----
*From:* Balazs Lengyel
*To:* netconf mailing list
*Sent:* Tuesday, May 19, 2009 12:01 PM
*Subject:* [Netconf] Partial-lock issues
Hello,
Some people brought it up that partial-locking without partial
commit is not a good solution as
it can lead to dead-locks. For one last time I try to list the
reasons why we included candidate.
Please state if you can accept the reasoning below or whether
you think we should allow
partial-locking ONLY for the running configuration?
1) As Washam pointed out just by having access control and
without using any locks we face a
dead-lock problems:
- A only has access to /foo, and edits it in candidate
- B only has access to /bar, and edits it in candidate
- A terminates it's session
- Now B can not issue <discard-changes> because it can not
modify /foo in the candidate
- B can not issue <commit> because it can not modify /foo in the
running
If A and/or B uses partial-locking that will NOT make this
situation WORSE, as the lock is
automatically released at the end of the session. The real
problem is caused by access control.
2) When partial-locking is used correctly, there is no danger of
dead-lock, and locking does
help to protect the individual operator's activities. (In the
next sequence we presume access
control will not block any of the actions.)
- Operator A locks everything it needs both in candidate and
running in one operation e.g. /foo
- A edits the locked part in the candidate
- A issues commit, if this fails due to lock conflicts, it
simply releases the lock, and let's
any concurrent operator (e.g. B) work on candidate; B will later
commit changes done by A as
well. Lock conflicts can include operator B locking /bar in the
running configuration
- Operator B works the same way on another area e.g. /bar
- The operator that finishes editing last will successfully
commit all changes to running (by
this time there are no other locks)
3) Later we might introduce partial commit, in which case
partial-locking would be very much
needed/useful
4) Partial-locking does no evil
5) It is nice to have the feature available on all three datastores
So we propose to keep partial-locking on candidate, but as this
is only secondary use-case if
the workgroup decides it can be removed.
This question has already been raised a number of times, so we
would like to establish the
workgroup
consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING
ON CANDIDATE SHOULD STAY OR
SHOULD BE REMOVED !!!!
Balazs
------------------------------------------------------------------------
_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf
