Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)

Andy Bierman <andy@yumaworks.com> Tue, 10 December 2013 17:05 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 39D061AE22A for <netconf@ietfa.amsl.com>; Tue, 10 Dec 2013 09:05:57 -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 zDsir8wzpKo5 for <netconf@ietfa.amsl.com>; Tue, 10 Dec 2013 09:05:56 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED41AE226 for <netconf@ietf.org>; Tue, 10 Dec 2013 09:05:55 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id n7so3976378qcx.5 for <netconf@ietf.org>; Tue, 10 Dec 2013 09:05:50 -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=48nFxqZHo3DEsbWGJbg6/xTKm+0sp+1CbKH9qQ08zWg=; b=kj2mP6xkZeDbJxGcbBpvqFDxlez+Kbnbez6iqPbnIFG/mwYGMKTTDaYnE0NTlc266j RjCOqsoLb4zgvjIjlrlrA95TGQWv/v6vcFoK7YXv//VB5a17k8XsGYLE2GhqhbTtS6Or OYxfR9jzmoGR+xZLQwSkPto18SMJSpjFpMYMSQMnqqbIFBtPNzpgM2Ki4fXZim+AKxGW w4dAJbWVg5ryROzYGvvJuzAEqkM8xPg3MZYSL6oQgFMOfikPNEgfgk7eaWDvMPMezAlE T1ZTy/RVkzv81cbfTgWIDFcdzQfMANJrXjoZNKp+/6UehyCmNttaPY+N1Bwwg281OQdJ za0Q==
X-Gm-Message-State: ALoCoQlHnvhSoVv+8lq49D4QxBCmPftc4Vo71Rv3nH0Elweid8V5yM7DqY+xwqU1IZfoESkI8s9Q
MIME-Version: 1.0
X-Received: by 10.224.151.209 with SMTP id d17mr28186065qaw.87.1386695150368; Tue, 10 Dec 2013 09:05:50 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 09:05:50 -0800 (PST)
In-Reply-To: <7de2779d935aae627d3c3b030466b1dc@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>
Date: Tue, 10 Dec 2013 09:05:50 -0800
Message-ID: <CABCOCHQCayT6UXuh_k9FSZH4iRCoPP7RoBwar1RKAFVM-3T0SQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Jonathan Hansford <Jonathan@hansfords.net>
Content-Type: multipart/alternative; boundary=089e0149d2c4d9a14804ed311fb5
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: Tue, 10 Dec 2013 17:05:57 -0000

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