Subject: [Netconf] Fw: Database Architecture OK or NOT-OK?

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 2 Aug 2009 22:58:09 +0200

> Hi,
>
> You have taken a comment out of context, and have not identified the 
> original email where Andy made this remark.
> Can you identify the original message so readers can see what Andy had to 
> say?
>
> dbh

See the bottom of the following post from Andy:

----- Original Message ----- 
From: Andy Bierman
To: Martin Bjorklund
Cc: [email-masked]
Sent: Saturday, July 25, 2009 5:59 PM
Subject: Re: [Netconf] Comments :draft-ietf-netconf-4741bis-01.txt

Martin Bjorklund wrote:
> Phil Shafer <[email-masked]> wrote:
>> Martin Bjorklund writes:
>>> RFC 4741 says:
>>>  Delete a configuration datastore.
>> This makes little sense.  What does it mean to delete <running>?
>
> According to 4741, running cannot be deleted.
>

good!

I find the <copy-config> and <delete-config> operations
to be the absolute worst part of NETCONF.

It is obvious from studying the protocol that there was no
clear or shared understanding of the database architecture.
Now with partial-locking, it is even worse.

   * every agent MUST have a <running> database
   * every agent MUST have exactly 1 database that can
     be the target of an <edit-config> operation.
     (Writing to both <candidate> and <running> does not work!)
      * therefore the agent MUST support the :candidate OR
        :writable-running capabilities, but not both)
   * the :candidate and :startup capabilities are independent,
     not mutually exclusive.

(Is there any agreement on these points?)

I changed my mind on 'minimal <startup> operations'.
I think <get-config> and <validate> on the "NV version"
are too useful for operators to leave as optional.
So the table in 4741bis, 8.7.5.1 is OK

I do not like all the combinations for <copy-config>
that occur when :candidate and :startup are both supported.
Or for that matter, just :candidate.

8.3.5.1.  <get-config>, <edit-config>, <copy-config>, and <validate>

   The candidate configuration can be used as a source or target of any
   <get-config>, <edit-config>, <copy-config>, or <validate> operation
   as a <source> or <target> parameter.  The <candidate> element is used
   to indicate the candidate configuration:

This first sentence is clearly wrong.
You cannot copy from candidate to running.
You can only use <commit> for that.
(Not sure about copy from candidate to startup.)
You should not be able to copy from running to candidate either.
We have <discard-changes> for that.

I wish we had time to work on the NETCONF database architecture,
because it isn't very good.

> /martin

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Aug 2009 22:22:03 +0200

> You can only use <commit> for that.

Is this stated somewhere or would a copy-config from candidate to
running just be the same as a commit?

> We have <discard-changes> for that.

Would a copy-config from running to candidate do exactly what
discard-changes does? My question is whether we simply have redundant
operations or if we have a problem with similar but slightly different
semantics?

I personally find copy-config('candidate', 'runnning') nicer than
discard-changes() since it tells me which datastores are actually
involved - but that might be a matter of personal preference. If both
achieve the same effect, lets just state it explicitely and then
script writers can choose what they prefer.

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 Aug 2009 16:33:15 -0700

> running just be the same as a commit?

It should be stated that they are equivalent.

> operations or if we have a problem with similar but slightly different

yes -- that is what at least 2 implementations do.

> discard-changes() 

copy from running to candidate --> discard-changes
copy from candidate to running --> commit

commit has extra parameters for confirmed commit.

a copy-config does not count as the 2nd commit
in a confirmed-commit.  Not sure what happens to
the confirmed commit in progress if running
is touched via copy-config.

IMO, :candidate and :writable-running do not work
together.  They almost work together, and only go horribly wrong
sometimes.  If that's good enough for the NETCONF
database architecture, then I guess there is nothing to fix.

since it tells me which datastores are actually

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 11:56:39 +0200

> database architecture, then I guess there is nothing to fix.

The case where a running timed commit interferes with an
edit-config('running', ...) can probably be fixed by letting any
attempts to change running fail while a commit is in
progress.

Are there other things that can go horribly wrong?

/js

---

