Re: [Netconf] Confirmed commit
Jonathan Hansford <Jonathan@hansfords.net> Fri, 20 September 2013 12:50 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 32B5321F991E for <netconf@ietfa.amsl.com>; Fri, 20 Sep 2013 05:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Level:
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 asrIjPUYLqon for <netconf@ietfa.amsl.com>; Fri, 20 Sep 2013 05:50:20 -0700 (PDT)
Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F221F98EE for <netconf@ietf.org>; Fri, 20 Sep 2013 05:50:18 -0700 (PDT)
Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id TQqG1m003283uBY01QqHiW; Fri, 20 Sep 2013 13:50:17 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=urOY2GcFnqMA:10 a=SUE4xeBjAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=rihGqeaeGMNJ_zN5TosA:9 a=j687ffqgWN9L1c5g:21 a=e7DWD138tDqp-C0T:21 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=jFPUFpGHtmAA:10 a=ChEcuLpljosA:10 a=lZB815dzVvQA:10 a=mKXWlFheUt9OwBv7ot4A:9 a=n2YzEJjhoVO3ULyy:21 a=Y1PkaJMBiVD0VzhX:21 a=jGZpr6vZ-Cc2wpE3:21 a=_W_S_7VecoQA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 20 Sep 2013 13:50:16 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_404faad83dccbb8ce4012f39b0cd2982"
Date: Fri, 20 Sep 2013 13:50:16 +0100
From: Jonathan Hansford <Jonathan@hansfords.net>
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
In-Reply-To: <523C3856.9040304@bwijnen.net>
References: <c0df6f9383b5810f604aec2a2f381bae@imap.plus.net> <20130920.125718.2241274183066609324.mbj@tail-f.com> <523C3856.9040304@bwijnen.net>
Message-ID: <e63b0a016e00e48e181bc0e9d6b97b85@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.134.100]
Cc: netconf@ietf.org
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: Fri, 20 Sep 2013 12:50:30 -0000
In order to address the terminology issue without changing the terminology, how about changing the first paragraph of 8.4.1 to: The :confirmed-commit:1.1 capability indicates that the server will support the <cancel-commit> operation, the <confirmed>, <confirm-timeout>, <persist>, and <persist-id> parameters for the <commit> operation, and differentiate between a "to be confirmed" <commit> operation (a "confirmed commit") and a confirming <commit> operation. See Section 8.3 for further details on the <commit> operation. Jonathan On 2013-09-20 12:58, Bert Wijnen (IETF) wrote: > Speaking as a technical contributor. > > I also think we should stick to the terminology we have been using for > many years now. So I was thinking more about some clarifying or explanatory > text instead of renaming our terminology. > > Bert > > On 9/20/13 12:57 PM, Martin Bjorklund wrote: > >> Hi, I don't think we should change the terminology in an errata. (and actually I don't think we should change it at all - I agree there might be a better term, but the term "confirmed commit" has been used for several years and people are used to it) Your text about sequence of commits is fine; but I think we should stick to the current terminology. /martin Jonathan Hansford <Jonathan@hansfords.net [8]> wrote: >> >>> I propose the following changes to address Andy's issue relating to consecutive confirmed commits and my issue relating to the confusing terminology: 8.4.1. Description (paras 2-6) A <commit> operation with the <confirmed> parameter (an unconfirmed <commit>) 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 and, if successful, cannot be reverted. The timeout period can be adjusted with the <confirm-timeout> parameter. If a follow-up unconfirmed <commit> operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up unconfirmed <commit> operation MAY introduce additional changes to the configuration. If the <persist> element is not given in the unconfirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the unconfirmed commit. If the <persist> element is given in the unconfirmed <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 unconfirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued, unless the last unconfirmed commit also included a <persist> element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of unconfirmed commits. To cancel the current sequence of unconfirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of unconfirmed commits was issued, by using the <cancel-commit> operation. : 8.4.4.1. <cancel-commit> Description: Cancels an ongoing sequence of unconfirmed commits. If the <persist-id> parameter is not given, the <cancel-commit> operation MUST be issued on the same session that issued the sequence of unconfirmed commits. Parameters: persist-id: Cancels a persistent sequence of unconfirmed commits. The value MUST be equal to the value given in the <persist> parameter to the <commit> operation. If the value does not match, the operation fails with an "invalid-value" error. : 8.4.5.1. <commit> The :confirmed-commit:1.1 capability allows 4 additional parameters to the <commit> operation. Parameters: confirmed: Perform an unconfirmed <commit> operation. confirm-timeout: Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. persist: Make the unconfirmed commit survive a session termination, and set a token on the ongoing sequence of unconfirmed commits. persist-id: Used to issue a follow-up unconfirmed commit or a confirming commit from any session, with the token from the previous <commit> operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:THat is one (and probably good) approach. >>> >>>> So can the >>> authors/experts suggest some text that makes >>> >>>> sense as a fix (or better >>> clarification) to a possible Yes, this corner case where multiple confirmed commits are issued is not described well. Your interpretation that subsequent confirmed commits effectively extend the first one makes sense to me. Can wee keep this somewhere so we clarify it if we ever have to open up and update the document? Bert Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] mailto:netconf@ietf.org [5] mailto:andy@yumaworks.com [6] mailto:Jonathan@hansfords.net [7] mailto:netconf@ietf.org [8] mailto:Jonathan@hansfords.net
- [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit mikebianc@aol.com
- Re: [Netconf] Confirmed commit Juergen Schoenwaelder
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Andy Bierman
- Re: [Netconf] Confirmed commit Juergen Schoenwaelder
- Re: [Netconf] Confirmed commit Bert Wijnen (IETF)
- Re: [Netconf] Confirmed commit Martin Bjorklund
- Re: [Netconf] Confirmed commit Bert Wijnen (IETF)
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Martin Bjorklund
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Bert Wijnen (IETF)
- Re: [Netconf] Confirmed commit Jonathan Hansford
- Re: [Netconf] Confirmed commit Andy Bierman