Subject: RE: interesting application problems

From: "Rob Enns" <[email-masked]>
Date: Wed, 24 Nov 2004 10:14:20 -0800

> The interesting thing with configuration of a device when a tcp based
> transport is in use is that the transport can die in the middle due to
> changes in the configuration themselves.  This leaves things in an odd
> state sometimes.

Yep. As Juergen pointed out, should NETCONF do anything other than 
acknowledge that this is a well known issue?

NETCONF's commit confirmed capability is intended to help address this.

>   The result of the commit is
>   unknown (what happens in the commit when not everything could be
>   completed isn't well defined in the draft, I just noticed...  I
>   don't think it says anywhere if it is all or nothing.  edit-config
>   has options for what to do, but commit does not).  Additionally, if
>   the commit wasn't 100% successful then no one can obtain a lock on
>   the <candidate> store until a rollback is done, a copy from running
>   to candidate, or whatever to release the uncommitted changes.      

commit is atomic. Either it's 100% successful or the configuration 
is unchanged. Looks like the draft doesn't say that though...

thanks,
 Rob

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Rob Enns" <[email-masked]>
Date: Tue, 30 Nov 2004 12:49:11 -0800

> > To address this, I can add the following to the description
> > of commit:
> >
> > The &lt;commit&gt; operation must execute atomically. If the
> > device is unable to commit all of the changes in the candidate
> > configuration datastore, then the running configuration must
> > remain unchanged.
> ...
> 
> The first sentence of the proposed text would impose much
> stricter limitations on implementations than would the second.
> If we're going to throw around words like "atomically", then we
> should qualify them so that they do not over-constrain 
> implementations,
> especially in hard real-time environments.  I see us heading down
> the slippery slope of "as if simultaneously", which was cited as
> one of the implementors' objections to the SNMP way of doing
> things.

Ok... whack the first sentence entirely, and go with the following:

If the device is unable to commit all of the changes in the candidate
configuration datastore, then the running configuration must
remain unchanged.

Rob

---

From: "Frye, Robert J (US SSA)" <[email-masked]>
Date: Tue, 30 Nov 2004 16:21:15 -0500

Capital "'MUST' remain unchanged" and I'm happy with the wording.

Rob Frye
BAE SYSTEMS
CNIR
11487 Sunset Hills Road
Reston, VA 20190
(v)703-668-4520
(m)571-331-2846
(e)[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rob Enns
Sent: Tuesday, November 30, 2004 3:49 PM
To: Randy Presuhn; [email-masked]
Subject: RE: interesting application problems

Rob