Re: Issue 13.6: Discard changes

[Andy Bierman <abierman@cisco.com>]

At 10:55 AM 2/10/2004, Phil Shafer wrote:
>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 part that says the #candidate config should
be implicitly locked whenever somebody writes to it.
You have to write code to have the CLI check for
an active lock to cover the case where NETCONF acquires
the lock before the CLI session starts.  In order for
NETCONF locking to work, vendors have to add lock support 
to their CLI and SNMP agents.  The <lock> command can fail
because CLI or SNMP has the lock -- it doesn't just
apply to NETCONF.  


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

Then write the XSD that has this "do what I mean"
semantics.  It's silly to optimize away the need
to know about #candidate for one operation, but
not all the others.   This is one line of code,
executed at the start of session:

  if (#candidate) 
     target = "<candidate>";
  else
     target = "<running>";


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

No.  The way #candidate is defined, the <lock> command
will fail if the <candidate> config contains uncommitted
content.  An application can't hold the lock if it
can't get the lock.  

We should not make huge exceptions in the architecture 
based on scenarios involving a human at the CLI, especially
assuming that the human doesn't know the system uses
configuration locking to provide transaction integrity.
Add a 'lock' command to the CLI.  Problem solved.

If NETCONF is used in a system, then all access mechanisms
should be updated to understand the system now uses
write locks.  This is an important architectural improvement
to the system, and all NM access methods needs to be aware of 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.

Then why build in a special case that causes the <lock>
command to fail even though nobody is holding the lock?


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