IETF Logo Mail Archive

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

"Jonathan Hansford" <jonathan@hansfords.net> Tue, 15 January 2019 11: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 69296130E2B for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 03:10:17 -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 dzKIa5w0LM0c for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 03:10:15 -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 6FB42127133 for <netconf@ietf.org>; Tue, 15 Jan 2019 03:10:15 -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: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=9dOl4Myqn6nIRdxthVTQhMywyjgY11gSDtI21d9BmM4=; b=2FkOPJvgt5dVtKkSHAUwHjtQ9 tpe8HIGpL5dtf1Qo6ofQsYCIEyg6/cyC62jMEsF4P8VnDFiiyfOhwWf5lVmJnWDFVQbnZ1a25qJuf FdLP2UTHBgVQS1Nx4OoqBgKcckpzVzsPAn4vt1dz6XRNz7vIqEJJwN3zLgWEhcd5EJg0kIQ5lrzDQ sC7+IgR3xfs3grXwKt0xcmiYKAs+CYMDFHKs+b3/UugV8K9t0rAdeTG0OXchAFxY7J6Nrs08/ZhZl 1+mXtogx3FE5eUqP9kAo/5CQXWepvGE/kV3BuV8lcBK/mqi4u0BfKbeTz3wYL37DiyW40NaAb/Nlm jVLmE0Hhw==;
Received: from [51.52.247.166] (port=51563 helo=[172.16.1.65]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1gjMbk-004Qb8-5v; Tue, 15 Jan 2019 11:10:12 +0000
From: Jonathan Hansford <jonathan@hansfords.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: 'Andy Bierman' <andy@yumaworks.com>, netconf@ietf.org
Date: Tue, 15 Jan 2019 11:10:19 +0000
Message-Id: <em78cf0e94-3893-444f-af27-af785829bb37@morpheus>
In-Reply-To: <20190115105935.7xs43rlsngntedia@anna.jacobs.jacobs-university.de>
References: <em5dfb175c-7835-43eb-a767-38e270601427@morpheus> <20190114154026.tbevjbcdn3oh34uz@anna.jacobs.jacobs-university.de> <emd3042eae-a670-4eb3-8055-5f3379acc4d8@morpheus> <20190114162532.ptmzaxwghowda2o7@anna.jacobs.jacobs-university.de> <CABCOCHTTMPq54_HPYOLBGavX2Q1NqzHPXLv0BVofBaKSxd=TdQ@mail.gmail.com> <009301d4ac44$c55b0fe0$50112fa0$@hansfords.net> <20190114223221.ohkqjlqvtwbdjkx6@anna.jacobs.jacobs-university.de> <em2395bee5-1d9f-40c5-8162-314dad97f6d3@morpheus> <20190115101409.jn4ygedezyy53nih@anna.jacobs.jacobs-university.de> <em915d9278-7fc2-4163-b580-95e4d7ac5442@morpheus> <20190115105935.7xs43rlsngntedia@anna.jacobs.jacobs-university.de>
Reply-To: Jonathan Hansford <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.34062.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBACA99D09-65F1-4C38-A977-8D5F59377C10"
X-Antivirus: Avast (VPS 190115-0, 15/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/S_V8fGi6Gp0lcuA0_KLxoUe4HeQ>
Subject: Re: [Netconf] Is there a problem with confirmed commits?
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, 15 Jan 2019 11:10:17 -0000


On 15/01/2019 10:59:35, "Juergen Schoenwaelder" 
<j.schoenwaelder@jacobs-university.de> wrote:

>On Tue, Jan 15, 2019 at 10:36:02AM +0000, Jonathan Hansford wrote:
>>
>>  > Why copy again? The flow would be:
>>  >
>>  >   upon confirmed-commit:
>>  >      copy <candidate> to <running>
>>  >      reinitialize what needs to be reinitialized
>>  >      wait for the confirmation
>>  >      if (timeout) rollback <running>
>>
>>  Section 8.4.1 states, 'A confirmed <commit> operation MUST be reverted
>>  if a confirming commit is not issued within the timeout period (by
>>  default 600 seconds = 10 minutes). The confirming commit is a <commit>
>>  operation without the <confirmed> parameter... the confirming commit ...
>>  MAY introduce additional changes to the configuration' So the
>>  confirmation comes in the form of a confirming commit which is not
>>  described as being different to any other commit, other than it
>>  completes a confirmed commit.
>>
>>  Section 8.3.4.1 states, 'The <commit> operation instructs the device to
>>  implement the configuration data contained in the candidate
>>  configuration.' So a confirming commit has to copy to <running> any
>>  changes, if any, that have been made to <candidate> since the previous
>>  confirmed commit.
>>
>
>Since the data has already been copied and the server is just waiting
>for the confirming commit to finish the confirmed commit, there is no
>need to copy data again.
But that is not what the RFC suggests and there is nothing to stop 
changes being introduced to <candidate>. That is why Section 8.4.1 
states, 'the confirming commit ... MAY introduce additional changes to 
the configuration'. So if <candidate> has changed, those changes need to 
be committed.

>
>
>/js
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

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

v2.23.0 | Report a Bug | By Email