From: WashamFan <[email-masked]>
Date: Tue, 04 Aug 2009 18:39:16 +0800

Hi,

----- Original Message -----
From: Juergen Schoenwaelder <[email-masked]>
Date: Tuesday, August 4, 2009 5:56 pm
Subject: Re: [Netconf] Fw:  Database Architecture OK or NOT-OK?
To: Andy Bierman <[email-masked]>
Cc: Netconf <[email-masked]>

>  attempts to change running fail while a commit is in

But changes are allowed before comfirming commit.

washam

>  Fax:   +49 421 200 3103         <
>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 13:45:26 +0200

> But changes are allowed before comfirming commit.

I guess so, although such changes will be purged by the commit
operation, unless the commit fails and there is an automatic
rollback. The point is I think to disallow changes you can't 
rollback to if the commit fails.

/js

---

From: WashamFan <[email-masked]>
Date: Tue, 04 Aug 2009 20:25:52 +0800

Hi,
  
>  rollback to if the commit fails.

That depends on how you see the changes between commits. If you
consider these changes as an additional part of previous undone changes,
then they can be rollbacked.

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 14:44:20 +0200

> then they can be rollbacked.

Not sure I understand your point.

My model is that the start of a commit() defines the running
configuration you roll back to if the commit fails. If this model is
right, then any further changes to the running configuration after the
start of the commit() will be lost - either because the commit
succeeds or there is a rollback.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 07:35:32 -0700

> Are there other things that can go horribly wrong?

I've already pointed them out at least twice.

I'm never going to support this combo, so I don't
care anymore.  Use locking or get what get.

It is interesting that just a lock on candidate
will prevent any changes to :writable-running though.
The candidate has to stay in synch with running.
If the agent cannot copy the new changes to running
into candidate because candidate is locked,
the agent must not allow running to be edited.
Not sure the draft is clear on this point.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 16:48:38 +0200

> The candidate has to stay in synch with running.

Why is this the case?

> Not sure the draft is clear on this point.

It is not clear to me why changes to running can't happen while
candidate is locked. It is probably not terribly useful but it is
unclear why it must be forbidden. Can you explain?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 08:06:54 -0700

>> The candidate has to stay in synch with running.

if it does not, then when a commit is done,
the recent changes to running will be lost
because they are not in the candidate.
The agent will interpret the missing node in
candidate as a deletion in running.

> unclear why it must be forbidden. Can you explain?

Fine.  It should be allowed.
The changes will be undone by a commit,
but garbage-in/garbage-out happens sometimes,
and this is one of them.

Also, the draft never specifies the initial contents of the
candidate (IMO, sloppy).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 20:41:36 +0200

> candidate as a deletion in running.

I am fine accepting this behaviour.

What I find more interesting is the question whether a well behaved
manager can try to avoid this situation, e.g. by locking running and
candidate. Can I commit() the candidate while I own the lock for
running? That is, can I do this:

    lock('running')
    discard-changes()
    lock('candidate')
    edit-config('candidate', ...)
    commit()
    unlock('candidate')
    unlock('running')

<rant>
I still find it surprising that I have to do the discard-changes()
before lock('candidate') but Phil strongly believes that failing
lock('candidate') if 'candidate' != 'running' is the correct way of
doing things.
</rant>

> Also, the draft never specifies the initial contents of the

Can you suggest words that should be there? 

I would probably issue a discard-changes() whenever I want to use
'candidate' so I can be sure what its contents is. And since
discard-changes() and lock('candidate') are not atomic, the real code
likely becomes this:

    lock('running')
    do {
      discard-changes()
      lock('candidate')
    } until lock-aquired
    edit-config('candidate', ...)
    commit()
    unlock('candidate')
    unlock('running')

But I already wrote a <rant/> about this...

/js

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 04 Aug 2009 21:22:14 +0200

>     edit-config('candidate', ...)

would you not rather first get the lock on candidate before you do a 
discard-changes ??
otherwise someone else might still change the candidate in between your 
discard-changes and lock, no?

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 2009 23:14:49 +0200

> discard-changes and lock, no?

