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: 3821
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13
Section 8.4.1 says:
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.
It should say:
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> or <persist-id> 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, unless the last confirmed commit also included a <persist> or <persist-id> element. 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.