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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jan 15, 2019 at 10:36:02AM +0000, Jonathan Hansford wrote:
> 
> > 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>
>
> Section 8.4.1 states, 'A confirmed <commit> operation MUST be reverted
> if a confirming commit is not issued within the timeout period (by
> default 600 seconds = 10 minutes). The confirming commit is a <commit>
> operation without the <confirmed> parameter... the confirming commit ...
> MAY introduce additional changes to the configuration' So the
> confirmation comes in the form of a confirming commit which is not
> described as being different to any other commit, other than it
> completes a confirmed commit.
> 
> Section 8.3.4.1 states, 'The <commit> operation instructs the device to
> implement the configuration data contained in the candidate
> configuration.' So a confirming commit has to copy to <running> any
> changes, if any, that have been made to <candidate> since the previous
> confirmed commit.
>

Since the data has already been copied and the server is just waiting
for the confirming commit to finish the confirmed commit, there is no
need to copy data again.

/js

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