RE: interesting application problems

["Rob Enns" <rpe@juniper.net>]

> 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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>