Re: [Netconf] candidate config details

Andy Bierman <andy@netconfcentral.com> wrote:
> *** 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)?

It will not work, since discard-changes is supposed to completely
reset the candidate, and the dirty locked nodes must not be modified.

> Same question for commit?

If some nodes are dirty in the candidate, and they are locked in
running, then, by the same reasoning, a 3rd party session's commit
will not succeed.

I think you can view nodes that are locked as if you don't have access
to them (while they are locked).

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

Yes.  We debated whether to put text about this in the draft or not;
maybe we should be explicit about this (if it's not there already).

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

Good idea!  leaf-list is probably right.

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