Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)

Jonathan <jonathan@hansfords.net> Fri, 12 April 2019 12:22 UTC

Return-Path: <jonathan@hansfords.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 4B2ED12019B; Fri, 12 Apr 2019 05:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
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 sMIdq444tWgU; Fri, 12 Apr 2019 05:22:01 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF1B12011D; Fri, 12 Apr 2019 05:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5iIlsS695vITqJSVlJsLEP2lu8qH8e81l6q4WJO/MF0=; b=Aqdd6WbRzoKlxod5MAVcfTxH4 0Hw6kchvQL1Tw49zdScuUsfnNDjw7do5C9+4vl6XQYyg/V4FslFEa9Gsk5A7RUUejtfzowx9MOSIY ndfrVNGc5rHPOy+uyXrv5SPGKNH108VXtw5ggq+NZtFsI+1vapMZauz/kKfxPwwt4FTE6lyCbkDyo liujJVJw1mJ5xtTKr5vScoX8wv5/Zh9YtUgF5JnWpmbrPV3E1bpWGemHY741aU00FaNBSjVa0zpxW Gn3jJn8dAF+rnXve1/GyuDUYL1MP9oYe4U3NkDxFI2ph3xcS8MzPvDPRkshS4I+pN//d3n0y5C8pF yzYZbZX0g==;
Received: from hansfords.plus.com ([84.92.116.209]:32987 helo=[192.168.54.23]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1hEvBt-0001cn-HD; Fri, 12 Apr 2019 13:21:58 +0100
Date: Fri, 12 Apr 2019 13:15:22 +0100
From: Jonathan <jonathan@hansfords.net>
To: Martin Bjorklund <mbj@tail-f.com>, Per Hedeland <per@hedeland.org>
Cc: mferguson@amsl.com, bclaise@cisco.com, rob.enns@gmail.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org
Message-ID: <92cbd858-e49f-4d28-a81f-af55813c7e3c@Spark>
In-Reply-To: <fbc906bc-f003-417a-1113-0c4d6f213841@hedeland.org>
References: <20140113155326.2E4B97FC396@rfc-editor.org> <74C3A7F7-B338-4B9F-AD61-66F39EA43FC9@amsl.com> <34e64e9f-f3a0-9c4f-9860-e69e120e926c@hedeland.org> <20190221.142233.540619960445664842.mbj@tail-f.com> <fbc906bc-f003-417a-1113-0c4d6f213841@hedeland.org>
X-Readdle-Message-ID: 92cbd858-e49f-4d28-a81f-af55813c7e3c@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5cb082e1_327b23c6_16b2"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/MWlJEjQfzAEGCYhZS7xSMjXkQTg>
Subject: Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 12 Apr 2019 12:22:05 -0000

Re <persist> and <persist-id>, the point I was trying to get across is, since there can be a sequence of commits after a confirmed commit and before the final confirming commit, it would not necessarily be the last commit before session termination that makes the confirmed commit persistent. Perhaps "unless the last confirmed commit also included a <persist> or <persist-id> element" would be better worded as "unless the confirmed commit was persistent".

Jonathan

=O)
On 21 Feb 2019, 13:48 +0000, Per Hedeland <per@hedeland.org>;, wrote:
> On 2019-02-21 14:22, Martin Bjorklund wrote:
> > Hi,
> >
> > Per Hedeland <per@hedeland.org>; wrote:
> > > On 2019-02-20 01:44, Megan Ferguson wrote:
> > > > Jonathan and Benoit,
> > > > We have edited the "corrected text in this errata report as
> > > > suggested by Jonathan.
> > >
> > > I don't know if this change - i.e. the addition of the text "or
> > > <persist-id>" in two places - should affect the status of the
> > > document, but it seems to me that it can then no longer be considered
> > > a "clarification", since it proposes a change to the semantics
> > > specified in RFC 6241. As far as I can see, it is clear from 6241 that
> > > the presence of the <persist-id> parameter does not affect the
> > > persistence, only the presence of the <persist> parameter does that.
> >
> > Hmm, I missed this detail.
> >
> > It is clearly not correct to say that the <persist-id> affects
> > persistence. So s/or <persist-id>// in the 4th and 5th paragraphs.
>
> Hm, right, the remainder of the change to the 5th paragraph should be
> kept (I originally misread it as *only* adding "or <persist-id>" there
> too).
>
> > Do you see any other issues with the proposed text?
>
> No, it seems fine - a useful clarification.
>
> > (An editorial change - the 4th para should be split into two, just as
> > in the original text)
>
> +1
>
> --Per
>
> > /martin
> >
> >
> >
> >
> >
> >
> > >
> > > Furthermore, I'm afraid I fail to find any motivation for this change
> > > in the quoted message from Jonathan (as far as I can see, this message
> > > was not sent to the mailing list).
> > >
> > > --Per Hedeland
> > >
> > > > We have left the status of this report as Held for Document
> > > > Update.
> > > > Please let us know if any further action is necessary on our part.
> > > > The report itself is viewable at
> > > > https://www.rfc-editor.org/errata/eid3821.
> > > > Old (as in Jonathans original report):
> > > > If the session issuing a sequence of one or more
> > > > confirmed commits is terminated for any reason before the confirm
> > > > timeout expires, the server MUST restore the configuration to its
> > > > state before the sequence of confirmed commits was issued, unless
> > > > the last confirmed commit also included a <persist>
> > > > element.
> > > > If the device reboots for any reason before the confirm timeout
> > > > expires, the server MUST restore the configuration to its state
> > > > before the sequence of confirmed commits was issued.
> > > > New (as updated by Jonathans email - see the last line of both
> > > > paragraphs):
> > > > If the session issuing a sequence of one or more
> > > > confirmed commits is terminated for any reason before the confirm
> > > > timeout expires, the server MUST restore the configuration to its
> > > > state before the sequence of confirmed commits was issued, unless
> > > > the last confirmed commit also included a <persist> or <persist-id>
> > > > element.
> > > > If the device reboots for any reason before the confirm timeout
> > > > expires, the server MUST restore the configuration to its state
> > > > before the sequence of confirmed commits was issued, unless the last
> > > > confirmed commit also included a <persist> or <persist-id> element.
> > > > Thank you.
> > > > RFC Editor/mf
> > > >
> > > > > Hi,
> > > > > I raised erratum 3821 to clarify the meaning of the term "confirmed
> > > > > commit" for those not familiar with the use of the term within
> > > > > JUNOS. Both the original text and the erratum include text that states
> > > > > If the device reboots for any reason before the confirm timeout
> > > > > expires, the server MUST restore the configuration to its state before
> > > > > the sequence of confirmed commits was issued.. I have since
> > > > > discovered the description of the persist leaf on page 102 that
> > > > > includes the statement, A persistent confirmed commit is not aborted
> > > > > if the NETCONF session terminates. The only way to abort a persistent
> > > > > confirmed commit is to let the timer expire, or to use the
> > > > > <cancel-commit> operation. Consequently, the replacement text should
> > > > > read:
> > > > > 8.4.1. Description
> > > > > The :confirmed-commit:1.1 capability indicates that the server will
> > > > > support the <cancel-commit> operation, the <confirmed>, <confirm-
> > > > > timeout>, <persist>, and <persist-id> parameters for the <commit>
> > > > > operation, and differentiate between a to be confirmed <commit>
> > > > > operation (a confirmed commit) and a confirming <commit>
> > > > > operation. See Section 8.3 for further details on the <commit>
> > > > > operation.
> > > > > A confirmed <commit> operation MUST be reverted if a confirming
> > > > > commit is not issued within the timeout period (by default 600
> > > > > seconds = 10 minutes). The confirming commit is a <commit> operation
> > > > > without the <confirmed> parameter and, if successful, cannot be
> > > > > reverted. The timeout period can be adjusted with the <confirm-
> > > > > timeout> parameter. If a follow-up confirmed <commit> operation is
> > > > > issued before the timer expires, the timer is reset to the new value
> > > > > (600 seconds by default). Both the confirming commit and a follow-up
> > > > > confirmed <commit> operation MAY introduce additional changes to the
> > > > > configuration.
> > > > > If the <persist> element is not given in the confirmed commit
> > > > > operation, any follow-up commit and the confirming commit MUST be
> > > > > issued on the same session that issued the confirmed commit. If the
> > > > > <persist> element is given in the confirmed <commit> operation, a
> > > > > follow-up commit and the confirming commit can be given on any
> > > > > session, and they MUST include a <persist-id> element with a value
> > > > > equal to the given value of the <persist> element.
> > > > > If the server also advertises the :startup capability, a <copy-
> > > > > config> from running to startup is also necessary to save the
> > > > > changes to startup. If the session issuing a sequence of one or more
> > > > > confirmed commits is terminated for any reason before the confirm
> > > > > timeout expires, the server MUST restore the configuration to its
> > > > > state before the sequence of confirmed commits was issued, unless
> > > > > the last confirmed commit also included a <persist> or <persist-id>
> > > > > element.
> > > > > If the device reboots for any reason before the confirm timeout
> > > > > expires, the server MUST restore the configuration to its state
> > > > > before the sequence of confirmed commits was issued, unless the last
> > > > > confirmed commit also included a <persist> or <persist-id> element.
> > > > > If a confirming commit is not issued, the device will revert its
> > > > > configuration to the state prior to the issuance of the first in the
> > > > > current sequence of confirmed commits. To cancel the current
> > > > > sequence of confirmed commits and revert changes without waiting for
> > > > > the confirm timeout to expire, the client can explicitly restore the
> > > > > configuration to its state before the sequence of confirmed commits
> > > > > was issued, by using the <cancel-commit> operation.
> > > > > Jonathan Hansford
> > > > On Jan 13, 2014, at 7:53 AM, RFC Errata System
> > > > <rfc-editor@rfc-editor.org>; wrote:
> > > >
> > > > > The following errata report has been held for document update
> > > > > for RFC6241, "Network Configuration Protocol (NETCONF)".
> > > > >
> > > > > --------------------------------------
> > > > > You may review the report below and at:
> > > > > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821
> > > > >
> > > > > --------------------------------------
> > > > > Status: Held for Document Update
> > > > > Type: Editorial
> > > > >
> > > > > Reported by: Jonathan Hansford <jonathan@hansfords.net>;
> > > > > Date Reported: 2013-12-06
> > > > > Held by: Benoit Claise (IESG)
> > > > >
> > > > > Section: 8.4.1
> > > > >
> > > > > Original Text
> > > > > -------------
> > > > > 8.4.1. Description
> > > > >
> > > > > The :confirmed-commit:1.1 capability indicates that the server will
> > > > > support the <cancel-commit> operation and the <confirmed>,
> > > > > <confirm-timeout>, <persist>, and <persist-id> parameters for the
> > > > > <commit> operation. See Section 8.3 for further details on the
> > > > > <commit> operation.
> > > > >
> > > > > A confirmed <commit> operation MUST be reverted if a confirming
> > > > > commit is not issued within the timeout period (by default 600
> > > > > seconds = 10 minutes). The confirming commit is a <commit> operation
> > > > > without the <confirmed> parameter. The timeout period can be
> > > > > adjusted with the <confirm-timeout> parameter. If a follow-up
> > > > > confirmed <commit> operation is issued before the timer expires, the
> > > > > timer is reset to the new value (600 seconds by default). Both the
> > > > > confirming commit and a follow-up confirmed <commit> operation MAY
> > > > > introduce additional changes to the configuration.
> > > > >
> > > > > If the <persist> element is not given in the confirmed commit
> > > > > operation, any follow-up commit and the confirming commit MUST be
> > > > > issued on the same session that issued the confirmed commit. If the
> > > > > <persist> element is given in the confirmed <commit> operation, a
> > > > > follow-up commit and the confirming commit can be given on any
> > > > > session, and they MUST include a <persist-id> element with a value
> > > > > equal to the given value of the <persist> element.
> > > > >
> > > > > If the server also advertises the :startup capability, a
> > > > > <copy-config> from running to startup is also necessary to save the
> > > > > changes to startup.
> > > > >
> > > > > If the session issuing the confirmed commit is terminated for any
> > > > > reason before the confirm timeout expires, the server MUST restore
> > > > > the configuration to its state before the confirmed commit was
> > > > > issued, unless the confirmed commit also included a <persist>
> > > > > element.
> > > > >
> > > > > If the device reboots for any reason before the confirm timeout
> > > > > expires, the server MUST restore the configuration to its state
> > > > > before the confirmed commit was issued.
> > > > >
> > > > > If a confirming commit is not issued, the device will revert its
> > > > > configuration to the state prior to the issuance of the confirmed
> > > > > commit. To cancel a confirmed commit and revert changes without
> > > > > waiting for the confirm timeout to expire, the client can explicitly
> > > > > restore the configuration to its state before the confirmed commit
> > > > > was issued, by using the <cancel-commit> operation.
> > > > >
> > > > > Corrected Text
> > > > > --------------
> > > > > 8.4.1. Description
> > > > >
> > > > > The :confirmed-commit:1.1 capability indicates that the server will
> > > > > support the <cancel-commit> operation, the <confirmed>, <confirm-
> > > > > timeout>, <persist>, and <persist-id> parameters for the <commit>
> > > > > operation, and differentiate between a to be confirmed <commit>
> > > > > operation (a confirmed commit) and a confirming <commit>
> > > > > operation. See Section 8.3 for further details on the <commit>
> > > > > operation.
> > > > >
> > > > > A confirmed <commit> operation MUST be reverted if a confirming
> > > > > commit is not issued within the timeout period (by default 600
> > > > > seconds = 10 minutes). The confirming commit is a <commit> operation
> > > > > without the <confirmed> parameter and, if successful, cannot be
> > > > > reverted. The timeout period can be adjusted with the <confirm-
> > > > > timeout> parameter. If a follow-up confirmed <commit> operation is
> > > > > issued before the timer expires, the timer is reset to the new value
> > > > > (600 seconds by default). Both the confirming commit and a follow-up
> > > > > confirmed <commit> operation MAY introduce additional changes to the
> > > > > configuration.
> > > > >
> > > > > If the <persist> element is not given in the confirmed commit
> > > > > operation, any follow-up commit and the confirming commit MUST be
> > > > > issued on the same session that issued the confirmed commit. If the
> > > > > <persist> element is given in the confirmed <commit> operation, a
> > > > > follow-up commit and the confirming commit can be given on any
> > > > > session, and they MUST include a <persist-id> element with a value
> > > > > equal to the given value of the <persist> element.
> > > > >
> > > > > If the server also advertises the :startup capability, a <copy-
> > > > > config> from running to startup is also necessary to save the
> > > > > changes to startup. If the session issuing a sequence of one or more
> > > > > confirmed commits is terminated for any reason before the confirm
> > > > > timeout expires, the server MUST restore the configuration to its
> > > > > state before the sequence of confirmed commits was issued, unless
> > > > > the last confirmed commit also included a <persist> element.
> > > > >
> > > > > If the device reboots for any reason before the confirm timeout
> > > > > expires, the server MUST restore the configuration to its state
> > > > > before the sequence of confirmed commits was issued.
> > > > >
> > > > > If a confirming commit is not issued, the device will revert its
> > > > > configuration to the state prior to the issuance of the first in the
> > > > > current sequence of confirmed commits. To cancel the current
> > > > > sequence of confirmed commits and revert changes without waiting for
> > > > > the confirm timeout to expire, the client can explicitly restore the
> > > > > configuration to its state before the sequence of confirmed commits
> > > > > was issued, by using the <cancel-commit> operation.
> > > > >
> > > > > Notes
> > > > > -----
> > > > > This erratum seeks to clarify the meaning of the term "confirmed
> > > > > commit" for those not familiar with the use of the term within
> > > > > JUNOS. In particular, that the use of "confirmed" is not in the sense
> > > > > of the adjective (meaning "firmly established") but rather that the
> > > > > commit needs to be confirmed. It also emphasises that a "confirming
> > > > > commit" cannot be reverted. Finally it identifies that it is possible
> > > > > to have a sequence of "confirmed commits" prior to a "confirming
> > > > > commit" and that, should no "confirming commit" be received, the
> > > > > configuration will revert to the state prior to the first "confirmed
> > > > > commit" in the sequence.
> > > > >
> > > > > --------------------------------------
> > > > > RFC6241 (draft-ietf-netconf-4741bis-10)
> > > > > --------------------------------------
> > > > > Title : Network Configuration Protocol (NETCONF)
> > > > > Publication Date : June 2011
> > > > > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed.,
> > > > > A. Bierman, Ed.
> > > > > Category : PROPOSED STANDARD
> > > > > Source : Network Configuration
> > > > > Area : Operations and Management
> > > > > Stream : IETF
> > > > > Verifying Party : IESG
> > > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>