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