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

["ietfdbh" <[e-mail]>]

Hi,

 

This thread about an errata says to me that implementers could implement the
original text in different ways and be conformant to the standard. 

 

The clarification text seems to be modifying what a conformant
implementation must do, and obviously the WG members haven't reached
consensus on just what that must be. 

 

If the clarification becomes part of conformance requirements, then existing
implementations would likely become non-conformant. 

To me, that says a -bis is called for, including WGLC and IETF LCs, to
change the conformance requirements of the standard.

 

I am not implementing this standard, so maybe I misjudge whether this
affects existing implementations or not. Please let me know if I am looking
at this incorrectly.

 

David Harrington

 <mailto:[e-mail]> [e-mail]

[phone]

From: Netconf [mailto:[e-mail]] On Behalf Of Andy Bierman
Sent: Thursday, December 12, 2013 11:57 AM
To: Jonathan Hansford
Cc: Rob Enns; joel jaeggli; Netconf
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)

 

 

 

On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford <[e-mail]>
wrote:

 

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

 

 

On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <[e-mail]>
wrote:

On 2013-12-10 16:15, Andy Bierman wrote:

 

 

On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <[e-mail]>
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):

1.	"Confirmed commit" - the first successful commit with a <confirmed>
parameter after a successful commit without a <confirmed> parameter
2.	"Extension commit" - any commit with a <confirmed> parameter after a
"confirmed commit" and before any successful "confirming commit"
3.	"Confirming commit" - any commit without a <confirmed> parameter
after a "confirmed commit" and before any other successful "confirming
commit"
4.	"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>)

 

 

 

The saved state that that gets reverted if the commit is not confirmed does
not change

because anther commit with a <confirmed> element is received.  This 2nd
commit that

is extending the confirmed commit procedure is clearly not a confirming
commit, so

the server cannot update the saved state that will be reverted if necessary.

 

The terminology does not distinguish very well between the confirmed commit
procedure

and a <rpc> request that is called a confirmed commit.  There is only 1
confirmed commit

procedure active at any given time.  The 2nd confirmed commit <rpc> request
does not end

the first procedure and start a new one.  Once the procedure is ended
somehow,

then it ends for all the confirmed commit requests that are pending.

 

 

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?

 

No -- any session that knows the correct persist-id can complete the
procedure,

including any session that sent a confirmed commit <rpc> request.

 

 

Thanks,

Jonathan

 

Andy