Re: Issue 13.6: Discard changes

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Phil Shafer writes:

Phil> The "legacy" application here is human users, which have a
Phil> strong priority claim.  If the ISP has to choose between
Phil> deploying netconf-based applications and allowing their users to
Phil> continue their normal mode of operation, their choice will be
Phil> easy.

[...]

Phil> The trick is to add transaction integrity for automation without
Phil> hosing human users.  I think we did this pretty well in
Phil> Junoscript and hate to think that we'd fail to do it in netconf.

Human users type into a CLI not into memory - so why can the CLI not
establish a suitable lock when the user is making configuration
changes? This can be implemented either by a special lock CLI command
which the user has to learn and use, or it can be bundled with some
"enable" mechanism, or perhaps even be totally implicit and delayed
until the first real change is being made. But at the end, I think the
CLI should lock somehow.

In fact, the ID says:

         A lock will not be granted if any of the following conditions
         are true:
[...]
         +  the target configuration has already been modified and these
            changes have not been committed

Is this not basically saying that something did already establish a
lock (by modifying the configuration)?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany



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