The NETCONF RFC says that lock('candidate') fails if 'candidate' is
dirty. So you have to clean 'candidate' before you can get the lock
and since discarding changes and locking is not atomic, you get a loop
like above.

Also note that unlock('candidate') reverts candidate back to 'running'
- but I have less an issue with that (although I probably would not
have designed things this way myself).

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 14:21:58 -0700

> have designed things this way myself).

Not in my code.
I don't see that anywhere in sec. 7.6.
Losing the lock via session termination doesn't even
revert the candidate.  This is 1 reason why the candidate
may be dirty in the first place.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 14:37:38 -0700

....
> and since discarding changes and locking is not atomic, you get a loop

Note that the agent MUST send the session-id of the
lock-holder (lock-denied error-tag), but in this case,
there is no lock holder.

Is the agent supposed to send session-id=0 in this case?
That will look like SNMP or CLI has the lock.

It is possible an operator may not have read the 1 sentence buried in
a 120 page document that explains why this is happening,
and have no idea that <discard-changes> is the only thing
that will fix it.

(I agree with you about using copy-config instead
of discard-changes.  I never bought the argument
that the candidate was so special it needed its
own set of operations.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 Aug 2009 14:45:08 -0700

...
> and since discarding changes and locking is not atomic, you get a loop

Can we change this in 4741bis?
Why is the candidate so special?
I don't get it at all.

If the user doesn't use locking,
then too bad, so sad.  Somebody
else can just discard your changes
without any lock, so what is the point of
preventing a lock once you have touched the candidate somehow?

The loop should go away.
The lock should succeed on candidate, unless it is
currently locked.  Then the discard-changes
command could go after the lock was granted,
and there would be no confusion wrt/ lock-denied yet no session
is holding the lock.

Andy

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 16:03:47 +0800

Hi,

>  succeeds or there is a rollback.

Sorry, I misunderstood. I thought the changes via candidate, but you
meant the changes via running. That is different.

washam

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 17:40:15 +0800

Hi,

>  >  succeeds or there is a rollback.

Even use your model, why changes are lost when commit succeeds?
When do those changes come? in the processing of <commit> or between
confirmed commit and confirming commit?

washam

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 17:58:01 +0800

Hi,

>  have designed things this way myself).

If changes to running are allowed when candidate is locked, then how to
deal with changes coming in between <commit> and <unlock>. That might
be the reason why some people add syncing to unlock.

washam

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 17:59:45 +0800

>  That will look like SNMP or CLI has the lock.

session-id makes no sense in above case, since no one has the lock.
I don't think we need session-id field in this case.

washam

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 18:10:21 +0800

Hi,

>  Why is the candidate so special?

Are you saying to remove the belowing criterion for identifying a invalid lock:

         The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.

>  preventing a lock once you have touched the candidate somehow?

use a (global) lock when you see potential interruption. otherwise no lock
used in a controllable enviroment. It is up to you.

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 13:10:41 +0200

> may be dirty in the first place.

Check out section 8.3.5.2. - :candidate adds special behaviour
to lock operations.

   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.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 13:13:29 +0200

> and there would be no confusion wrt/ lock-denied yet no session

This was the code I originally wrote until I was made aware that
lock()/unlock() semantics are special for 'candidate' and since
you were also not really aware of this, we have at least two cases
where people were caught by a surprise (and I might count Bert's
email as an indication of a 3rd case of surprise).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 13:17:37 +0200

> be the reason why some people add syncing to unlock.

My understanding is that unlock() does an implicit discard-changes()
or copy-config('candidate', 'running') - so I do not understand your
question. My concern really is that :candidate adds semantics to
lock()/unlock() that are subtle and it remains unclear to me why they
are needed - perhaps Phil can try to explain this again.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 06:02:58 -0700

> email as an indication of a 3rd case of surprise).

I should not be surprised.
I should have guessed, because for candidate,
the least likely behavior is probably how it works.

Good to know if you mistakenly ^C out of a program,
that NETCONF's got your back by blowing away any
changes to candidate you obviously don't want anymore.
Oh, you did want to keep those edits?   Too bad.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 06:21:01 -0700

