[Netconf] Fwd: [Errata Held for Document Update] RFC6241 (3821)

[Benoit Claise <[e-mail]>]

Dear all,

There was much discussion on this errata, but no perfect text proposed 
AFAICT.
It's now in the "Editorial", "Held for Document Update"

 From http://www.ietf.org/iesg/statement/errata-processing.html:

    *Hold for Document Update* - The erratum is not a necessary update
    to the RFC. However, any future update of the document might
    consider this erratum, and determine whether it is correct and
    merits including in the update. 

The exact text might be discussed further in the WG when/if a bis 
document is worked on, or in an implementation guideline.

Regards, Benoit


-------- Original Message --------
Subject: 	[Errata Held for Document Update] RFC6241 (3821)
Date: 	Mon, 13 Jan 2014 07:53:26 -0800
From: 	RFC Errata System <[e-mail]>
To: 	<[e-mail]>, <[e-mail]>, <[e-mail]>, 
<[e-mail]>, <[e-mail]>
CC: 	<[e-mail]>, <[e-mail]>, <[e-mail]>, 
<[e-mail]>



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 <[e-mail]>
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

.