Re: More confirmed-commit issues

[Andy Bierman <ietf@andybierman.com>]

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

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. 

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

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