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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 15 January 2019 10:59 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 1A08C130DEA for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 kMo50bCV2zRA for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:59:39 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED53127133 for <netconf@ietf.org>; Tue, 15 Jan 2019 02:59:39 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9D39CFDE; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SPh2mogOvbt0; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8653F20046; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pG_AiyKulASz; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 292ED20045; Tue, 15 Jan 2019 11:59:37 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 15 Jan 2019 11:59:36 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 6A58E3005A4089; Tue, 15 Jan 2019 11:59:35 +0100 (CET)
Date: Tue, 15 Jan 2019 11:59:35 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Jonathan Hansford <jonathan@hansfords.net>
CC: 'Andy Bierman' <andy@yumaworks.com>, <netconf@ietf.org>
Message-ID: <20190115105935.7xs43rlsngntedia@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Jonathan Hansford <jonathan@hansfords.net>, 'Andy Bierman' <andy@yumaworks.com>, netconf@ietf.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <em915d9278-7fc2-4163-b580-95e4d7ac5442@morpheus>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/PcGtOVBRWq3fxaVuz8XogTyNPUo>
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 10:59:41 -0000

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.

/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/>