Re: Issue 13.6: Discard changes

[Andy Bierman <abierman@cisco.com>]

At 12:12 PM 2/10/2004, Phil Shafer wrote:
>Andy Bierman writes:
>>The part that says the #candidate config should
>>be implicitly locked whenever somebody writes to it.
>
>I follow you now, but I think there's a distinction
>between an inability to acquire a lock and an implicit
>lock, though this may be a fine point.
>
>The objective is to control the interaction between
>the user and any applications.  If there are uncommitted
>changes, a lock cannot be granted without hosing
>the human user, which isn't a viable option.

Why is this assumption that session A is a human user
important?  Why is the assumption that the human at
the CLI started typing before session B attempted
to acquire the lock important?

IMO, they're not.  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.  That's not how NETCONF
locking is defined.  The lock applies to the whole
system, not just NETCONF.  We made locking mandatory
because global locking is easy to implement on the
agent.  We did not consider the impact on legacy
applications very much.


>>We should not make huge exceptions in the architecture 
>>based on scenarios involving a human at the CLI
>
>We _have_ to make whatever exceptions are required to handle scenarios
>involving humans at the CLI.  The human has to win any user.vs.automation
>contest.  You cannot hose the user.  Ever.

Then how are you going to implement <lock> in NETCONF?
What if the user at the CLI starts editing the config
after a NETCONF session acquires a lock?


>Give the user an application that hoses him and you'll be making
>an application that the user doesn't use.

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.


>Thanks,
> Phil

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