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

["Jonathan Hansford" <[e-mail]>]

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.

>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?

------ Original Message ------
From: "Juergen Schoenwaelder" <[e-mail]>
To: [e-mail]
Cc: "'Andy Bierman'" <[e-mail]>; [e-mail]
Sent: 14/01/2019 22:32:21
Subject: Re: [Netconf] Is there a problem with confirmed commits?

>On Mon, Jan 14, 2019 at 08:07:26PM -0000, [e-mail] wrote:
>>
>>  Just as a footnote, if the cause of the session termination was the device rebooting and the :startup capability was supported, the <running> configuration datastore will contain whatever was in the <startup> configuration datastore. However, a confirming commit on a persistent confirmed commit would still commit the <candidate> configuration datastore to <running>. If the purpose of the confirmed commit was to test the new configuration prior to making it permanent, it would therefore make sense to copy the <candidate> configuration datastore to the <startup> configuration datastore prior to the confirmed commit.
>>
>
>My understanding of a confirmed commit is:
>
>     copy condidate to running and wait for a confirmation that
>     everything is OK; if no confirmation is received within a certain
>     time window, rollback to the original state of <running>.
>
>The situation you describe is a bit unclear for me; when does the
>device reboot, after the confirmed commit has been issued but before
><candidate> was copied to <running>? That would be a rare situation
>and I have some doubts that implementations after the reboot would
>start the confirmed commit or they would not execute a reboot before
>copying <candidate> to <running>.
>
>/js
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   [phone]         <https://www.jacobs-university.de/>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus