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

Andy Bierman <> Thu, 12 December 2013 16:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CF7D1ADF67 for <>; Thu, 12 Dec 2013 08:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L5JIH2gSmwLN for <>; Thu, 12 Dec 2013 08:57:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EF1651AD2EC for <>; Thu, 12 Dec 2013 08:57:48 -0800 (PST)
Received: by with SMTP id ii20so1856603qab.15 for <>; Thu, 12 Dec 2013 08:57:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id c10mr14574215qag.7.1386867435232; Thu, 12 Dec 2013 08:57:15 -0800 (PST)
Received: by with HTTP; Thu, 12 Dec 2013 08:57:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 12 Dec 2013 08:57:15 -0800
Message-ID: <>
From: Andy Bierman <>
To: Jonathan Hansford <>
Content-Type: multipart/alternative; boundary=089e0158cb54d40bcb04ed593c0c
Cc: Rob Enns <>, joel jaeggli <>, Netconf <>
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Dec 2013 16:57:52 -0000

On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford

> On 2013-12-10 17:05, Andy Bierman wrote:
> On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <
> > wrote:
>>  On 2013-12-10 16:15, Andy Bierman wrote:
>> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <
>>> 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 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
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
then it ends for all the confirmed commit requests that are pending.

Also, 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
including any session that sent a confirmed commit <rpc> request.

> Thanks,
> Jonathan