[Netconf] NETCONF persist-id

<jonathan@hansfords.net> Tue, 08 January 2019 18:27 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 7A73B130F72 for <netconf@ietfa.amsl.com>; Tue, 8 Jan 2019 10:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
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: 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 A6ojlW3r_-5J for <netconf@ietfa.amsl.com>; Tue, 8 Jan 2019 10:27:26 -0800 (PST)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 779D2130F6D for <netconf@ietf.org>; Tue, 8 Jan 2019 10:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=l69JtpQfgF+jAcDK5GT2PekDFM14xIGQ4uuGj4j3UN0=; b=zHuQTKQWnFpyDtAsKWViD6yLP/ ZyiK/ZUkJb0sGot79efF7D8uTdc3XbK+ONyUUEA5Phl+zwO7cT4aioqSo8GqwTvyEcGliv7SjcUEk +HlnSsjsM/+XEpVgGJFh1dW8My/i/Q9Zpd8hSjwSoMr2gvih1j5tCbWjfqxNwzTqPDgYo90NGSwoL 5zI/b49zlP8cK3286+EpUPjccU1ZHpVXJaLIjskRct7A+j86RpSPA2XgxlJ2w7P86AK6UxmuQKius WQQAYrTV6scdGJljsKGRuMnSYvcbZxFVNoInHKcArZaR7HYljp9V1AYxIEucwvmltssIv4iJL8dZV VozwvYNg==;
Received: from hansfords.plus.com ([84.92.116.209]:54881 helo=Vanguard) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1ggw5z-00D42h-KY for netconf@ietf.org; Tue, 08 Jan 2019 18:27:23 +0000
From: <jonathan@hansfords.net>
To: <netconf@ietf.org>
Date: Tue, 8 Jan 2019 18:27:24 -0000
Message-ID: <011801d4a77f$cdad5140$6907f3c0$@hansfords.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01D4A77F.CDAFC240"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdSneoGz79LxA9jdQkC03Q+X6rX2jw==
X-Antivirus: Avast (VPS 190108-2, 08/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 - mail.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: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/pYc_1OC_UJjqxxiSwqtgs8wZcJc>
Subject: [Netconf] NETCONF persist-id
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Jan 2019 18:27:29 -0000

Hi,

 

RFC6241 introduced <persist> and <persist-id> parameters to the commit
operation for NETCONF.

 

In section 7.8 in erratum 5397 it states:

If a NETCONF server receives a <close-session> request while processing a
confirmed commit (Section 8.4) for that session, regardless of whether the
confirmed commit included a <persist> element, it MUST restore the
configuration to its state before the confirmed commit was issued.

 

In section 7.9 in erratum 5397 it states:

If a NETCONF server receives a <kill-session> request while processing a
confirmed commit (Section 8.4) for that session, regardless of whether the
confirmed commit included a <persist> element, it MUST restore the
configuration to its state before the confirmed commit was issued.

 

In section 8.4.1 in erratum 3821 it states:

If the <persist> element is not given in the confirmed commit operation, any
follow-up commit and the confirming commit MUST be issued on the same
session that issued the confirmed commit. If the <persist> element is given
in the confirmed <commit> operation, a follow-up commit and the confirming
commit can be given on any session, and they MUST include a <persist-id>
element with a value equal to the given value of the <persist> element.

 

If the server also advertises the :startup capability, a <copy-config> from
running to startup is also necessary to save the changes to startup. If the
session issuing a sequence of one or more confirmed commits is terminated
for any reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the sequence of confirmed commits was
issued, unless the last confirmed commit also included a <persist> element.

 

In section 8.4.5.1 in erratum 3823 it states:

persist:

Make the confirmed commit survive a session termination, and set a token on
the ongoing sequence of confirmed commits.

 

In Appendix C on page 102 it states:

leaf persist {

if-feature confirmed-commit;

type string;

description

"This parameter is used to make a confirmed commit persistent.  A persistent
confirmed commit is not aborted if the NETCONF session terminates.  The only
way to abort a persistent confirmed commit is to let the timer expire, or to
use the <cancel-commit> operation. The value of this parameter is a token
that must be given in the 'persist-id' parameter of <commit> or
<cancel-commit> operations in order to confirm or cancel the persistent
confirmed commit. The token should be a random string.";

reference "RFC 6241, Section 8.3.4.1";

}

 

It would appear the persist-id is intended to allow a commit operation to
survive a session termination, presumably regardless of whether that
termination results from a <close-session> or <kill-session>. However,
section 7.6 states "An <unlock> operation will not succeed if . the session
issuing the <unlock> operation is not the same session that obtained the
lock", and there is no <persist-id> element for <unlock>. This implies
<lock> cannot be used with a confirmed commit sequence that includes the
termination of the initiating session.

 

Should a <persist-id> element be added to <unlock>, and a new erratum be
raised against sections 7.8 and 7.8 to rescind the previous erratum and
state that any session termination of a persistent confirmed commit will NOT
restore the configuration to its state before the confirmed commit was
issued but continue the persistence until either a timeout or a
<cancel-commit>?

 

Jonathan



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