More confirmed-commit issues

[Andy Bierman <ietf@andybierman.com>]

Hi,

IMO, PROT, section 8.4 is not very clear what happens
if locking is not used, or if the manager doesn't follow
the elements of procedure that the document suggests.

If a confirmed-commit timeout is pending, and the <candidate>
config is modified again before the 2nd <commit> or the timeout
occurs, how does the agent interpret the <commit> that is intended
to be for the newly modified <candidate>?  What exactly is the the
contents of <running> after the confirm-commit timer pops?
What if the 2nd commit is also a confirmed-commit?  What if
time(C2) < timer(C1)? How come a manager cannot cancel a confirmed
commit  (after commit-1 but before the timeout)?

Note that this corner-case can occur naturally if locking is not 
properly used,
or pathologically, if the manager holding the locks writes to the 
<candidate>
before finishing the first confirmed commit.  (E.g., operator forgets a line
of config -- adds it -- commits it.)

The vague warning about "use locks properly" (8.4.1, para 2) is not 
relevant
to agent implementers who have to make this work even if locking isn't 
used,
used wrong, or the manager doesn't follow the implied transaction model.

I would also like to note that the #rollback feature was thrown out because
of these same corner-cases, that (IMO) are neither explained or properly 
handled
in the current draft as they relate to the #candidate and  #confirmed-commit
capabilities.

Andy










--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>