Subject: [Netconf] candidate config details

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Oct 2008 10:49:15 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Oct 2008 20:55:46 +0200 (CEST)

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

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

> If not a leaf-list, then a 'bits' parameter, since the URL form

Good idea!  leaf-list is probably right.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Oct 2008 20:55:46 +0200 (CEST)

/martin