RE: unified transaction model proposal

["Harrington, David" <dbh@enterasys.com>]

Hi, 

Comments inline. 

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com] 
> There is a fuzzy line between implementation details
> and standards details when it comes to locking.
> The feature is transaction integrity.  Global database
> locking is just a way to implement transaction integrity,
> not a feature in itself.  Global locking creates performance
> and security problems, so it's not nearly the best way
> to implement transaction integrity.
> 
> >> Our notion of a transaction doesn't align very well with
> >> a traditional database transaction model.  We have optional-to-use
> >> explicit global config locking instead of mandatory-to-use implicit
> >> partial config locking.  The optional-to-use aspect creates
> >> lots of problems like the one you're describing here.
> >
> >I agree.
> >
> >I think it is a bad design to have optional locks. Making 
> locks optional
> >will greatly increase the conditional-complexity of the
> >applications/scripts needed to use NETCONF, which is not in 
> line with a
> >number of operators' requirements.
> 
> Some operators and EMS developers have problems with the 
> global locking because they want to be able to have multiple 
> provisioning transactions in progress at once, which affect 
> different device resources (and/or instances).

I have problems with two things: making locks optional, and making locks
global. 

I think it will be imperative to be able to manipulate different
portions of the configuration simultaneously, so globally locking global
configurations, like running, are a problem. We discussed this at the
interim and it has been raised multiple times on the mailing list. I
believe we will need partial configuration support, with locks to
support that.

Trying to solve the need for partial configurations by allowing locks to
be optional misses the point in my view, and the cure is worse than the
illness.

> >We're designing a standard, and we should be able to specify what is
> >required to be conformant, and I believe the locks should be 
> mandatory,
> >not optional. It will greatly simplify the design process 
> for NETCONF,
> >provide better interoperability, and improve predictability in the
> >network management process. 
> >
> >Implementors will complain that locks are hard, and 
> therefore should be
> >optional. I agree that locks are hard, but they are hard because
> >multi-user and cross-interface coordination is hard, and 
> locks help to
> >improve the coordination. They should be mandatory because managing
> >effectively without them is really hard; having the locks makes it
> >easier.
> >
> >> 
> >> How about forcing the duration of a lock to be a single 
> transaction:
> >
> >In a cross-protocol setting, how will you define "a single 
> transaction"?
> >
> >If SNMP sets the global lock, what would a single transaction be? One
> >PDU, or one transaction carried in multiple PDUs, such as a
> >CreateAndWait transaction?
> >Could I SNMP-lock a system and then send multiple messages with
> >configuration changes, all part of a single transaction, before
> >releasing the lock?
> 
> You have to create a common transaction model and map
> it to NETCONF and SNMP.  The client signals the start
> and end of a transaction.  This WG isn't concerned how
> the NETCONF transaction model maps to SNMP.  That can
> happen later, if needed.

SNMP wasn't concerned with how it mapped to the CLI either. But if
you're going to have a common transaction model and common access
control, you can't do it later; you need to build it into the design
upfront.

The more problems you throw over the wall, the harder it will be to get
acceptance of NETCONF until those problmes are solved. And the harder it
will be to solve them after NETCONF is cast in stone. Think about
SNMPv3's decision to resolve key distribution problems "later".

Dbh

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