Re: [Netconf] Is there a problem with confirmed commits?

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jan 15, 2019 at 10:02:09AM +0000, Jonathan Hansford wrote:
> The issue I am trying to address is one where the original session is
> terminated. This could occur, for example, if the device's IP address is
> changed by the confirmed commit. I have also worked with devices in the past
> where certain configuration changes caused the device to reboot. In both
> circumstances the <candidate> has been copied to <running> but the commit
> hasn't been confirmed. Consequently there is still the need to issue a
> confirming commit which, according to my reading of the RFC, would copy
> <candidate> to <running> again. Clearly if <candidate> hasn't changed the
> server can choose not to make any changes to <running> but, if another
> client has in the meantime updated <candidate>, the confirming commit should
> (by my reading) copy those changes over.

Why copy again? The flow would be:

  upon confirmed-commit:
     copy <candidate> to <running>
     reinitialize what needs to be reinitialized
     wait for the confirmation
     if (timeout) rollback <running>

> From the last few emails on this subject it seems the persist-id can be
> considered a de facto lock on both <candidate> and <running> that is
> released on a confirming <commit>, a timeout on the confirmed <commit> or a
> <cancel-commit>. Unlike other locks, this "lock" could be shared between
> clients by sharing the persist-id. Is that a fair summary?

Yes, this may be one way to look at it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>