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