Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
Andy Bierman <andy@yumaworks.com> Thu, 12 December 2013 16:57 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7D1ADF67 for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 08:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 L5JIH2gSmwLN for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 08:57:49 -0800 (PST)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id EF1651AD2EC for <netconf@ietf.org>; Thu, 12 Dec 2013 08:57:48 -0800 (PST)
Received: by mail-qa0-f49.google.com with SMTP id ii20so1856603qab.15 for <netconf@ietf.org>; Thu, 12 Dec 2013 08:57:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XanpNtx2tcTMbfk8eQBMX+6eZFV47OfJjrb3mimxGY0=; b=H5JEY4JHWstx9atj8VAKu/4X/e2Dgky7polvuBdKcjENCWBTbXXqhSY8vGQdtHonqq DHm0x6NPs6ALN78EIeViDoBYPbMoMC8bWDXsGrgM3j2NtvVXQETi3ZCEgh/x9WbxY4td 5scY1sDNHo5KdA4Q69xRGsqSFub4U/2KwHVXsxXbGX7Vw0bwTwO3UX36+i6bKNYd/c4l Ddq4g6IM2y1t9BzGMnlmDp8dcEtdXdbx6OkJAkBlX0dJ+tC7zqroxt/HkWOlffaZJJ98 L83XbA6fSVKUtI0zbGilPZh0VOP0BYomB3U8xTj50AaxAe11uwBwo7z1gpk4BqZGcs7h 53cQ==
X-Gm-Message-State: ALoCoQmbzR1fSjsLW8mbfslH7h92JJx4S6tNqI0y+/PPt5voA7ee4sXDiyxSWTjCdRummbwX1NcI
MIME-Version: 1.0
X-Received: by 10.224.51.74 with SMTP id c10mr14574215qag.7.1386867435232; Thu, 12 Dec 2013 08:57:15 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 08:57:15 -0800 (PST)
In-Reply-To: <80d82e162c729b696be4ddd23dc624d2@imap.plus.net>
References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <CABCOCHQfbsz8AHY0SRs+TOcmARenvTQ2Nn_JtAkynexxh-wozw@mail.gmail.com> <cb13626ae792344d299ac437a00c906b@imap.plus.net> <CABCOCHS4BSR=46xcnWx02DQtXm6rtbJ69vHXwO9gReOPrist-g@mail.gmail.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <CABCOCHQCayT6UXuh_k9FSZH4iRCoPP7RoBwar1RKAFVM-3T0SQ@mail.gmail.com> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net>
Date: Thu, 12 Dec 2013 08:57:15 -0800
Message-ID: <CABCOCHT=2SRjhXwrGwZK=7QbkVkKhhSv8WWXwoGr83r1JC43kA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Jonathan Hansford <Jonathan@hansfords.net>
Content-Type: multipart/alternative; boundary="089e0158cb54d40bcb04ed593c0c"
Cc: Rob Enns <rob.enns@gmail.com>, joel jaeggli <joelja@bogus.com>, Netconf <netconf@ietf.org>
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Dec 2013 16:57:52 -0000
On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford <Jonathan@hansfords.net>wrote: > > > On 2013-12-10 17:05, Andy Bierman wrote: > > > > > On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <Jonathan@hansfords.net > > wrote: > >> On 2013-12-10 16:15, Andy Bierman wrote: >> >> >> >> >> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford < >> Jonathan@hansfords.net> wrote: >> >>> On 2013-12-10 15:59, Andy Bierman wrote: >>> >>> Hi, >>> I don't think these 3 reports are corrections. >>> They are editorial changes to the text. >>> I don't agree that the new terminology added "sequence of confirmed >>> commits" >>> is correct. There is just 1 netconf-confirmed-commit notification for >>> start & complete >>> sent out no matter how how many times the procedure is extended. >>> If the procedure ends with a cancel or timeout, there is only 1 >>> original commit >>> that is restored. It is incorrect to think of this procedure as a >>> series of >>> confirmed commits. A commit that extends the procedure is not treated >>> the same as the commit that starts the procedure. >>> >>> Are you saying that the initial commit of the sequence (the confirmed >>> commit?) is restored should the procedure be cancelled or timeout? Surely >>> the commit that is restored is the one that preceded the confirmed commit. >>> >> The confirmed commit is the first <commit> that includes a <confirmed> >> parameter. >> The 2nd - Nth <commit> are extending the first commit operation. The >> server is still >> obligated to revert the running config for the first commit (if it is >> canceled or timed out). >> This obligation is not removed because the commit is extended. It is >> only removed >> if a confirming commit is received. >> >> Andy, >> I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd >> paragraph) talks about 'a follow-up confirmed <commit> operation'. Are you >> saying that that second 'confirmed <commit>' (i.e. a <commit> with the >> <confirmed> parameter) is not a "confirmed commit"? And when you say 'the >> server is obligated to revert the running config for the first commit' do >> you mean revert to the state prior to that first confirmed <commit>? >> > sec. 8.4.1, para 2: > > The confirming commit is a <commit> operation > without the <confirmed> parameter. > > The 2nd commit with a <confirmed> parameter extends the confirmed-commit > procedure. > Any cancel or complete applies to this commit. If canceled, then the > changes made for the > 2nd commit are going to be undone. An extension commit is not a > confirming commit. > A cancel/timeout causes the config to revert to its state before the first > confirmed commit > operation. > >> Jonathan >> > Andy > > Andy, > What I think you seem to be stating here is that there are three types of > commit (and possibly, by extension, four): > > 1. "Confirmed commit" - the first successful commit with a <confirmed> > parameter after a successful commit without a <confirmed> parameter > 2. "Extension commit" - any commit with a <confirmed> parameter after > a "confirmed commit" and before any successful "confirming commit" > 3. "Confirming commit" - any commit without a <confirmed> parameter > after a "confirmed commit" and before any other successful "confirming > commit" > 4. "Standard commit" - any commit without a <confirmed> parameter > after a successful "confirming commit" and before a subsequent "confirmed > commit" > > By those definitions a "confirmed commit" cannot follow another "confirmed > commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about > follow-up "confirmed commits" and "confirming commits". How can there be a > follow-up "confirmed commit", unless the definition of a "confirmed commit" > becomes something like: > > (the first commit with a <confirmed> parameter after a successful commit > without a <confirmed> parameter) OR (the first successful commit with a > <confirmed> parameter from another session and the appropriate <persist-id>) > The saved state that that gets reverted if the commit is not confirmed does not change because anther commit with a <confirmed> element is received. This 2nd commit that is extending the confirmed commit procedure is clearly not a confirming commit, so the server cannot update the saved state that will be reverted if necessary. The terminology does not distinguish very well between the confirmed commit procedure and a <rpc> request that is called a confirmed commit. There is only 1 confirmed commit procedure active at any given time. The 2nd confirmed commit <rpc> request does not end the first procedure and start a new one. Once the procedure is ended somehow, then it ends for all the confirmed commit requests that are pending. Also, 8.4.5.1 states the <persist> parameter makes the "confirmed commit" > survive a session termination. Does that mean the <persist-id> parameter > can only be successful if the original session has been terminated, or is > it more accurate to state that the <persist> parameter allows the > "confirmed commit" to be extended by other sessions, whether or not the > original session has been terminated? > No -- any session that knows the correct persist-id can complete the procedure, including any session that sent a confirmed commit <rpc> request. > Thanks, > > Jonathan > Andy
- [Netconf] [Technical Errata Reported] RFC6241 (38… RFC Errata System
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Ladislav Lhotka
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… joel jaeggli
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… ietfdbh
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Benoit Claise
- [Netconf] [Errata Held for Document Update] RFC62… RFC Errata System
- [Netconf] Fwd: [Errata Held for Document Update] … Benoit Claise
- Re: [netconf] [Errata Held for Document Update] R… Megan Ferguson
- Re: [netconf] [Errata Held for Document Update] R… Benoit Claise
- Re: [netconf] [Errata Held for Document Update] R… Martin Bjorklund
- Re: [netconf] [Errata Held for Document Update] R… Per Hedeland
- Re: [netconf] [Errata Held for Document Update] R… Per Hedeland
- Re: [netconf] [Errata Held for Document Update] R… jonathan
- Re: [netconf] [Errata Held for Document Update] R… Jonathan