> I don't think we need session-id field in this case.

You are right:

pg 51:

      If the lock is already held, the <error-tag> element will be
      'lock-denied' and the <error-info> element will include the
      <session-id> of the lock owner.

Section 7.6 never says what error-tag to send
if the lock cannot be granted because the candidate
is dirty.  Section 8.3.5 should be the place
where this is specified, but it isn't.

So the situation is even worse than I thought:
When the candidate is dirty, an unspecified error
that will certainly be implemented differently on every
agent is used to identity the problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 16:34:34 +0200

> agent is used to identity the problem.

And it is even more unclear what 'no dirty candidate rule' in section
7.5 tries to achieve if you have :writable running if I do this:

    discard-changes()
    edit-config('running', bla bla)
    lock('candidate')

Since I did not touch 'candidate', the lock should be granted
according to this text:

      *  The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.

In this case, the content of 'candidate' is not the same as 'running'
either and I might be able to construct the very same situation by
doing this

    discard-changes()
    edit-config('candidate', inverse of bla bla)
    lock('candidate')

and this time the lock fails. Once again, I like to see someone here
explain why things were done in this way.

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 05 Aug 2009 17:00:45 +0200

Hi,

I brought this lock issue up over a half year ago. Here is that thread:
http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html

Regards,
Tomasz Mikolajczyk

> explain why things were done in this way.

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 08:10:01 -0700

> Since I did not touch 'candidate', the lock should be granted

s/should/should not/

> explain why things were done in this way.

indeed.
I just changed my code to comply with this CLR.
I would rather lose the CLR.

For the dirty-lock error, let's spin the wheel
(in-use, resource-denied, operation-failed...)
how about resource-denied, since in-use is
for a write-op to a locked database?

(I need to update the issue tracker anyway...)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Aug 2009 23:03:33 +0200

> http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html

Thanks for the pointer. It would really be nice to have an explanation
why the current behaviour is there and useful.

/js

---

From: Phil Shafer <[email-masked]>
Date: Sun, 9 Aug 2009 00:52:27 -0400

>unclear why it must be forbidden. Can you explain?

Because it makes locking candidate pointless.  The model is:

lock candidate
make change
commit change
unlock candidate

This sequence should ensure that my changes are applied
atomically and in isolation to the device.  If someone
can change running while I've locked candidate, then
I can't commit without trashing those changes.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 9 Aug 2009 00:57:57 -0400

>lock('candidate') if 'candidate' != 'running' is the correct way of

I strongly believe that you should not do a discard-changes before
locking, since this means you may be discard changes that have not
been discarded or committed.  If someone has outstanding changes
to the database but did not lock it, then you know that either (a)
someone crazy is playing with your config, or (b) something very
wrong has happened.  Blowing away the changes and plowing ahead
isn't the proper action for either case.

I also strongly believe that allowing a lock while these
outstanding changes exist is very bad.

Thanks,
 Phil

---

From: WashamFan <[email-masked]>
Date: Sun, 09 Aug 2009 16:13:46 +0800

> isn't the proper action for either case.

So what should be done when I want to lock the "dirty" candidate config?

> outstanding changes exist is very bad.

That is also what the current text believes. It says you can not
grab a lock on "dirty" candidate.

washam

---

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Aug 2009 07:01:03 -0700

> Because it makes locking candidate pointless.  The model is:

This needs to be resolved.
The <commit> operation clearly alters the running config
so a lock on running will block it.

It is not clear that a lock on candidate blocks <commit>.
It clearly blocks the operations that write to candidate.
It is not clear that <commit> writes to candidate.  It does not.
The <commit> operation is supposed to
leave the candidate untouched, so why does the lock
on candidate affect <commit>?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2009 22:54:32 +0200

> outstanding changes exist is very bad.

I do not see how this works with writeable-running. See this sequence
with three sessions S1-S3:

   S1:  ...
   S1:  discard-changes()
   S1:  close-session()

   S2:  lock(running)
   S2:  edit-config(running, ...)
   S2:  unlock(running)

   S3:  lock(candidate)
   S3:  edit-config(candidate, ...)
   S3:  commit()
   S3:  unlock(candidate)

