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 -----
*From:* David B Harrington <mailto:dbharrington at comcast.net>
*To:* 'Bert Wijnen (IETF)' <mailto:bertietf at bwijnen.net> ;
netconf at ietf.org <mailto:netconf at ietf.org>
*Cc:* 'Ron Bonica' <mailto:rbonica at juniper.net>
*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
------------------------------------------------------------------------
*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
------------------------------------------------------------------------
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
------------------------------------------------------------------------
_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf
