[netconf] [Technical Errata Reported] RFC6241 (5790)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 23 July 2019 14:58 UTC
Return-Path: <wwwrun@rfc-editor.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 3DC5512011D for <netconf@ietfa.amsl.com>; Tue, 23 Jul 2019 07:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yoYAKBybG7nf for <netconf@ietfa.amsl.com>; Tue, 23 Jul 2019 07:58:06 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402581200F8 for <netconf@ietf.org>; Tue, 23 Jul 2019 07:58:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 242B2B80D34; Tue, 23 Jul 2019 07:57:56 -0700 (PDT)
To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, ibagdona@gmail.com, warren@kumari.net, kent+ietf@watsen.net, mjethanandani@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mjethanandani@gmail.com, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190723145756.242B2B80D34@rfc-editor.org>
Date: Tue, 23 Jul 2019 07:57:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/CALAgup7cwGnGPWppqP4B83oT0E>
Subject: [netconf] [Technical Errata Reported] RFC6241 (5790)
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: Tue, 23 Jul 2019 14:58:08 -0000
The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5790 -------------------------------------- Type: Technical Reported by: Mahesh Jethanandani <mjethanandani@gmail.com> Section: GLOBAL Original Text ------------- OLD: 7.8. <close-session> Description: Request graceful termination of a NETCONF session. When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a <close-session> request will be ignored. Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason. Example: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session/> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> NEW 7.8. <close-session> Description: Request graceful termination of a NETCONF session. When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a <close-session> request will be ignored. For details on what happens if a NETCONF server receives a <close-session> request while processing a confirmed commit, please refer to Section 8.4. Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason. Example: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session/> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> OLD 7.9. <kill-session> Description: Force the termination of a NETCONF session. When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it MUST restore the configuration to its state before the confirmed commit was issued. Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock. Parameters: session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an "invalid-value" error is returned. Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason. Example: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>4</session-id> </kill-session> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> NEW 7.9. <kill-session> Description: Force the termination of a NETCONF session. When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. For details on what happens if a NETCONF server receives a <kill-session> request while processing a confirmed commit, please refer to Section 8.4. Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock. Parameters: session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an "invalid-value" error is returned. Positive Response: If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason. Example: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>4</session-id> </kill-session> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> Section 8.4.1 OLD: 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. NEW: 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, unless the confirmed commit also included a <persist> element, in which case the server MAY continue the confirmed commit procedure. Corrected Text -------------- Notes ----- This Errata modifies three different sections, Sections 7.8, 7.9 and 8.4.1. The changes in Section 7.8 and 7.9 defer the description of the behavior of confirmed commit to Section 8.4.1. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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] [Technical Errata Reported] RFC6241 (57… RFC Errata System