Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)

[Jonathan Hansford <[e-mail]>]

 

On 2013-12-10 17:05, Andy Bierman wrote: 

> On Tue, Dec 10, 2013 at
8:26 AM, Jonathan Hansford <[e-mail] [2]> wrote:
> 
>> On
2013-12-10 16:15, Andy Bierman wrote: 
>> 
>>> On Tue, Dec 10, 2013 at
8:05 AM, Jonathan Hansford <[e-mail] [1]> wrote:
>>> 
>>>>
On 2013-12-10 15:59, Andy Bierman wrote: 
>>>> 
>>>>> Hi, 
>>>>> I don't
think these 3 reports are corrections. 
>>>>> They are editorial changes
to the text. 
>>>>> I don't agree that the new terminology added
"sequence of confirmed commits" 
>>>>> is correct. There is just 1
netconf-confirmed-commit notification for start & complete 
>>>>> sent
out no matter how how many times the procedure is extended. 
>>>>>

>>>>> If the procedure ends with a cancel or timeout, there is only 1
original commit 
>>>>> that is restored. It is incorrect to think of
this procedure as a series of 
>>>>> confirmed commits. A commit that
extends the procedure is not treated 
>>>>> the same as the commit that
starts the procedure.
>>>> 
>>>> Are you saying that the initial commit
of the sequence (the confirmed commit?) is restored should the procedure
be cancelled or timeout? Surely the commit that is restored is the one
that preceded the confirmed commit.
>>> 
>>> The confirmed commit is the
first <commit> that includes a <confirmed> parameter. 
>>> The 2nd - Nth
<commit> are extending the first commit operation. The server is still

>>> obligated to revert the running config for the first commit (if it
is canceled or timed out). 
>>> This obligation is not removed because
the commit is extended. It is only removed 
>>> if a confirming commit
is received.
>> 
>> Andy, 
>> I'm not sure whether we agreeing or not.
Section 8.4.1 of RFC6241 (2nd paragraph) talks about 'a follow-up
confirmed <commit> operation'. Are you saying that that second
'confirmed <commit>' (i.e. a <commit> with the <confirmed> parameter) is
not a "confirmed commit"? And when you say 'the server is obligated to
revert the running config for the first commit' do you mean revert to
the state prior to that first confirmed <commit>?
> 
> sec. 8.4.1, para
2: 
> 
> The confirming commit is a <commit> operation
> without the
<confirmed> parameter. 
> 
> The 2nd commit with a <confirmed> parameter
extends the confirmed-commit procedure. 
> Any cancel or complete
applies to this commit. If canceled, then the changes made for the 
>
2nd commit are going to be undone. An extension commit is not a
confirming commit. 
> A cancel/timeout causes the config to revert to
its state before the first confirmed commit 
> operation. 
> 
>>
Jonathan
> 
> Andy

Andy, 
What I think you seem to be stating here is
that there are three types of commit (and possibly, by extension, four):


 	* "Confirmed commit" - the first successful commit with a
<confirmed> parameter after a successful commit without a <confirmed>
parameter
 	* "Extension commit" - any commit with a <confirmed>
parameter after a "confirmed commit" and before any successful
"confirming commit"
 	* "Confirming commit" - any commit without a
<confirmed> parameter after a "confirmed commit" and before any other
successful "confirming commit"
 	* "Standard commit" - any commit
without a <confirmed> parameter after a successful "confirming commit"
and before a subsequent "confirmed commit"

By those definitions a
"confirmed commit" cannot follow another "confirmed commit" without an
intervening "confirming commit". Yet 8.4.5.1 talks about follow-up
"confirmed commits" and "confirming commits". How can there be a
follow-up "confirmed commit", unless the definition of a "confirmed
commit" becomes something like: 

(the first commit with a <confirmed>
parameter after a successful commit without a <confirmed> parameter) OR
(the first successful commit with a <confirmed> parameter from another
session and the appropriate <persist-id>) 

Also, 8.4.5.1 states the
<persist> parameter makes the "confirmed commit" survive a session
termination. Does that mean the <persist-id> parameter can only be
successful if the original session has been terminated, or is it more
accurate to state that the <persist> parameter allows the "confirmed
commit" to be extended by other sessions, whether or not the original
session has been terminated? 

Thanks, 

Jonathan 

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