Subject: [Netconf] :writable-running and :candidate

From: Andy Bierman <[email-masked]>
Date: Sat, 01 Aug 2009 08:20:47 -0700

Hi,

I asked (in email) how the :candidate and :writable-running
capabilities can possibly be supported on the same agent.
I never got an answer.

I do not understand how the candidate database stays in synch
with the running database if user B can write to running
while user A has the candidate locked.  Also what happens
to the edits made by user A when user B issues a <commit>?
Are the changes just made to running undone (they were not
in the candidate, so they must be undone, right?)

Is this part of the intended database architecture or not?

And if user A does a copy-config from a locked candidate to running?
That is allowed of course.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 8 Aug 2009 10:37:45 -0400

>capabilities can possibly be supported on the same agent.

I believe I answered you, saying that tail-f's sw does this.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 08 Aug 2009 08:09:24 -0700

> I believe I answered you, saying that tail-f's sw does this.

I asked for clarifications on the standard,
for specific corner-cases that IMO indicate
that this combination is not supported by the standard.

The thread reached a conclusion that even though any
changes made to running will get wiped-out as soon
as the candidate is committed, this is how the
standard is intended to work.

I can't imagine that an operator or NMS developer
using :writable-running would reach the same conclusion,
but that's their problem -- not an IETF standards problem, right?

Andy