Subject: [Netconf] confirmed-commit bug in RFC 6241?

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2012 07:57:35 -0700

Hi,

Just wondering about some confirmed-commit text in 6241:

7.2, para 2:

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

Really?

It doesn't say that this is only done if it is the session that issued
the confirmed commit.
It also is not correct if the <persist> parameter was provided in the
commit that
started (or continued) the confirmed commit procedure.
I think we missed this edit in the 4741 -> 6241 rewrite.

I also think 8.4.1 could be more clear that commits from other sessions
that do not have the persist-id will be completed by the server, and are
not rejected.  They are subject to being rolled back of course (that
is documented).

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2012 05:53:15 -0700

>       configuration to its state before the confirmed commit was issued.

I did not get any comments.
I checked what yuma implements, and it is not this text.
It implements the (IMO) correct behavior.

RFC 6241, sec 7.2, paragraph 2:
OLD:

NEW:

        If a NETCONF server receives a <kill-session> request while
        processing a confirmed commit (Section 8.4), it MUST restore the
        configuration to its state before the confirmed commit was issued,
        if the session being killed is the same session that initiated the
        current confirmed commit procedure, and the 'persist' parameter
        was not present in the <commit> operation input parameters.

Are there any objections to posting this RFC Errata for RFC 6241?

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 27 Jul 2012 15:01:09 +0200

So Andy, your new text (to me at least) seems more of a
piece of clarifying text being added. Good thing I believe,
but I would not consider the current text a bug.

Bert (speaking as a technical contributor)

On 7/27/12 2:53 PM, Andy Bierman wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Jul 2012 06:32:29 -0700

The current text seems like a bug to me because it says
that any session being killed will cause the confirmed commit
to be terminated.  Even if that session is being killed, the
persist parameter allows other sessions to finish the CC.

All the IETF WEB sites are down right now, so I can't find
the confirmed-commit text that says this is how it works.
This text in 4271 wasn't even correct because a session
that is not involved in the CC does not affect it.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 29 Jul 2012 16:55:53 +0200 (CEST)

> Are there any objections to posting this RFC Errata for RFC 6241?

No.  I think this is a correct clarification.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Sun, 29 Jul 2012 20:42:40 -0700

I like it.  My only comment is grammatical - the last two commas caused me
to have to rescan the text and therefore seem out of place.  Here's the
same text with the last two commas removed:

        If a NETCONF server receives a <kill-session> request while
        processing a confirmed commit (Section 8.4), it MUST restore the
        configuration to its state before the confirmed commit was issued
        if the session being killed is the same session that initiated the
        current confirmed commit procedure and the 'persist' parameter
        was not present in the <commit> operation input parameters.

See you all tomorrow

Kent