Subject: [Netconf] RFC6241 - Confirmed Commit Capability, <close-session> and <kill-session>

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 18 Jun 2018 15:32:45 +0000

Hi,

RFC6241, Section 7.9 <kill-session> states "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."

Is it correct to assume that only applies if the session being killed is 
the one for which a confirmed commit is being processed?

Section 8.4.1 states "If the session issuing the confirmed commit is 
terminated for any reason before the confirm timeout expires, the server 
MUST restore the configuration to its state before the confirmed commit 
was issued, unless the confirmed commit also included a <persist> 
element."

Is it correct to assume if a <kill-session> is received for a session 
for which the confirmed commit included a <persist> element, the 
behaviour is still to restore the configuration to its state before the 
confirmed commit was issued since the client owning the session is no 
longer in control and the session is having to be killed using a 
different client?

Section 7.8 <close-session> makes no mention of confirmed commits.

Is it correct to assume the client would be expected to cancel a 
confirmed commit before closing its session unless the client wished to 
continue on a new session (e.g. after a device reboot) in which case the 
confirmed commit would have included a <persist> element?

Thanks,

Jonathan

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: "Jonathan Hansford" <[email-masked]>
Date: Tue, 19 Jun 2018 10:10:42 +0000

------ Original Message ------
From: "Jonathan Hansford" <[email-masked]>
To: [email-masked]
Sent: 18/06/2018 16:32:45
Subject: [Netconf] RFC6241 - Confirmed Commit Capability, 
<close-session> and <kill-session>

>Hi,
>
>RFC6241, Section 7.9 <kill-session> states "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."
>
>Is it correct to assume that only applies if the session being killed 
>is the one for which a confirmed commit is being processed?
>
>terminated for any reason before the confirm timeout expires, the 
>server MUST restore the configuration to its state before the confirmed 
>commit was issued, unless the confirmed commit also included a 
><persist> element."
>
>continue on a new session (e.g. after a device reboot) in which case 
>the confirmed commit would have included a <persist> element?
Thinking about it, <close-session> clears any locks which implies any 
outstanding confirmed commits should be cancelled as with 
<kill-session>. That also implies confirmed commits only persist beyond 
a session if the session is closed in an uncontrolled manner (e.g. 
through a client or server reboot). But the confirmed commit is planned 
so why should a <close-session> (also planned) have to clear locks? 
Surely a <close-session> should optionally clear locks and cancel 
confirmed commits, based on the reason for closing the session.

Also, Section 7.9 talks about <kill-session> being received by a NETCONF 
entity. Section 1 indicates clients send RPCs to servers so presumably 
by "entity" section 7.9 means server (as in other sections).
>
>
>Thanks,
>
>Jonathan
>
><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>Virus-free. www.avast.com 
><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---