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

"Jonathan Hansford" <> Mon, 14 January 2019 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C939F128CF2 for <>; Mon, 14 Jan 2019 07:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 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, URIBL_BLOCKED=0.001] 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 geDhU0xa1PWV for <>; Mon, 14 Jan 2019 07:13:58 -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 B5A17124BAA for <>; Mon, 14 Jan 2019 07:13:57 -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=EuBaC3MBrBBxSb22fEyVA9ILWMcyySN/ZcNtRpT+Mo0=; b=WH80b6z84AnKljzd+TP3vwFJ3 7h6lJMdj0588Lom9MTP87cI5+MEfs6MaKaYkOfleC1zoX/OZ5CrYW+hQ3IBJp1xORmDUfc5n+GsRF zioF7cdaFmxNSSENKcO38HjJY/raC3U9LzwBVCwBjwws/HU6OGb2+MiSm9jv5hyIMN2BpXOsXPNh2 U/AmL7C6zSEZHs3Civ9wC49qaNuTylRGy4izeGXdvq8DugbcfslulfIyVcd4NKrYWbfOkP6XWuhN8 6DdF8OWKtE/elp35H7KqCjcpOStxqSnJhOveYDMz0CqI9LG3lYyZ0bCeXFL37o2ott1Abg2+JAXld paNwIzxpQ==;
Received: from [] (port=60869 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1gj3w3-00GYaw-TB; Mon, 14 Jan 2019 15:13:55 +0000
From: "Jonathan Hansford" <>
To: "Juergen Schoenwaelder" <>
Cc: "" <>
Date: Mon, 14 Jan 2019 15:14:02 +0000
Message-Id: <em5dfb175c-7835-43eb-a767-38e270601427@morpheus>
In-Reply-To: <>
References: <em106ef27b-c989-4e0b-b819-413fef852d53@morpheus> <>
Reply-To: "Jonathan Hansford" <>
User-Agent: eM_Client/7.2.34062.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBF7FDBA9F-016C-44F8-B6C1-0823831E5924"
X-Antivirus: Avast (VPS 190114-0, 14/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: Mon, 14 Jan 2019 15:14:00 -0000

If a persistent confirmed commit has not timed out, the running 
configuration datastore will be the same as the candidate and 
<discard-changes> won't change its contents. Any edit of candidate will 
be based on the configuration resulting from the persistent confirmed 

If the persistent confirmed commit has timed out, the running 
configuration datastore will have reverted and <discard-changes> will 
change candidate. Any edit of candidate in this case will be based on 
the configuration prior to the start of the persistent confirmed commit.

------ Original Message ------
From: "Juergen Schoenwaelder" <>
To: "Jonathan Hansford" <>
Cc: "" <>
Sent: 14/01/2019 13:50:56
Subject: Re: [Netconf] Is there a problem with confirmed commits?

>I have not yet understood where you see a problem. In general,
><candidate/> contains arbitrary stuff and hence it is the client's
>responsibility to clear any arbitrary stuff found in <candidate/>
>after obtaining a lock. If does not really matter whether there has
>been a failed confirmed commit before or something else. I think the
>general safe pattern is:
>If you do a confirmed commit and the session disappears, then the lock
>will disappear as well. But I do not think this creates a race
>condition, or I am just not yet seeing it. Perhaps it helps to write
>down the sequence of actions that leads to a race.
>On Mon, Jan 14, 2019 at 12:50:38PM +0000, Jonathan Hansford wrote:
>>  Hi,
>>  No one seems to be responding to my email and proposed erratum around
>>  the subject of confirmed commits (apart from Martin), but I would really
>>  like to know it I am missing something here. As far as I can tell,
>>  session termination during a confirmed commit leads to unpredictable
>>  behaviour and I would like to know whether anyone is using confirmed
>>  commits and how (if at all) they address the issues outlined below. My
>>  assumptions are that locks are used and :writable-running is not
>>  supported.
>>  If the <candidate> and <running> configuration datastores are locked to
>>  prevent concurrent access, and a confirmed commit sequence is
>>  interrupted by the session terminating, the locks will automatically be
>>  released but the server MUST NOT accept a lock on <running> from any
>>  session if another session has an ongoing confirmed <commit>.
>>  Consequently, after session termination no client can acquire a <lock>
>>  on <running>, not even the one that initiated the confirmed <commit>,
>>  until after the confirmed <commit> has timed out. However, if the
>>  confirmed <commit> included the <persist> parameter, the original client
>>  could still issue a <commit> using the persist-id to complete the
>>  sequence prior to the timeout, even without a lock.
>>  Of course, the problem now is the race for the new lock on <candidate>.
>>  If the original client is successful then all is good. But if a new
>>  client locks <candidate> before the timeout on the confirmed commit,
>>  whether or not they precede <lock> with <discard-changes>, <candidate>
>>  will be the same as <running> and the new client will pick up everything
>>  from the previous session. However, the client won’t be able to lock
>>  <running> until after the timeout, at which point <running> reverts but
>>  <candidate> still represents the previous session. If the client tries
>>  to lock <candidate> after the timeout, <running> will have reverted and
>>  the lock will only be granted after a <discard-changes> which will cause
>>  the <candidate> to revert. So, depending on when the lock on <candidate>
>>  occurs relative to the confirmed commit timeout, the client could be
>>  editing <candidate> in one of two states. Further, before the timeout on
>>  the confirmed commit, even if the new client has locked candidate, the
>>  original client could still issue a confirming commit (they don’t need a
>>  lock on <candidate> to do so) which would persistently commit any edits
>>  made by the new client. NOTE: it is not the use of the persist-id that
>>  introduces this behaviour; a new client would have the same problem even
>>  if a confirmed commit was not intended to persist beyond a session
>>  termination.
>>  If the server also supports the :startup capability then, if the session
>>  termination was due to the server rebooting, the behaviour above would
>>  be further complicated by <running> now containing the configuration
>>  from the <startup> configuration datastore.
>>  Am I right?
>>  Jonathan
>>  ---
>>  This email has been checked for viruses by Avast antivirus software.
>>  _______________________________________________
>>  Netconf mailing list
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <>