Re: [Netconf] Confirmed commit

[Martin Bjorklund <[e-mail]>]

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]