Re: same value operation attributes restriction

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Andy Bierman" <abierman@cisco.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <netconf@ops.ietf.org>
> Sent: Friday, March 26, 2004 5:10 PM
> Subject: Re: same value operation attributes restriction
...
On the question of vendor motivation to implement rollback -
...
> 1) The NETCONF protocol distinguishes between create, modify,
> and delete.   The granularity for create and modify are
> not necessarily the same.  The notion of completeness
> is data-model specific.

Somehow this does not make me feel any better.
Perhaps it's because today some MIBs are straightforward
to implement, even with create-and-wait, while others are
overly complicated.   If the argument "design better MIBs"
didn't cut it for folks who thought SNMP was ill-suited for
configuration, leaving the notion of "completeness"
data-model specific means netconf may face the same problem.

> 2) There is a big difference between as-if-simultaneous
> and serialized execution with rollback.  NETCONF requirements
> are not as strict as SNMP.

Serialized execution with rollback is exactly what most SNMP subagent
technologies do.  That's why SNMPv3 has the "undo failed" error code.

> 3) Customers will expect to use NETCONF for configuration.
> This is not usually the case for SNMP.
...

Unless vendors plan to drop their CLIs in favor of netconf, I still
don't see how the first two points provide any motivation for
vendors to implement rollback, and even the third is hard to to
imagine becoming a determining factor in an equipment bid.

Randy



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