Re: Issue 13.6: Discard changes

[Andy Bierman <abierman@cisco.com>]

At 07:02 AM 2/11/2004, Phil Shafer wrote:
>Andy Bierman writes:
>>Why is this assumption that session A is a human user
>>important?
>
>Because we like human users.  Scripts can wait and retry
>operations.  An operator in the middle of a set of
>changes (one not retrained to use explicit locks)
>shouldn't have their changes committed or discarded
>by an automated script.

I don't think you are addressing this issue consistently.
On one hand, you say never stop the human operator
from using the CLI, but if the lock is already obtained,
it's okay to print an error message telling the human
that the configuration can't be modified right now.

My point is that the introduction of configuration
locking has system-wide impact.  The CLI code will
have to be aware of locking.  Whether the CLI
sub-system obtains a lock without human intervention
(as Juergen pointed out) is an implementation detail.

The NETCONF I-D doesn't say that the lock is denied
only if the candidate config contains uncommitted
changes via CLI.  

Andy



>>You are trying to claim that
>>a "legacy" application should still work, even though
>>the system architecture changed to one that uses
>>a configuration lock.
>
>The "legacy" application here is human users, which
>have a strong priority claim.  If the ISP has to
>choose between deploying netconf-based applications
>and allowing their users to continue their normal
>mode of operation, their choice will be easy.
>
>>We did not consider the impact on legacy
>>applications very much.
>
>We did consider this impact.  That's the motivation
>for the rules regarding candidate config and locks.
>
>>Then how are you going to implement <lock> in NETCONF?
>
>As described in the draft, locks are not granted if
>there are outstanding changes to the candidate configuration.
>
>>What if the user at the CLI starts editing the config
>>after a NETCONF session acquires a lock?
>
>They get an error message when they try to change the configuration.
>
>>We have the NETCONF WG because current CLI based systems
>>make lousy programmatic interfaces.  We have no transaction
>>integrity with CLI, and that hoses users as well.
>
>The trick is to add transaction integrity for automation
>without hosing human users.  I think we did this pretty
>well in Junoscript and hate to think that we'd fail to
>do it in netconf.
>
>Thanks,
> Phil
>
>--
>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/>