Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)
Martin Bjorklund <mbj@tail-f.com> Thu, 21 February 2019 13:22 UTC
Return-Path: <mbj@tail-f.com>
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 9A4AE130FCF; Thu, 21 Feb 2019 05:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pB48LUthARLg; Thu, 21 Feb 2019 05:22:38 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8EA130FA5; Thu, 21 Feb 2019 05:22:37 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 32CD41AE00A0; Thu, 21 Feb 2019 14:22:33 +0100 (CET)
Date: Thu, 21 Feb 2019 14:22:33 +0100
Message-Id: <20190221.142233.540619960445664842.mbj@tail-f.com>
To: per@hedeland.org
Cc: mferguson@amsl.com, jonathan@hansfords.net, bclaise@cisco.com, rob.enns@gmail.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <34e64e9f-f3a0-9c4f-9860-e69e120e926c@hedeland.org>
References: <20140113155326.2E4B97FC396@rfc-editor.org> <74C3A7F7-B338-4B9F-AD61-66F39EA43FC9@amsl.com> <34e64e9f-f3a0-9c4f-9860-e69e120e926c@hedeland.org>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/hcA39uyw5L-SAL9fMvwfXEiFkLI>
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: Thu, 21 Feb 2019 13:22:42 -0000
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. Do you see any other issues with the proposed text? (An editorial change - the 4th para should be split into two, just as in the original text) /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 >
- [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