Subject: [Netconf] Confirmed commit

From: Jonathan Hansford <[email-masked]>
Date: Thu, 19 Sep 2013 13:41:29 +0100

Hi, 

I am writing an Interface Definition Document that references
NETCONF but am struggling to explain the terminology surrounding
confirmed and confirming commits. From my reading, the difference
between a confirmed commit and a confirming commit is the latter
effectively marks the end of a transaction (running configuration cannot
be rolled back beyond the last confirming commit). Consequently, it
seems to me that a "confirmed commit" would be better described as an
"unconfirmed commit" since it is not confirmed until followed by a
"confirming commit". Can someone explain the choice of the current
terminology and correct any erroneous assumptions I have made? 

Thanks,

Jonathan

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 19 Sep 2013 21:07:17 +0100

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? 

Jonathan 

On 2013-09-19 13:41, Jonathan Hansford wrote:

> Hi, 
> 
> I am writing an Interface Definition Document that
references NETCONF but am struggling to explain the terminology
surrounding confirmed and confirming commits. From my reading, the
difference between a confirmed commit and a confirming commit is the
latter effectively marks the end of a transaction (running configuration
cannot be rolled back beyond the last confirming commit). Consequently,
it seems to me that a "confirmed commit" would be better described as an
"unconfirmed commit" since it is not confirmed until followed by a
"confirming commit". Can someone explain the choice of the current
terminology and correct any erroneous assumptions I have made? 
Thanks,

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 19 Sep 2013 16:15:04 -0400

I am familiar with the Juniper 'commit confirmed' command which means exactly what you guessed it means (you type in 'commit confirmed [timeout]' and then if you aren't kicked off the box, you type in 'commit' to confirm the commit otherwise it reverts back).

So to answer your question, having 'confirming' commit as well as 'confirmed commit' is rather confusing, esp to someone who is unfamiliar with one or both cases and has to make assumptions.

From: [email-masked]<[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 19, 2013
Subject: Re: [Netconf] Confirmed commit

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?

Jonathan

Hi,

I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made?

Thanks,

Jonathan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Sep 2013 22:15:18 +0200

> confirmed, not that it needs to be confirmed. Isn't this confusing to

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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 19 Sep 2013 21:23:26 +0100

On 2013-09-19 21:15, Juergen Schoenwaelder wrote:

>> a
>> Google search on "confirmed commit", I've come to the conclusion
>> 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

Thanks, you have confirmed (no pun intended) my reading of the RFC and 
I will use your definition of it being a 'to be confirmed commit' in my 
document.

Jonathan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Sep 2013 13:39:28 -0700

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 <
[email-masked]> wrote:

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Sep 2013 07:13:15 +0200

> 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.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 20 Sep 2013 08:41:42 +0200

See at bottom

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 20 Sep 2013 08:48:08 +0200 (CEST)

> commits effectively extend the first one makes sense to me.

+1

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 20 Sep 2013 12:08:15 +0200

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)" <[email-masked]>
> Date: Fri, 20 Sep 2013 08:41:42
> To: Andy Bierman<[email-masked]>; Jonathan Hansford<[email-masked]>; Netconf<[email-masked]>