|
I really believe that we have worked hard on this document and
that it deserves publication.
With the Warning that Balazs added, people can understand what
the issues are and
act accordingly.
If we want t o add partial-commit and/or multiple
candidate-configs, then that is fine.
I am looking forward to Internet-Drafts that make a first pass
at describing such functions
after which we can discuss if we need a charter update for
that (assuming we have enough
WG members to work on such a document).
Bert
partial-lock document shepherd and WG co-chair
----- Original Message -----
Sent: Wednesday, June 03, 2009 6:54
PM
Subject: RE: [Netconf] New
draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
Hi,
I think there is a real problem that exists, and Balaz's
reasoning effectively says "let's just ignore the conflict with access
control; then we can make believe the problem does not exist." This does not
make the problem go away.
The problem is that the scope of the lock and the scope
of the commit are different.
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
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 -----
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
No virus found in this incoming message.
Checked by AVG -
www.avg.com
Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release
Date: 06/03/09 05:53:00
|
