Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)
Per Hedeland <per@hedeland.org> Thu, 21 February 2019 13:47 UTC
Return-Path: <per@hedeland.org>
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 235E8130FD4 for <netconf@ietfa.amsl.com>; Thu, 21 Feb 2019 05:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
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 lWd9hjEMO8bk for <netconf@ietfa.amsl.com>; Thu, 21 Feb 2019 05:47:55 -0800 (PST)
Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (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 45252130FCF for <netconf@ietf.org>; Thu, 21 Feb 2019 05:47:54 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1550756871; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=L5CrDn9n+FPRxgJQEv2Y0cBPpK/07rrQuLL7+VHiVR0lMnmTkdQBOpeS+CPnJvuusEw+1CH58jI0j iEt1ztJ0vGN9Kw0ewM/MHNKD1jjkiBrUNeakHqSKA6qgp8d46b8NWwAbBA6ih1wbWr3BBlHQ/5xsvA qwoCTXvu8EtHPbJw/6XzUGEvzH4bKJoahWdYoO+R4wt747+GVEf2HNPsmUbeKGEVq/aGsDng2PnCxp zQCUV3lrHO5N6zbjNIY94bC2E1SMFAWHAWtdC19KCwhzXKnbd42UMKztT4sfJO6E/vTvjyN5VTGzgo hZx9FKnDPyvSgyUgLneS1F2NhN7aPzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=QUNY4hfvP4KTFfOru5XngiiOU8Tia6HDWmX1JhG/JlU=; b=WbFmGSdEAdfs1tEAOaGUNU0NiJEec8lhH888Shu3QqMlMr0zK/1dVFDyzzNOGhg3t2Gf7UMsNl3l/ px03mzTSZajx6ORUOL66q+FRpEJYE+AbpkvE1HzweHc6dNCKpC7CziPgOeFGhCFKaZUKxBmbj1AAA1 q3DXdevD59aNz2dHJDdo4nAtLqqma1RclmNl6W+HfBClu/pKwrn6n7sCshimMBIxJCeCCFPKYZ61Ao 1c7gHullzI5AYsqiOvblo8mfR3quNd1BCg184O4ARZBCy1qfMfOk2t4ZGCJPMAHilMfq73EY0C7KAS +78dZ/iD27iEmJFVt9A5ftFuUDYwquQ==
ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=QUNY4hfvP4KTFfOru5XngiiOU8Tia6HDWmX1JhG/JlU=; b=OTrWNCEyvgmAXL9qUQjQPLiKaNbRJl+RYbdfAe4NMWVnGH2IAAjMXS8fG2fwZDu7zFPe2jHB596jw 9Ua/AT2+OvogR5XHEVP6NkJ5m1K6f3RPXA18e0LoAhqYAL97gi4rWsolPwKHxn998zgAlhSAeUX3A9 X2uQ9TxM96qCUEXdihK6kg9XaL9Dp1Y3WUYyKmB8Eqm9LQGP4PpJX5UEyvZx/LnRsdW2DN2ogdYtdS R9MdRSUI2vcW/ghKYZY7xcWH1E8mCkE8FUaJ8f6a/afsgQzEYnB1hUI7PHzi8QndUdy+4uAtdEd1BQ 4iMsjigfYAU+zpl2dIlFs11CJwoFkiA==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 42677d4b-35df-11e9-908b-352056dbf2de
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 42677d4b-35df-11e9-908b-352056dbf2de; Thu, 21 Feb 2019 13:47:45 +0000 (UTC)
Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x1LDlfkA090575 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Feb 2019 14:47:41 +0100 (CET) (envelope-from per@hedeland.org)
To: Martin Bjorklund <mbj@tail-f.com>
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
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>
From: Per Hedeland <per@hedeland.org>
Message-ID: <fbc906bc-f003-417a-1113-0c4d6f213841@hedeland.org>
Date: Thu, 21 Feb 2019 14:47:41 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190221.142233.540619960445664842.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/im-N-GMX3bpe3eEntD4qDtr4DfE>
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:47:59 -0000
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 >>
- [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