Re: [Netconf] Confirmed commit

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Fri, 20 September 2013 10:08 UTC

Return-Path: <bertietf@bwijnen.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 D520221F8FDC for <netconf@ietfa.amsl.com>; Fri, 20 Sep 2013 03:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 c-0+1mzuM3fy for <netconf@ietfa.amsl.com>; Fri, 20 Sep 2013 03:08:21 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8A21F8F97 for <netconf@ietf.org>; Fri, 20 Sep 2013 03:08:20 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1VMxdI-0000kj-Mt; Fri, 20 Sep 2013 12:08:19 +0200
Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1VMxdI-000766-Jt; Fri, 20 Sep 2013 12:08:16 +0200
Message-ID: <523C1E8F.5020207@bwijnen.net>
Date: Fri, 20 Sep 2013 12:08:15 +0200
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: jonathan@hansfords.net
References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <a6c873ec7bf7ba7766d822c1caf3b3ea@imap.plus.net> <20130919201517.GA1886@elstar.local> <CABCOCHTOWgn7d=maj-bw7t_PooT9fJwYdoLZKP1ABcvF+=MYFA@mail.gmail.com> <20130920051315.GA2835@elstar.local> <523BEE26.4070908@bwijnen.net> <535778763-1379664004-cardhu_decombobulator_blackberry.rim.net-1112072667-@b28.c4.bise7.blackberry>
In-Reply-To: <535778763-1379664004-cardhu_decombobulator_blackberry.rim.net-1112072667-@b28.c4.bise7.blackberry>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130920 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46effcedbad66cf7c5350e69c3d4b670c
Cc: Netconf <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 10:08:27 -0000

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
erratum?

Bert

On 9/20/13 10:00 AM, Jonathan Hansford wrote:
> Would it be worth agreeing text online then raising an erratum?
> Sent from my BlackBerry
>
> -----Original Message-----
> From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
> Date: Fri, 20 Sep 2013 08:41:42
> To: Andy Bierman<andy@yumaworks.com>; Jonathan Hansford<Jonathan@hansfords.net>; Netconf<netconf@ietf.org>
> Subject: Re: [Netconf] Confirmed commit
> See at bottom
>
> On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote:
>> On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote:
>>> Hi,
>>>
>>> I always found section 8.4.1, para 2 confusing.
>>>
>>> T0: /int8.1 does not exist
>>>
>>>      > merge /int8.1 value=20
>>>      > commit confirmed confirm-timeout=60
>>>
>>> T1: /int8.1 = 20
>>>
>>>      merge /int8.1 value=30
>>>      commit confirmed confirm-timeout=60
>>>
>>> T2: /int8.1 = 30
>>>
>>> T3: timeout occurs:
>>>
>>> para 6 says:
>>>
>>>      If a confirming commit is not issued, the device will revert its
>>>      configuration to the state prior to the issuance of the confirmed
>>>      commit.
>>>
>>>
>>> The problem is that there are 2 confirmed commit operations.
>>> At time T3 does the server go back to state T1 or T0?
>>> (Our server goes back to T0).
>>>
>>> The 2nd commit contains a confirmed parameter, and para 2
>>> sentence 2 clearly says this is not a confirming commit.
>>> The text does not actually define a "confirmed commit",
>>> but I assume it is a commit with a confirmed parameter.
>>> Therefore, paragraphs 5 - 7 are wrong where they refer
>>> to "the confirmed commit", because there are 2 of them.
>>>
>>
>> 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
>> /js
>>