Subject: [Netconf] :confirmed-commit and :startup

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Jul 2009 09:25:36 -0700

Hi,

It seems to me that the requirements for :confirmed-commit
preclude any possible concurrent support for the :startup
capability.

Am I understanding 4741bis, 8.4.1 correctly?
It is not clear at all how the agent MUST or SHOULD
deal with non-volatile storage of the confirmed commit,
especially when :startup is also supported (or if :startup
should even allowed together with :candidate).

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 15 Jul 2009 13:58:16 -0400

>preclude any possible concurrent support for the :startup

They are orthogonal.  The only thing that affects <startup/> is
<copy-config/>, so your commit confirmed operation should only be
affecting <running/>.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Jul 2009 11:28:38 -0700

> <copy-config/>, so your commit confirmed operation should only be

Does the draft clearly state this somewhere?
I don't think it does.

Another issue that came up in conf-calls:

Is the agent required to support <get-config> with filters
on the <startup> config?  I remember the details as you do --
that the only thing the agent was required to support if
it advertised :startup was <copy-config> from <running>
to <startup>.

The :url capability is just as unclear as :startup,
on this issue.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 15 Jul 2009 15:37:07 -0400

>it advertised :startup was <copy-config> from <running>

Somehow <get-config> ended up in 8.7.5.1 as a modified
RPC, but that's a bug in 4741 imho.  The distinct
startup folks didn't want to support anything fancy
on it.  But that's not what we ended up with.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Jul 2009 12:31:54 -0700

> on it.  But that's not what we ended up with.

I don't implement the other (unintended) required aspects
of :startup, not only because it's too hard, but because it's
not secure.

The startup config is an external file and not a real database.
There is no filtering or access control implemented for it, like the
real databases.

There was never any original intent to treat <startup>
as just another database, especially with the slow NVRAM
devices at the time.  It was expected that copy-config
from running to NV-storage might even be expensive on the agent,
let alone filtering, editing, and access control enforcement.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Jul 2009 10:25:54 +0200 (CEST)

Hi,

> should even allowed together with :candidate).

Is this a different issue than what I wrote in
http://www.ietf.org/mail-archive/web/netconf/current/msg04532.html?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jul 2009 11:30:49 -0700

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

no -- this is the same issue.

I like your idea.
I agree that :startup could be an independent variable,
and should not hard-wired to 'not(:candidate)'.

That would mean that if :startup is advertised,
the NV-storage will never get updated automatically,
no matter what else the agent advertises.
The failed confirmed-commit procedure just refers to
restoring the <running> config.

Andy

---

From: WashamFan <[email-masked]>
Date: Thu, 23 Jul 2009 10:46:15 +0800

Hi,

Should we explicitly specify how to handle :confirmed-commit
and :startup co-existence in the doc?

washam

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Thursday, July 23, 2009 2:35 am
Subject: Re: [Netconf] :confirmed-commit and :startup
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]

>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>