Re: [Netconf] Confirmed commit

["Bert Wijnen (IETF)" <[e-mail]>]

Speaking as a technical contributor.

I also think we should stick to the terminology we have been using for
many years now. So I was thinking more about some clarifying or explanatory
text instead of renaming our terminology.

Bert

On 9/20/13 12:57 PM, 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
>
>
> Jonathan Hansford <[e-mail]> 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]
>