Do you blow away changes that were made to running? Or would an
implementation have to detect that candidate is dirty due to changes
made to running? Since candidate is a shared buffer, how can I every
use discard-changes() in a save way without having a proper lock?

RFC 4741 discusses in section 8.3.1 that candidate is a buffer shared
among multiple sessions and it gives the following advise: "It is
therefore prudent for a client to lock the candidate configuration
before modifying it."

You seem to want to protect applications that do not use locks
properly and I wonder how this is ever going to work. Each invocation
of discard-changes() simply discards all changes and I can never be
sure that I really know what the change set is I discard - unless I
use locks. So for me, any invocation of discard-changes() outside a
lock is broken - whatever your intentions are. But then I am not
allowed to obtain locks in certain situations and you do not want me
to use discard-changes() either. In other words, a session that causes
candidate to be dirty (and see above that it is not clear what dirty
means with :writable-running) and goes away will cause all other well
written applications to stop working.

Concrete question to you: Does the Junos CLI use locks or only when
specifically asked to use locks?

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Mon, 10 Aug 2009 09:19:58 +0200

Hi,

Phil Shafer wrote:
> atomically and in isolation to the device.  

I don't agree. That's not guarantee atomicity! What if a management 
system losses a connection with a managed device in the middle of 
commit? Management system (NETCONF agent) cannot guarantee atomicity on 
its own. Device must support atomic operations and transactions.

Regards,
Tomasz Mikolajczyk

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 09:36:10 -0400

Tomasz Mikolajczyk writes:
>commit?

Regardless of the connection, the commit operation on the device
must be atomic, either succeeding or failing completely.  A
failed connection should not leave the device with a 1/2 committed
config.

>Management system (NETCONF agent) cannot guarantee atomicity on 
>its own.

"Management system" != "NETCONF agent", right?  Oh, you mean the
on-the-box mgmt software?  Either way:

>Device must support atomic operations and transactions.

Absolutely.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 10:00:12 -0400

Juergen Schoenwaelder writes:
>Do you blow away changes that were made to running?

I don't support :writable-running, just :candidate, and the
interaction between the two isn't clear.  Martin, how does
this work on your sw?

>Since candidate is a shared buffer, how can I every

If there are outstanding changes, the software client cannot
make any serious assumption about their nature, so choosing
to blow them away is something best left to a human.

>properly and I wonder how this is ever going to work.

I don't see it this way.  I want to protect applications that are
using locks in a responsible manner from dangerous interactions
with other sources of configuration that are not behaving well.

>In other words, a session that causes

Exactly.  An client (human or sw) that leaves (or keeps) the box
in an undefined state is not a suitation that a non-ai piece of
software can reasonable resolve.  Send an alarm and let something
smarter resolve it.

>specifically asked to use locks?

The candidate config in JUNOS is shared between all CLI users, and
locks are not mandatory.  The "configure" command enters configuration
mode, and the "configure exclusive" command grabs the lock before
entering configuration mode.  These same "dirty" rules apply.

For three people working together to solve a, say, bgp policy problem,
using the shared workspace works well.  But in the interaction between
humans and applications means, the human should always win.

Hmmmm, the three laws of management applications:
(1) An automation may not break human configuration
or, through action or inaction, allow human configuration
to be broken.
(2) An automation must try to get it's job done, except
where such attempts would conflict with the First Law.
(3) An automation must protect its own existence, by
applying the First and Second Laws in a way that does
not tempt the human to turn it off.

I, Config?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Aug 2009 12:39:29 +0200 (CEST)

> interaction between the two isn't clear.  Martin, how does

There is no magic going on just beacuse the box is configured to use
both :candidate and :writable-running.  Each operation behaves the
same regardless of the other capabilites.  So <discard-changes> resets
candidate to the contents of running, and <commit> replaces running
with the contents of candidate.

