[Netconf] [Technical Errata Reported] RFC6241 (3821)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Jonathan Hansford <[e-mail]>

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


Instructions:
-------------
This errata 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 (IESG)
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