RFC Errata
RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011
Note: This RFC has been updated by RFC 7803, RFC 8526
Source of RFC: netconf (ops)
Errata ID: 5596
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2019-01-09
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-19
Section 7.5 says:
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.
It should say:
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