Re: Issue 13.6: Discard changes

[Rob Enns <rpe@juniper.net>]

On Mon, Feb 09, 2004 at 04:04:59PM -0800, Andy Bierman wrote:
> At 03:16 PM 2/9/2004, Rob Enns wrote:
> >> 13.16) <discard-changes>
> >> 
> >> 13.16.1) Clarifications [PROT]
> >> 
> >>   Says content 'automatic' is allowed for the <discard-changes>
> >>   operation.  This is not actually documented.
> >>    
> >>   Closed: accepted, protocol document needs to be updated
> >
> >Here is the source of the confusion: there is a <discard-changes>
> >operation which tells the device to discard any changes made to
> >the candidate the configuration.
> >
> >There is _also_ a <discard-changes> argument specified as part of the
> >lock operation which can indicate that the device should automatically
> >discard any changes to the configuration when the lock is released 
> >(either intentionally using <unlock/>, or implicitly, by session failure).
> >
> >The confusion can be fixed by renaming one of these elements. 
> >We could rename the <discard-changes> argument
> >to <rollback>, so that a lock request could look like:
> >
> ><lock>
> >  <target><candidate/></target>
> >  <rollback>automatic</rollback>
> ></lock>
> >
> >and this element could be conditional on the (tbd) #rollback capability.
> 
> I really don't like this approach at all.
> Rollback should not be coupled to the candidate config.
> This is a separate feature that is not dependent on whether
> the device supports writes to <candidate> or to <running>.
 
I am trying to propose _decoupling_ automatic rollback from the
candidate config. :-) That's why I said to make it conditional
on the rollback capability.

> Why does the candidate config need its own extensions
> to the <lock> command?  This seems like really bad design.
> I think we should avoid special versions of the protocol
> operations unless absolutely required.

Perhaps we are in agreement, maybe I was not clear. What I'm suggesting
is that we add the ability to specify that changes can be
rolled back (from either the candidate or running) configuration.
The reason to put it on the lock command is that lock/unlock
are one nice way NETCONF has to bracket a set of changes.
The other way is "all the changes in an <edit-config>", which
is okay too, but not as flexible. If we do rollback in
NETCONF, it should work both with a single <edit-config> 
granularity, as well as the set of changes between a lock and unlock.

thanks,
 Rob

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

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