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

Andy Bierman <andy@yumaworks.com> Thu, 12 December 2013 17:42 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 781281ADFD4 for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 09:42:58 -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 59Skr4Xq16u3 for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 09:42:54 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 840C51AE02C for <netconf@ietf.org>; Thu, 12 Dec 2013 09:42:54 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id c9so573774qcz.16 for <netconf@ietf.org>; Thu, 12 Dec 2013 09:42:48 -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=MjMnHxSm/TGegPRHyfpTFFFaCKNqtbMdUFOFsJyTAiM=; b=DqekH2H7mOk6TgBtTQYNVgvoHWzOlOhiPEwq8jU3c1cdO2ZPjZ+kwdKNz28dhUcCA2 mimeUljRwFE96FI/kc2k4WaX/6J81f0ohwVbVi+iD4jqHonugKRuU6vrogrzzzKhuQPj TTiazy8Q3ZjW8osLcEvGmVoR0/VMyKq1sMSKWn91dST225il8o0GkNl7k3IFMVML8kbe 1gObwLxHkt37j/xRbGjaJDFn8469Wobty7M5zyGZ3w19cK+tWGmvCWEAzgDwWOMlPpfq QdnaILdjnf/jRv2W5bZR1f7/Ev0flHcHuTrFWrq5X+H6dnLLAyzMJ7MWYhbaj0e886Ls U8lg==
X-Gm-Message-State: ALoCoQmADzo9nY4ACta19VfF9cWkJ6mac9zRWTChIgv79UnZNskW8Fl0ElOkwqMLCQQJoJusYCgi
MIME-Version: 1.0
X-Received: by 10.224.39.15 with SMTP id d15mr8162541qae.36.1386870168245; Thu, 12 Dec 2013 09:42:48 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 09:42:48 -0800 (PST)
In-Reply-To: <004e01cef75e$7bb29250$7317b6f0$@comcast.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> <CABCOCHT=2SRjhXwrGwZK=7QbkVkKhhSv8WWXwoGr83r1JC43kA@mail.gmail.com> <004e01cef75e$7bb29250$7317b6f0$@comcast.net>
Date: Thu, 12 Dec 2013 09:42:48 -0800
Message-ID: <CABCOCHT9buLOhFVKd1sNJD-PSux14Zgtb4bci2-=fOcn2ip_bQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: ietfdbh <ietfdbh@comcast.net>
Content-Type: multipart/alternative; boundary=001a1134a56aba8cb104ed59dfa0
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 17:42:58 -0000

Hi,


On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh <ietfdbh@comcast.net>; wrote:

> Hi,
>
>
>
> This thread about an errata says to me that implementers could implement
> the original text in different ways and be conformant to the standard.
>
>
>


What are the implementation differences that the spec allows?



> The clarification text seems to be modifying what a conformant
> implementation must do, and obviously the WG members haven’t reached
> consensus on just what that must be.
>
>
>

I do not agree that there is WG consensus to accept the errata -- the
discussion seems to show
that the term "confirmed commit" is used to refer to the entire procedure
and to a specific
form of a <commit> request.   There is no text that is clearly in error.

I don't think consensus has been established that different implementations
of confirmed commit
are possible.  The draft is clear about the definition of a confirming
commit, and also clear
what ends a confirmed commit procedure.


If the clarification becomes part of conformance requirements, then
> existing implementations would likely become non-conformant.
>
> To me, that says a –bis is called for, including WGLC and IETF LCs, to
> change the conformance requirements of the standard.
>


Can you describe this non-conformance that needs to be fixed with a new RFC?
It seems to me (and other implementors) that restoring the running config to
its state before the first confirmed commit <rpc> request is the correct
behavior.

I do not agree that the current RFC text allows an interpretation that
permits the
server to treat a <commit> with a <confirmed> element as a confirming
commit.
Only a timeout, <cancel-commit> or confirming commit can release the server
from its obligation to revert the saved state.



>
>
> I am not implementing this standard, so maybe I misjudge whether this
> affects existing implementations or not. Please let me know if I am looking
> at this incorrectly.
>
>
>
> David Harrington
>
> ietfdbh@comcast.net
>
> +1-603-828-1401
>



Andy



> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, December 12, 2013 11:57 AM
> *To:* Jonathan Hansford
> *Cc:* Rob Enns; joel jaeggli; Netconf
> *Subject:* Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
>
>
>
>
>
>
>
> 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
>
>
>