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

"Jonathan Hansford" <> Tue, 15 January 2019 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7712130E2B for <>; Tue, 15 Jan 2019 02:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t1UKU7W1bcnE for <>; Tue, 15 Jan 2019 02:36:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21D32127133 for <>; Tue, 15 Jan 2019 02:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NusI4y7JdPidaujuYrScMW7ohl6D3/6PBwKKpRQPzIQ=; b=CEeH8E81aGCPANaa8GZwU+QtS OluA2yVGKaP710GgjrkwfGA+2dHZRAfp8uuJbx4AusgA/4G8BTIWIHknLYxJDfg3u/v2Yfuc86wn0 EyCDcwrNvC+ecqM83JniMppkLvhq8S2HKhcYILjRDNOziJNJ3mmLxda9n/h2lwevDx05iCne/OigS rpai++55qlfzIyZq75rMNCJKE7fjSwk7xAbOMFNMWexdq2tW0KP5LJGsg4M0yHnpalHY5UO51b1lQ ogwcxmsD+dlZKXPrMM4cMIZwKTKLx6HEOWB9NF9aGLF8zF1aiwMX+Lvo3Dl0CAbEp4KolzSqzQnFr ciB9pvqCg==;
Received: from [] (port=51405 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1gjM4c-004F8Q-4x; Tue, 15 Jan 2019 10:35:58 +0000
From: "Jonathan Hansford" <>
To: "Juergen Schoenwaelder" <>
Cc: "'Andy Bierman'" <>,
Date: Tue, 15 Jan 2019 10:36:02 +0000
Message-Id: <em915d9278-7fc2-4163-b580-95e4d7ac5442@morpheus>
In-Reply-To: <>
References: <em106ef27b-c989-4e0b-b819-413fef852d53@morpheus> <> <em5dfb175c-7835-43eb-a767-38e270601427@morpheus> <> <emd3042eae-a670-4eb3-8055-5f3379acc4d8@morpheus> <> <> <009301d4ac44$c55b0fe0$50112fa0$> <> <em2395bee5-1d9f-40c5-8162-314dad97f6d3@morpheus> <>
Reply-To: "Jonathan Hansford" <>
User-Agent: eM_Client/7.2.34062.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB466B7D08-3E34-4472-BFDB-63B7DC8B9847"
X-Antivirus: Avast (VPS 190115-0, 15/01/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [Netconf] Is there a problem with confirmed commits?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jan 2019 10:36:03 -0000

On 15/01/2019 10:14:09, "Juergen Schoenwaelder" 
<> wrote:

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

>>  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.
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <>

This email has been checked for viruses by Avast antivirus software.