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

["Jonathan Hansford" <[e-mail]>]

------ Original Message ------
From: "Jonathan Hansford" <[e-mail]>
To: [e-mail]
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?
>
>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?
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>

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