Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
"ietfdbh" <ietfdbh@comcast.net> Thu, 12 December 2013 17:20 UTC
Return-Path: <ietfdbh@comcast.net>
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 6C7A71AE375 for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 09:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 xdnXSwda5OMj for <netconf@ietfa.amsl.com>; Thu, 12 Dec 2013 09:20:51 -0800 (PST)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3197C1AE36A for <netconf@ietf.org>; Thu, 12 Dec 2013 09:20:51 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 0gcf1n0021YDfWL58hLlku; Thu, 12 Dec 2013 17:20:45 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id 0hLk1n0082yZEBF3ghLkuZ; Thu, 12 Dec 2013 17:20:45 +0000
From: ietfdbh <ietfdbh@comcast.net>
To: 'Andy Bierman' <andy@yumaworks.com>, 'Jonathan Hansford' <Jonathan@hansfords.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>
In-Reply-To: <CABCOCHT=2SRjhXwrGwZK=7QbkVkKhhSv8WWXwoGr83r1JC43kA@mail.gmail.com>
Date: Thu, 12 Dec 2013 12:20:40 -0500
Message-ID: <004e01cef75e$7bb29250$7317b6f0$@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CEF734.92DF2260"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFxRN3ibRGuFkOXIPpnNb6vzrZ6MwIxKmMoAhpYLgUB5zDFsADOA3C8AbaCCN8AyzainQHGVfMPAoQ8528B6MKFzAJROrpsmnv4Z4A=
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386868845; bh=ZDiKKyLtf/00xqLjBDGGplsK23BL2A2YszwpJI06vUA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Waqf+mR2sqKhzyd2zA7EA3yTIlRj4tCCqDkyPmH7cQInLf5cjGRG2J/pfl7BCGdeQ bEl/5kiedChljBVz+q+6fT1u3+w4yRX4NWqt8bGi10ZvhSPFMB1tvFKU7tf30FPxoW /n/6zQvL/5TcjDtXhjbswhTxhCqUGFZ3fYLsToHr1t+JWDbIS/k1ZOVI6MOgQLBDGP lnJNBQ+XEOvJ4xKpgJ7xpOfMAILJge3hOouUxZTh+ET4lLTTGNua/cpdr7VcM171q3 Njpd4dS98h+T3l5Nb0WWLZtCyRWyRWjEEzBgdF8vfw4IxIY3p7/d6BV3t+6VdKHu87 2gNeHqQbH5yBg==
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:20:55 -0000
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. 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. 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. 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 <mailto:ietfdbh@comcast.net> ietfdbh@comcast.net +1-603-828-1401 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
- [Netconf] [Technical Errata Reported] RFC6241 (38… RFC Errata System
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Ladislav Lhotka
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… joel jaeggli
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Jonathan Hansford
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… ietfdbh
- Re: [Netconf] [Technical Errata Reported] RFC6241… Andy Bierman
- Re: [Netconf] [Technical Errata Reported] RFC6241… Martin Bjorklund
- Re: [Netconf] [Technical Errata Reported] RFC6241… Juergen Schoenwaelder
- Re: [Netconf] [Technical Errata Reported] RFC6241… Bert Wijnen (IETF)
- Re: [Netconf] [Technical Errata Reported] RFC6241… Benoit Claise
- [Netconf] [Errata Held for Document Update] RFC62… RFC Errata System
- [Netconf] Fwd: [Errata Held for Document Update] … Benoit Claise
- Re: [netconf] [Errata Held for Document Update] R… Megan Ferguson
- Re: [netconf] [Errata Held for Document Update] R… Benoit Claise
- Re: [netconf] [Errata Held for Document Update] R… Martin Bjorklund
- Re: [netconf] [Errata Held for Document Update] R… Per Hedeland
- Re: [netconf] [Errata Held for Document Update] R… Per Hedeland
- Re: [netconf] [Errata Held for Document Update] R… jonathan
- Re: [netconf] [Errata Held for Document Update] R… Jonathan