[Netconf] candidate config details

Hi,

I'm looking closely at the NETCONF specs wrt/ the candidate config.

It is not obvious from the text that anybody can invoke
discard-changes and/or commit if locks are not used.
The original session which neglected to use the lock
will continue to write to the <candidate> until
another session locks it, and probably try to commit it as well.

So use locking! And lock the candidate and running,
plus startup if :startup capability advertised.
The candidate lock controls edit-config and discard-changes.
The running lock controls 'commit'.
The startup lock controls 'copy-config <running> to <startup>'.

*** Questions about partial locking draft: ***

If partial locking is used, and some dirty nodes are locked,
but other dirty nodes are not, does a discard-changes by
a 3rd party session work (a) at all, (b)only on the unlocked nodes,
or (c) up to the agent to decide (a) or (b)?

Same question for commit?

*** Comments on partial locking draft: ***

It may seem that the manager can ignore the <running>
config and just lock the subtree in the <candidate>
(since writes to the <running> are not allowed).
But if some other session takes out a a global or a partial
<running> lock covering your subtree, you control only
the <candidate> version, and can not commit your changes.

Sec. 2.4.1, para 4 of partial-lock-03 says:

    A <partial-lock> operation MUST be handled atomically by the NETCONF
    server.  The server either locks all requested parts of the data
    store or none; I.e. if during the operation one of the requested
    parts cannot be locked the server MUST unlock all parts that have
    been already locked during that operation.

Clearly, getting all the locks you need at once is important,
and simplifies implementation for the manager.  However, this
is not supported in NETCONF <lock> or <partial-lock>.

IMO, the 'target' parameter should be a leaf-list, not a leaf.
If not a leaf-list, then a 'bits' parameter, since the URL form
is not allowed anyway.

The most common use case is going to be a partial-lock
of the same subtrees in both the <candidate> and <running>
configs.

Andy

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf