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

"Jonathan Hansford" <jonathan@hansfords.net> Tue, 19 June 2018 10:10 UTC

Return-Path: <jonathan@hansfords.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DC9130ECF for <netconf@ietfa.amsl.com>; Tue, 19 Jun 2018 03:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzxFnOdCis2t for <netconf@ietfa.amsl.com>; Tue, 19 Jun 2018 03:10:45 -0700 (PDT)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D61130DC4 for <netconf@ietf.org>; Tue, 19 Jun 2018 03:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; 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 [87.242.131.102] (port=52678 helo=[192.168.0.224]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1fVDb0-009xNf-7n for netconf@ietf.org; Tue, 19 Jun 2018 11:10:42 +0100
From: "Jonathan Hansford" <jonathan@hansfords.net>
To: netconf@ietf.org
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" <jonathan@hansfords.net>
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 - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/grDe07zqihwwYUECIIM3Cj9F6Cs>
Subject: Re: [Netconf] RFC6241 - Confirmed Commit Capability, <close-session> and <kill-session>
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2018 10:10:48 -0000


------ Original Message ------
From: "Jonathan Hansford" <jonathan@hansfords.net>
To: netconf@ietf.org
Sent: 18/06/2018 16:32:45
Subject: [Netconf] RFC6241 - Confirmed Commit Capability, 
<close-session> and <kill-session>

>Hi,
>
>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).
>
>
>Thanks,
>
>Jonathan
>
><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>Virus-free. www.avast.com 
><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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