Re: [Netconf] Confirmed commit

"mikebianc@aol.com" <mikebianc@aol.com> Thu, 19 September 2013 20:15 UTC

Return-Path: <mikebianc@aol.com>
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 330F121F85B3 for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2013 13:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level:
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwlyAdaG4eGy for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2013 13:15:07 -0700 (PDT)
Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.143.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE94421F85B2 for <netconf@ietf.org>; Thu, 19 Sep 2013 13:15:06 -0700 (PDT)
Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by omr-m01.mx.aol.com (Outbound Mail Relay) with ESMTP id AC393701065EC; Thu, 19 Sep 2013 16:15:04 -0400 (EDT)
Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6BB6EE0000E2; Thu, 19 Sep 2013 16:15:04 -0400 (EDT)
Date: Thu, 19 Sep 2013 16:15:04 -0400
From: "mikebianc@aol.com" <mikebianc@aol.com>
To: Jonathan@hansfords.net, netconf@ietf.org
Message-ID: <1469752086.21674.1379621704097.JavaMail.tomcat@mgs-aad01.mail.aol.com>
In-Reply-To: <a6c873ec7bf7ba7766d822c1caf3b3ea@imap.plus.net>
References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <a6c873ec7bf7ba7766d822c1caf3b3ea@imap.plus.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_21673_1128350158.1379621704096"
X-Originating-IP: 10.181.180.189, 64.12.75.136
X-Mailer: Alto
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1379621704; bh=a2z7cj6oNd8PJN6FoyVaXXwaeYo/MDZqlezfYtL8S0w=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=P+UOofeyhA4zt3ErjO7m00pJFz11bYWX1duSbJ8WA2cJi5jfqJnG46STWftD4NYlL 6bHPrJCPev9ZYv3aSt4PJ/VgS+3n3ZWiGQvsxASB2H6S48JSPyy8ZKRwyfDF9eowS5 SeQ7SRuiXpa6QW37g4vWEqxK+icYHw5gsojOOMi8=
x-aol-sid: 3039ac1d33c6523b5b48630b
X-AOL-IP: 205.188.178.60
Subject: Re: [Netconf] Confirmed commit
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Sep 2013 20:15:13 -0000

I am familiar with the Juniper 'commit confirmed' command which means exactly what you guessed it means (you type in 'commit confirmed [timeout]' and then if you aren't kicked off the box, you type in 'commit' to confirm the commit otherwise it reverts back).


So to answer your question, having 'confirming' commit as well as 'confirmed commit' is rather confusing, esp to someone who is unfamiliar with one or both cases and has to make assumptions.





From: Jonathan@hansfords.net<Jonathan@hansfords.net>
To: <netconf@ietf.org>
Sent: Thursday, September 19, 2013
Subject: Re: [Netconf] Confirmed commit



After about two hours digging around in the NETCONF archive and then a Google search on "confirmed commit", I've come to the conclusion confirmed commit has come out of the JUNOS "commit confirmed" command. My guess is the JUNOS command is shorthand for "revert this commit after the timeout unless it is confirmed"; not exactly clear. Indeed, I would have thought "commit confirmed" would be the command to confirm the previous commit, though obviously that would overload the meaning of the original "commit" command since it would not persist without the confirmation.

But "confirmed commit" implies the commit has been confirmed, not that it needs to be confirmed. Isn't this confusing to anyone else?

Jonathan

On 2013-09-19 13:41, Jonathan Hansford wrote:




Hi,

I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made?

Thanks,

Jonathan