Re: [Netconf] RFC6241 - Confirmed Commit Capability, <close-session> and <kill-session>

"Jonathan Hansford" <> Tue, 19 June 2018 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1DC9130ECF for <>; Tue, 19 Jun 2018 03:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=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 AzxFnOdCis2t for <>; Tue, 19 Jun 2018 03:10:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19D61130DC4 for <>; Tue, 19 Jun 2018 03:10:44 -0700 (PDT)
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:Subject:To:From:Sender:Cc: 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=C6Ijh9hOzFGyDKqQzd4V14JhQ7j4J0bFHPcg6S2fW8Q=; b=kCC9efwKM/OXoV7BdrYqOK8fD hmzOVov5Xcv+4RU9u0nhyrW66TEZ5mCQCc/IuE6pZUDupH/wX9B0smr4Fo1Wh1ITUCBDmDiyWB77J fSaeT/E+c4vGI+jma6IIDG8VMBPXSLz1HXdzuyy4wt5oElmc5LSX8hYbByi3/jDbRhWXtyG6NIZAb aNiIeO5dZMgkf5GNXfP1UJcN1Fz6qECE7QrNUviWkZYG2obyy8KTP56f8V5gm0XYkvBKUzpGKckdV ngL33g4MztJRYoSLvTCQkdA+hA6K5bKSBRZwqFPPjmz8hishNaNrPY7/veOTYJdFBO/g2IQfUas7g Z8MEYkCKQ==;
Received: from [] (port=52678 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1fVDb0-009xNf-7n for; Tue, 19 Jun 2018 11:10:42 +0100
From: "Jonathan Hansford" <>
Date: Tue, 19 Jun 2018 10:10:42 +0000
Message-Id: <emddd186dc-778a-4615-9f84-c60e87edf886@morpheus>
In-Reply-To: <em915805dc-94c3-4955-8d85-f8931cd4d69b@morpheus>
References: <em915805dc-94c3-4955-8d85-f8931cd4d69b@morpheus>
Reply-To: "Jonathan Hansford" <>
User-Agent: eM_Client/7.1.32088.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBD52681DF-F9CC-43DD-BA86-A5E9AC7EC458"
X-Antivirus: Avast (VPS 180618-4, 18/06/2018), 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] RFC6241 - Confirmed Commit Capability, <close-session> and <kill-session>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jun 2018 10:10:48 -0000

------ Original Message ------
From: "Jonathan Hansford" <>
Sent: 18/06/2018 16:32:45
Subject: [Netconf] RFC6241 - Confirmed Commit Capability, 
<close-session> and <kill-session>

>RFC6241, Section 7.9 <kill-session> states "If a NETCONF server 
>receives a <kill-session> request while processing a confirmed commit 
>(Section 8.4), it MUST restore the configuration to its state before 
>the confirmed commit was issued."
>Is it correct to assume that only applies if the session being killed 
>is the one for which a confirmed commit is being processed?
>Section 8.4.1 states "If the session issuing the confirmed commit is 
>terminated for any reason before the confirm timeout expires, the 
>server MUST restore the configuration to its state before the confirmed 
>commit was issued, unless the confirmed commit also included a 
><persist> element."
>Is it correct to assume if a <kill-session> is received for a session 
>for which the confirmed commit included a <persist> element, the 
>behaviour is still to restore the configuration to its state before the 
>confirmed commit was issued since the client owning the session is no 
>longer in control and the session is having to be killed using a 
>different client?
>Section 7.8 <close-session> makes no mention of confirmed commits.
>Is it correct to assume the client would be expected to cancel a 
>confirmed commit before closing its session unless the client wished to 
>continue on a new session (e.g. after a device reboot) in which case 
>the confirmed commit would have included a <persist> element?
Thinking about it, <close-session> clears any locks which implies any 
outstanding confirmed commits should be cancelled as with 
<kill-session>. That also implies confirmed commits only persist beyond 
a session if the session is closed in an uncontrolled manner (e.g. 
through a client or server reboot). But the confirmed commit is planned 
so why should a <close-session> (also planned) have to clear locks? 
Surely a <close-session> should optionally clear locks and cancel 
confirmed commits, based on the reason for closing the session.

Also, Section 7.9 talks about <kill-session> being received by a NETCONF 
entity. Section 1 indicates clients send RPCs to servers so presumably 
by "entity" section 7.9 means server (as in other sections).

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