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

[Martin Bjorklund <[e-mail]>]

Hi,

I agree w/ Andy.  The current text is correct, but can be improved
(clearer).


/martin



Andy Bierman <[e-mail]> wrote:
> Hi,
> 
> 
> On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh <[e-mail]> wrote:
> 
> > 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.
> >
> >
> >
> 
> 
> What are the implementation differences that the spec allows?
> 
> 
> 
> > The clarification text seems to be modifying what a conformant
> > implementation must do, and obviously the WG members haven$B!G(Bt reached
> > consensus on just what that must be.
> >
> >
> >
> 
> I do not agree that there is WG consensus to accept the errata -- the
> discussion seems to show
> that the term "confirmed commit" is used to refer to the entire procedure
> and to a specific
> form of a <commit> request.   There is no text that is clearly in error.
> 
> I don't think consensus has been established that different implementations
> of confirmed commit
> are possible.  The draft is clear about the definition of a confirming
> commit, and also clear
> what ends a confirmed commit procedure.
> 
> 
> If the clarification becomes part of conformance requirements, then
> > existing implementations would likely become non-conformant.
> >
> > To me, that says a $(Q#|(Bbis is called for, including WGLC and IETF LCs, to
> > change the conformance requirements of the standard.
> >
> 
> 
> Can you describe this non-conformance that needs to be fixed with a new RFC?
> It seems to me (and other implementors) that restoring the running config to
> its state before the first confirmed commit <rpc> request is the correct
> behavior.
> 
> I do not agree that the current RFC text allows an interpretation that
> permits the
> server to treat a <commit> with a <confirmed> element as a confirming
> commit.
> Only a timeout, <cancel-commit> or confirming commit can release the server
> from its obligation to revert the saved state.
> 
> 
> 
> >
> >
> > 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
> >
> > [e-mail]
> >
> > [phone]
> >
> 
> 
> 
> Andy
> 
> 
> 
> > *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
> >
> >
> >