Issues 10.3.2, 11.2.3, 13.3.2) new proposal for rollback

[Andy Bierman <abierman@cisco.com>]

Here is a stab at fixing the rollback problem:

Summary:
  - add #rollback-on-error capability
  - add #confirmed-commit capability
  - add rollback-on-error enum value to error-option parameter
  - keep 'confirmed' and 'confirmed-timeout' parameters for
    for the commit operation

Andy

----------------------------

Issue 11.2.13: #rollback capability

#rollback-on-error capability definition:

This capability indicates that the agent will support the
enumeration value 'rollback-on-error' in the 'error-option'
parameter of the edit-config operation. 

-----------------------------

Issue 13.3.2: rollback-on-error

rollback-on-error definition:

   If this error option is selected, and an error condition occurs
   such that 'error' severity rpc-error element is generated,
   the agent will stop processing the edit-config operation and
   restore the specified configuration to its complete state
   at the start of this edit-config operation.

   Note that for shared configurations, this feature can cause
   other configuration changes (e.g., via other NETCONF sessions)
   to be inadvertently altered or removed, unless the configuration
   locking feature is used (i.e., lock obtained before the edit-config
   operation is started).  Therefore, it is strongly suggested that
   in order to use this feature with shared configuration databases,
   configuration locking must also be available and used properly.

------------------------------

Issue 10.3.2: Confirmed commit

#confirmed-commit capability definition:

This capability indicates that the agent will support the
'confirmed' and 'confirm-timeout' parameters for the 'commit'
protocol operation.  See section 6.5.4 for further details
on the 'commit' operation.  This capability is only relevant
if the #candidate capability is also supported.

------------------------------

confirmed-commit definition:

   [doesn't change, but note about locking should be added]

   Note that for shared configurations, this feature can cause
   other configuration changes (e.g., via other NETCONF sessions)
   to be inadvertently  altered or removed, unless the configuration
   locking feature is used (i.e., lock obtained before the edit-config
   operation is started).  Therefore, it is strongly suggested that
   in order to use this feature with shared configuration databases,
   configuration locking must also be available and used properly.



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