Re: Issue 13.6: Discard changes

[Andy Bierman <abierman@cisco.com>]

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

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.

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