RE: More confirmed-commit issues

["Rob Enns" <rpe@juniper.net>]

How does this replacement text sound?

----
8.4  Confirmed Commit Capability

8.4.1  Description

   The #confirmed-commit capability indicates that the server will
   support the <confirmed> and <confirm-timeout> parameters for the
   <commit> protocol operation.  See section Section 8.3 for further
   details on the <commit> operation.

   A confirmed commit operation MUST be reverted if a follow-up commit
   (called the "confirming commit") is not issued within 600 seconds (10
   minutes).  The timeout period can be adjusted with the <confirm-
   timeout> element.  The confirming commit can itself include a
   <confirmed> parameter.

   If a confirming commit is not issued, the device will revert it's
   configuration to the state prior to the issuance of the confirmed
   commit.  Note that any commit operation, including a commit which
   introduces additional changes to the configuration, will serve as a
   confirming commit.  Thus to cancel a confirmed commit and revert
   changes without waiting for the confirm timeout to expire, the
   confirming commit can explicitly restore the configuration to it's
   state before the confirmed commit was issued.

   For shared configurations, this feature can cause other configuration
   changes (for example, via other NETCONF sessions) to be inadvertently
   altered or removed, unless the configuration locking feature is used
   (in other words, 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 should also be used.

8.4.2  Dependencies

   The #confirmed-commit capability is only relevant if the #candidate
   capability is also supported.

8.4.3  Capability and Namespace

   The #confirmed-commit capability is identified by the following
   capability string:

      urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit

   The #confirmed-commit capability uses the base NETCONF namespace URN.

8.4.4  New Operations

   None.

8.4.5  Modifications to Existing Operations

8.4.5.1  <commit>

   The #confirmed-commit capability allows 2 additional parameters to
   the <commit> operation.

   Parameters:

      confirmed:

            Perform a confirmed commit operation.

      confirm-timeout:

            Timeout period for confirmed commit, in seconds.  If
            unspecified, the confirm timeout defaults to 600 seconds.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>
 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Sunday, May 08, 2005 10:24 AM
> To: netconf
> Subject: More confirmed-commit issues
> 
> Hi,
> 
> IMO, PROT, section 8.4 is not very clear what happens
> if locking is not used, or if the manager doesn't follow
> the elements of procedure that the document suggests.
> 
> If a confirmed-commit timeout is pending, and the <candidate>
> config is modified again before the 2nd <commit> or the timeout
> occurs, how does the agent interpret the <commit> that is intended
> to be for the newly modified <candidate>?  What exactly is the the
> contents of <running> after the confirm-commit timer pops?
> What if the 2nd commit is also a confirmed-commit?  What if
> time(C2) < timer(C1)? How come a manager cannot cancel a confirmed
> commit  (after commit-1 but before the timeout)?
> 
> Note that this corner-case can occur naturally if locking is not 
> properly used,
> or pathologically, if the manager holding the locks writes to the 
> <candidate>
> before finishing the first confirmed commit.  (E.g., operator 
> forgets a line
> of config -- adds it -- commits it.)
> 
> The vague warning about "use locks properly" (8.4.1, para 2) is not 
> relevant
> to agent implementers who have to make this work even if 
> locking isn't 
> used,
> used wrong, or the manager doesn't follow the implied 
> transaction model.
> 
> I would also like to note that the #rollback feature was 
> thrown out because
> of these same corner-cases, that (IMO) are neither explained 
> or properly 
> handled
> in the current draft as they relate to the #candidate and  
> #confirmed-commit
> capabilities.
> 
> 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/>