Subject: RE: interesting application problems

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

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

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.

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: Wes Hardaker <[email-masked]>
Date: Wed, 24 Nov 2004 17:08:01 -0800

>>>>> On Wed, 24 Nov 2004 10:17:09 -0800, "Rob Enns" <[email-masked]> said:

Rob> The &lt;commit&gt; operation must execute atomically. If the
Rob> device is unable to commit all of the changes in the candidate
Rob> configuration datastore, then the running configuration must
Rob> remain unchanged.

Ok.  Sounds good.  From an implementation point of view, that may be
difficult to achieve some times.  Are you going to make that a MUST?

In short, you can upload a bad configuration today that causes boxes
to fail to come up.  netconf will provide them with the same power to
shoot themselves and I'm not sure you can actually achieve the above
paragraph in real life all the time.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Nov 2004 17:41:17 -0800

Hi -

> From: "Rob Enns" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, November 24, 2004 10:17 AM
> Subject: RE: interesting application problems
...
> configuration datastore, then the running configuration must
...

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.

Randy