Re: Issue 13.6: Discard changes

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>I don't buy into your premise that one session is a
>human at the CLI and the other is a NETCONF application.

What part don't you buy?  One of the keys to automation is controlling
the interaction between real human humans and applications.

>The <lock> operation should work consistently regardless
>of the target (candidate or running).

The motivation for the current behavior is DWIM, since
an application talking to a box with #candidate will
typically want to lock the candidate config and an
application talking to a box without it will
typically want to lock the running config.  Having
the target default to the proper value means that
the typical application can just do '<lock-config/>'
without sweating the candidate capability.

>The way locking
>is defined for #candidate is broken because a session
>can effectively hold a lock without actually using it.

I don't understand this comment.  An application can lock
the configuration and hold that lock until it's finished
with its work, or until someone gets upset and nukes it.

>The point of the locking mechanism is that only one
>session can write to the configuration at a time.
>It doesn't matter if the writer is NETCONF, CLI, SNMP
>or whatever.  If you don't lock the config, you are
>at risk of somebody else locking it instead.

Completely agree.

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