I agree that it is a burden on the client software to support all
different combinations of (startup, writable-running, candidate), and
a server developer that has a choice should carefully consider which
combination to implement.

When both :candidate and :writable-running are advertised, a client
that wants to use the candidate (maybe in order to use a confirmed
commit), should do:

  do {
    lock(running)
    discard-changes() 
    lock(candidate)
  } until candidate is locked
  edit-config(candidate, ...)
  commit()

Or, as was discussed before, don't do the loop and fail if the lock on
candidate cannot be acquired.

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Aug 2009 07:47:41 -0700

>>>>> On Wed, 05 Aug 2009 17:00:45 +0200, Tomasz Mikolajczyk <[email-masked]> said:

TM> I brought this lock issue up over a half year ago. Here is that thread:
TM> http://www.ietf.org/mail-archive/web/netconf/current/msg03992.html

Going back further you'll find I gave a whole presentation in San Diego
about the issues surrounding the fact that we expect to have multiple
potential editors operating on unique databases but the operation to
move data from one (candidate) to another (running) is a complete copy.
This is in no way a good design if multiple managers are involved (and
has security ramifications if the managers don't have global access
rights).

The netconf databases are designed to be used by a single manager with
absolute control or else all sort of things start to "pop up" like this.

In real life no one does "cp /dev/disk1 /dev/disk2" in order to copy
a subset of stuff from one storage system to another.

The discussion, reading it a bit late, sure makes it look like a
netconf-bis that completely replaces the original would be a good thing
at this point.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Aug 2009 17:44:01 +0200

> to blow them away is something best left to a human.

So discard-changes() is only for situations where I have a lock or for
humans? If this is so, I think this should be spelled out - otherwise
I am sure someone will write an application that calls
discard-changes() in order to acquire a lock...
 
> software can reasonable resolve.  Send an alarm and let something

But let me recap:

1) This behave well idea only works if all applications follow the
   same idea of responsible behaviour - so this needs to be documented
   somewhere since otherwise someone like me writes an application
   that simply calls discard-changes.

2) The candidate design does not work with :writeable-running unless
   we find a more precise definition how to determine whether
   candidate is in a "good shape" or not.

> not tempt the human to turn it off.

I might agree to the laws but I am not sure I agree that the current
special semantics we have generally work. They might be working for
the Junos combination of capabilities and applications written in the
Junos spirit - where unlocked usage of candidate is strictly for
humans. I am not sure this works in the wild with all the other legal
combinations of capabilities we have and that people will have to
write management applications for.

/js

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 13 Aug 2009 11:46:45 +0200

Hi,

> netconf-bis that completely replaces the original would be a good thing

+1
Starting from the scratch would be the best IMHO. New features are being 
added to the protocol, while the concept doesn't stand the pressure.

Regards,
Tomasz Mikolajczyk

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2009 07:35:03 -0700

> added to the protocol, while the concept doesn't stand the pressure.

This is a fairly content-free comment.

While I do not think partial-locking applies to
any database but <running>, I do not agree that
the whole protocol needs to be scrapped.

My comment about protocol versions was about too many
little optional features.  It would require a new protocol
version number to change optional bits to mandatory.

I pointed out 6 years ago that optional 'manual' database locking
was a really stupid choice.  Others also tried to steer NETCONF
towards a <begin-transaction> ... <end-transaction> model,
but some people insisted that database locking should be
optional to use.

Some people insist that informing every possible database user by email
to stay out of the candidate config for awhile is some form
of locking.  They call it "cooperative locking".

Why would starting over produce a better design outcome this time?
What evidence is there that the NETCONF WG has any competence in
this area at all?  IMO, this major disruption in the standard
will not yield any better results -- it will just waste time.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Aug 2009 12:16:02 -0400

>of locking.  They call it "cooperative locking".

I don't recall this point or these people.  Do you have a reference?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Aug 2009 10:27:26 -0700

> I don't recall this point or these people.  Do you have a reference?

2.1.1.3.  Multiple managers handling the candidate datastore in a semi-
          coordinated work mode

Sorry, it is called 'semi-coordinated', not 'cooperative'.
My mistake.

Andy