[netconf] [Errata Rejected] RFC6241 (5596)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 19 October 2019 14:31 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 2E1DA12002F; Sat, 19 Oct 2019 07:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Rs72nzxB3X-G; Sat, 19 Oct 2019 07:31:29 -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 61D1F120013; Sat, 19 Oct 2019 07:31:29 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 22111B80C7F; Sat, 19 Oct 2019 07:31:24 -0700 (PDT)
To: jonathan@hansfords.net, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ibagdona@gmail.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20191019143124.22111B80C7F@rfc-editor.org>
Date: Sat, 19 Oct 2019 07:31:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/p0cZx8gJKdCucN-3lPV9Fo4UloQ>
Subject: [netconf] [Errata Rejected] RFC6241 (5596)
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: Sat, 19 Oct 2019 14:31:31 -0000

The following errata report has been rejected for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5596

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Jonathan Hansford <jonathan@hansfords.net>
Date Reported: 2019-01-09
Rejected by: Ignas Bagdonas (IESG)

Section: 7.5

Original Text
-------------
      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport.

Corrected Text
--------------
      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport. Note that a lock
      associated with a persistent confirmed commit will be released if
      the NETCONF session closes and, if required, a new lock will have
      to be acquired.

Notes
-----
A persistent confirmed commit can survive a session termination, however any lock on that same session cannot. If a new session is established between the client and server, the client will need to acquire new locks if it wishes to protect the ongoing persistent confirmed commit.
 --VERIFIER NOTES-- 
   Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/lNr91W5aK-abxDaqzadftjoE2Pg



--------------------------------------
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