[Netconf] NETCONF persist-id

[<[e-mail]>]

Hi,

 

RFC6241 introduced <persist> and <persist-id> parameters to the commit
operation for NETCONF.

 

In section 7.8 in erratum 5397 it 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.

 

In section 7.9 in erratum 5397 it 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.

 

In section 8.4.1 in erratum 3821 it states:

If the <persist> element is not given in the confirmed commit operation, any
follow-up commit and the confirming commit MUST be issued on the same
session that issued the confirmed commit. If the <persist> element is given
in the confirmed <commit> operation, a follow-up commit and the confirming
commit can be given on any session, and they MUST include a <persist-id>
element with a value equal to the given value of the <persist> element.

 

If the server also advertises the :startup capability, a <copy-config> from
running to startup is also necessary to save the changes to startup. If the
session issuing a sequence of one or more confirmed commits is terminated
for any reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the sequence of confirmed commits was
issued, unless the last confirmed commit also included a <persist> element.

 

In section 8.4.5.1 in erratum 3823 it states:

persist:

Make the confirmed commit survive a session termination, and set a token on
the ongoing sequence of confirmed commits.

 

In Appendix C on page 102 it states:

leaf persist {

if-feature confirmed-commit;

type string;

description

"This 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. The value of this parameter is a token
that must be given in the 'persist-id' parameter of <commit> or
<cancel-commit> operations in order to confirm or cancel the persistent
confirmed commit. The token should be a random string.";

reference "RFC 6241, Section 8.3.4.1";

}

 

It would appear the persist-id is intended to allow a commit operation to
survive a session termination, presumably regardless of whether that
termination results from a <close-session> or <kill-session>. However,
section 7.6 states "An <unlock> operation will not succeed if . the session
issuing the <unlock> operation is not the same session that obtained the
lock", and there is no <persist-id> element for <unlock>. This implies
<lock> cannot be used with a confirmed commit sequence that includes the
termination of the initiating session.

 

Should a <persist-id> element be added to <unlock>, and a new erratum be
raised against sections 7.8 and 7.8 to rescind the previous erratum and
state that any session termination of a persistent confirmed commit will NOT
restore the configuration to its state before the confirmed commit was
issued but continue the persistence until either a timeout or a
<cancel-commit>?

 

Jonathan



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