Re: Issue 13.6: Discard changes

[Phil Shafer <phil@juniper.net>]

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.

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