Re: [Netconf] [Editorial Errata Reported] RFC6241 (5596)

Jonathan <jonathan@hansfords.net> Wed, 09 January 2019 13:30 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 95E40126CB6 for <netconf@ietfa.amsl.com>; Wed, 9 Jan 2019 05:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 JLurAWOKQepN for <netconf@ietfa.amsl.com>; Wed, 9 Jan 2019 05:30:48 -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 0C68D12426E for <netconf@ietf.org>; Wed, 9 Jan 2019 05:30:47 -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:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Sender:Reply-To: 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=qDgLPnF5/NK4PipUfyMXQPbvXI14gfQQ5kfGYEoMk6E=; b=oM68dvT9pJ0kSoQWNCpMDLHdc FF7/bKCmDOr+xACDCTxCYHg/JbofnCdNtJisuh6chhbs/irqI+2ZhTqMzNw+7fdHPi5DPsV8sTuKL aVd/+nAYZM4LCy2B6D1eEgWCCLzGM/eLtj92h/QLfM2/NkwxeJr/o5sbge5HsgmbL63VWmO4KNVBA DpkXTJX9jicavgQ1nnp7iqDkz7LgHTXa878ueUSCVjkf0ZD2GwWF6PJnBNsi+BtQyrAhA2rlzT4Sx VYjxiHwDJd/5VFXSIRknz7rnv+kqR4AAaLMTmEnYBO5iJiOwtRUtGoHqyJKpB9NExrf/BIvqanAZu qmQel2CDw==;
Received: from hansfords.plus.com ([84.92.116.209]:34131 helo=[192.168.54.23]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1ghDwS-005mlF-Dq; Wed, 09 Jan 2019 13:30:44 +0000
Date: Wed, 9 Jan 2019 13:30:31 +0000
From: Jonathan <jonathan@hansfords.net>
To: rfc-editor@rfc-editor.org, Martin Bjorklund <mbj@tail-f.com>
Cc: rob.enns@gmail.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, ibagdona@gmail.com, warren@kumari.net, kwatsen@juniper.net, mjethanandani@gmail.com, netconf@ietf.org
Message-ID: <dd45f575-90fe-4ea5-aebe-b75bac526b64@Spark>
In-Reply-To: <20190109.131345.733955603346655699.mbj@tail-f.com>
References: <20190109090532.F28AAB82360@rfc-editor.org> <20190109.131345.733955603346655699.mbj@tail-f.com>
X-Readdle-Message-ID: dd45f575-90fe-4ea5-aebe-b75bac526b64@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5c35f783_79838cb2_1ebb"
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/VjUK2E9RvqZ2htUPb3WQ0UFW2zY>
Subject: Re: [Netconf] [Editorial Errata Reported] RFC6241 (5596)
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: Wed, 09 Jan 2019 13:30:51 -0000

At least the erratum got a response, which is more than the original email did!

Unlike locks, a persistent confirmed commit isn't aborted if the NETCONF session terminates and Appendix E, though non-normative, uses locks and optionally the candidate configuration datastore. If a persistent confirmed commit is designed not to abort on session termination, what is the correct client behaviour for handling locks should, for example, either the client or server reboot?

Another client could <discard-changes> and acquire a lock on the candidate configuration datastore while being locked out of the running configuration datastore until the confirmed commit times out because, according to section 7.5, "a lock MUST NOT be granted if … the target configuration is <running>, and another NETCONF session has an ongoing confirmed commit".

Jonathan xx

=O)
On 9 Jan 2019, 12:14 +0000, Martin Bjorklund <mbj@tail-f.com>;, wrote:
> Hi,
>
>
> RFC Errata System <rfc-editor@rfc-editor.org>; wrote:
> > The following errata report has been submitted for RFC6241,
> > "Network Configuration Protocol (NETCONF)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5596
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: Jonathan Hansford <jonathan@hansfords.net>;
> >
> > Section: 7.5
> >
> > Original Text
> > -------------
> > The duration of the lock is defined as beginning when the lock is
> > acquired and lasting until either the lock is released or the
> > NETCONF session closes. The session closure can be explicitly
> > performed by the client, or implicitly performed by the server
> > based on criteria such as failure of the underlying transport,
> > simple inactivity timeout, or detection of abusive behavior on the
> > part of the client. These criteria are dependent on the
> > implementation and the underlying transport.
> >
> > Corrected Text
> > --------------
> > The duration of the lock is defined as beginning when the lock is
> > acquired and lasting until either the lock is released or the
> > NETCONF session closes. The session closure can be explicitly
> > performed by the client, or implicitly performed by the server
> > based on criteria such as failure of the underlying transport,
> > simple inactivity timeout, or detection of abusive behavior on the
> > part of the client. These criteria are dependent on the
> > implementation and the underlying transport. Note that a lock
> > associated with a persistent confirmed commit will be released if
> > the NETCONF session closes and, if required, a new lock will have
> > to be acquired.
>
> The errata adds the last sentence. I don't think that this sentence
> is necessary; there is no text that indicates that a lock will somehow
> be kept if the session terminates - in fact it is clear from section
> 7.5 what happens:
>
> A lock will be released by the system if the session holding the
> lock is terminated for any reason.
>
> Also, note that the proposed text is not quite correct; a lock is not
> associated with a persistent confirmed commit, but with a session.
>
> (There might be other issues with the text around lock and persist, as
> indicated in your email to the list though, but I think that this
> specific errata is not needed.)
>
>
> /martin
>
>
>
>
> >
> > Notes
> > -----
> > A persistent confirmed commit can survive a session termination, however any lock on that same session cannot. If a new session is established between the client and server, the client will need to acquire new locks if it wishes to protect the ongoing persistent confirmed commit.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC6241 (draft-ietf-netconf-4741bis-10)
> > --------------------------------------
> > Title : Network Configuration Protocol (NETCONF)
> > Publication Date : June 2011
> > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
> > Category : PROPOSED STANDARD
> > Source : Network Configuration
> > Area : Operations and Management
> > Stream : IETF
> > Verifying Party : IESG
> >