Re: [Netconf] Confirmed commit

[Jonathan Hansford <[e-mail]>]

 

Hi, 

I agree that changing the terminology would be confusing for
those who are used to it, but in its current form it is extremely
confusing to those who come to it cold. To my mind there needs, at
least, to be something that seeks to explain the current terminology. It
has taken me several readings, a trawl of the NETCONF list archive and
Internet search to reach some kind of understanding and even then it had
to be confirmed by someone "in the know". 

However, putting that to one
side for now, my text without the changed terminology becomes: 

8.4.1.
Description (paras 2-6)
A <commit> operation with the <confirmed>
parameter (an unconfirmed <commit>) 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 unconfirmed <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 unconfirmed <commit>
operation MAY introduce additional changes to the configuration.
If the
<persist> element is not given in the unconfirmed commit operation, any
follow-up commit and the confirming commit MUST be issued on the same
session that issued the unconfirmed commit. If the <persist> element is
given in the unconfirmed <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 unconfirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its state
before the sequence of unconfirmed commits was issued, unless the last
unconfirmed 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
unconfirmed 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 unconfirmed commits. To
cancel the current sequence of unconfirmed 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
unconfirmed commits was issued, by using the <cancel-commit>
operation.
:
8.4.4.1. <cancel-commit>
Description:
Cancels an ongoing
sequence of unconfirmed commits. If the <persist-id> parameter is not
given, the <cancel-commit> operation MUST be issued on the same session
that issued the sequence of unconfirmed
commits.
Parameters:
persist-id:
Cancels a persistent sequence of
unconfirmed commits. The value MUST be equal to the value given in the
<persist> parameter to the <commit> operation. If the value does not
match, the operation fails with an "invalid-value" error.
:
8.4.5.1.
<commit>
The :confirmed-commit:1.1 capability allows 4 additional
parameters to the <commit> operation.
Parameters:
confirmed:
Perform an
unconfirmed <commit> operation.
confirm-timeout:
Timeout period for
confirmed commit, in seconds. If unspecified, the confirm timeout
defaults to 600 seconds.
persist:
Make the unconfirmed commit survive a
session termination, and set a token on the ongoing sequence of
unconfirmed commits.
persist-id:
Used to issue a follow-up unconfirmed
commit or a confirming commit from any session, with the token from the
previous <commit> operation. 

Jonathan 

On 2013-09-20 11:57, Martin
Bjorklund wrote: 

> Hi,
> 
> I don't think we should change the
terminology in an errata.
> (and actually I don't think we should change
it at all - I agree there
> might be a better term, but the term
"confirmed commit" has been used
> for several years and people are used
to it)
> 
> Your text about sequence of commits is fine; but I think we
should
> stick to the current terminology.
> 
> /martin