Re: [netconf] RFC 6241 Ambiguity

It seems that the "for any reason" clause should be qualified modulo the "persist" element (please file an errata report).  Note also the last paragraph in Section 8.4.1, which shows RFC 624 straddling capability versions, hence the wonky text. 

To answer your question. it is the latter: the only way to abort a persistent confirmed commit is to let the timer expire, or to use the <cancel-commit> operation.

Kent // contributor

> On May 8, 2019, at 9:33 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:
> 
> 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
> 
>  <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> <x-msg://11/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>_______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>