Subject: RE: More confirmed-commit issues

From: "Rob Enns" <[email-masked]>
Date: Fri, 20 May 2005 09:41:37 -0700

>   1) add the "confirmed-commit-in-progress" warning I 
> proposed (or something like it) so other managers can 
> at least know their changes may be clobbered by the 
> agent at time T

This seems weak to me. The draft recommends that
the lock be held, in which case other managers couldn't make
changes during this window.

One could argue for similar warnings in the case of a shared 
candidate, or even a writable running configuration, given that 
multiple managers can be making changes simultaneously. In other
words, the automated restore that happens when an unconfirmed
commit is reverted is no more surprising than another manager
coming in and stomping on somebody's edits (candidate or not).
I think the best way to solve this is with the lock, not by
adding a warning message.

>   2) automatically revert the config if the "committing" session is 
> lost  (WG consensus for this already)

Change made.

>  3) automatically revert the config upon startup if the agent reboots 
> for any reason while a revert-timeout is pending

Change made.

Rob

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 May 2005 10:06:37 -0700

>changes during this window.

This is only true now that we will revert automatically if Mgr A 
closes/loses
its session.  It does rely on Mgr A doing everything correctly.  The warning
should not be issued often if everything goes as planned. It's a warning 
not
an error, so these operations still succeed.  IMO, it's more robust to
warn Mgr B about this unique situation. 

>adding a warning message.
I think there should be a 'stomping-on-edits' warning too!   :-;

This protocol provides a programmatic interface for the benefit of 
operators.
It may be easier on the agent developer not to bother with a warning,
but it can help an application (and it's human operators) from potentially
devastating consequences from a legal but not multi-manager friendly
application.  Remember -- use of locks is totally optional. 

To me it's no different than wanting my C compiler to tell me about
suspicious uses of C language constructs.

>>for any reason while a revert-timeout is pending
Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 21 May 2005 09:13:39 -0700

Andy Bierman wrote:

> Rob Enns wrote:
>
>>>  1) add the "confirmed-commit-in-progress" warning I proposed (or 
>>> something like it) so other managers can at least know their changes 
>>> may be clobbered by the agent at time T
>>>   
>>
>>
> should not be issued often if everything goes as planned. It's a 
> warning not

Another reason for the warning is that any manager can issue the 2nd 
<commit>,
even if that manager is actually intending to do its own "regular" commit.

I guess the warning isn't critical now that we've closed the 'dropped 
session'
and 'reboot' holes, and changed the timeout units from minutes to seconds,
so I'm not objecting to confirmed-commit anymore.  Now it takes misuse
to break things, instead of natural events like lost connections and 
reboots.

Andy