Re: [Netconf] Confirmed commit

[Jonathan Hansford <[e-mail]>]

 

I realise these changes have a knock-on impact on other parts of the
document (e.g. Appendices C and E), but I thought it important to try
and propose core changes before visiting those other sections. 

On
2013-09-20 11:29, Jonathan Hansford wrote: 

> I propose the following
changes to address Andy's issue relating to consecutive confirmed
commits and my issue relating to the confusing terminology: 
> 
> 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.
> 
>
On 2013-09-20 11:08, Bert Wijnen (IETF) wrote: 
> 
>> THat is one (and
probably good) approach.
>> 
>> So can the authors/experts suggest some
text that makes
>> sense as a fix (or better clarification) to a
possible
>> erratum?
>> 
>> Bert
>> 
>> On 9/20/13 10:00 AM, Jonathan
Hansford wrote:
>> 
>>> Would it be worth agreeing text online then
raising an erratum? Sent from my BlackBerry -----Original Message-----
From: "Bert Wijnen (IETF)" <[e-mail] [1]> Date: Fri, 20 Sep
2013 08:41:42 To: Andy Bierman<[e-mail] [2]>; Jonathan
Hansford<[e-mail] [3]>; Netconf<[e-mail] [4]>
Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 7:13
AM, Juergen Schoenwaelder wrote: 
>>> 
>>>> On Thu, Sep 19, 2013 at
01:39:28PM -0700, Andy Bierman wrote: 
>>>> 
>>>>> Hi, I always found
section 8.4.1, para 2 confusing. T0: /int8.1 does not exist 
>>>>>

>>>>>> merge /int8.1 value=20 commit confirmed confirm-timeout=60
>>>>>
T1: /int8.1 = 20 merge /int8.1 value=30 commit confirmed
confirm-timeout=60 T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If
a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the confirmed
commit. The problem is that there are 2 confirmed commit operations. At
time T3 does the server go back to state T1 or T0? (Our server goes back
to T0). The 2nd commit contains a confirmed parameter, and para 2
sentence 2 clearly says this is not a confirming commit. The text does
not actually define a "confirmed commit", but I assume it is a commit
with a confirmed parameter. Therefore, paragraphs 5 - 7 are wrong where
they refer to "the confirmed commit", because there are 2 of them.
>>>>
Yes, this corner case where multiple confirmed commits are issued is not
described well. Your interpretation that subsequent confirmed commits
effectively extend the first one makes sense to me.
>>> Can wee keep
this somewhere so we clarify it if we ever have to open up and update
the document? Bert 
>>> 
>>>> /js
 

Links:
------
[1]
mailto:[e-mail]
[2] mailto:[e-mail]
[3]
mailto:[e-mail]
[4] mailto:[e-mail]