[netconf] RFC 6241 Ambiguity

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

Hi,

In RFC 6241:

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

Section 8.4.5.1 states the persist parameter makes "the confirmed commit 
survive a session termination".

Appendix C states the persist parameter "is used to make a confirmed 
commit persistent. A persistent confirmed commit is not aborted if the 
NETCONF session terminates. The only way to abort a persistent confirmed 
commit is to let the timer expire, or to use the <cancel-commit> 
operation."

However:

Section 7.8, Erratum 5397 states "If a NETCONF server receives a 
<close-session> request while processing a confirmed commit (Section 
8.4) for that session, regardless of whether the confirmed commit 
included a <persist> element, it MUST restore the configuration to its  
state before the confirmed commit was issued."

Section 7.9, Erratum 5397 states "If a NETCONF server receives a 
<kill-session> request while processing a confirmed commit (Section 8.4) 
for that session, regardless of whether the confirmed commit included a 
<persist> element, it MUST restore the configuration to its  state 
before the confirmed commit was issued."

Section 8.4.1 states "If the device reboots for any reason before the 
confirm timeout expires, the server MUST restore the configuration to 
its state before the confirmed commit was issued."

So:

Is the use of <close-session> or <kill-session>, or the device 
rebooting, not considered to be the session being "terminated for any 
reason"? Or is it the case that "the only way to abort a persistent 
confirmed commit is to let the timer expire, or to use the 
<cancel-commit> operation"?

Jonathan

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