Re: [Netconf] Confirmed commit

[Andy Bierman <[e-mail]>]

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.


Andy



On Thu, Sep 19, 2013 at 1:15 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Thu, Sep 19, 2013 at 09:07:17PM +0100, Jonathan Hansford wrote:
> >
> >
> > After about two hours digging around in the NETCONF archive and then
> > a Google search on "confirmed commit", I've come to the conclusion
> > confirmed commit has come out of the JUNOS "commit confirmed" command.
> > My guess is the JUNOS command is shorthand for "revert this commit after
> > the timeout unless it is confirmed"; not exactly clear. Indeed, I would
> > have thought "commit confirmed" would be the command to confirm the
> > previous commit, though obviously that would overload the meaning of the
> > original "commit" command since it would not persist without the
> > confirmation.
> >
> > But "confirmed commit" implies the commit has been
> > confirmed, not that it needs to be confirmed. Isn't this confusing to
> > anyone else?
>
> There is the ':confirmed-commit' capability, there is the 'confirming
> commit' and there is the initial commit which is sometimes called the
> 'confirmed commit'. I assume it is this last one term you believe is
> confusing since it is the 'to be confirmed commit'. Perhaps we could
> have picked a better term - but as long as the description is clear
> (section 8.4 of RFC 6241), I think we are in a good enough state.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>