Re: [Netconf] idea for new commit operation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] idea for new commit operation



Hi,

Andy Bierman <andy at netconfcentral.com> wrote:
> A :new-commit capability can add output parameters, not just
> input parameters.  It can persist across sessions, and
> fix the broken parts of confirmed-commit.1.0.  It can support
> the verified commit procedure defined in a separate document.

I agree with this in general, except for the verified part.  I think
we get a cleaner model if one rpc does one thing.  In this case,
the confirmed commit operation will work just fine with a new
'start-test' rpc.  (see my email
http://www.ietf.org/mail-archive/web/netconf/current/msg04717.html)


I think this 'better confirmed commit' capability can be specified as
:confirmed-commit:1.1 in 4741bis.


The :confirmed-commit:1.0 capability lacks a 'cancel-commit'
operation.  The text actually vaguely refers to something like that in
section 8.4.1:

   Thus to cancel a confirmed commit and revert
   changes without waiting for the confirm timeout to expire, the
   manager can explicitly restore the configuration to its state before
   the confirmed commit was issued.

Except that this "explicit restore" operation does not exist...  So I
think it makes sense to add such an operation.


The other issue is if the confirming commit MUST be done from the same
session that did the confirmed commit or not.  4741 doesn't say, so I
think it needs to be clarified in 4741bis.  The reason it can be
useful to do this from some other session is if you change some
parameter that affects the session, e.g. if you change the ip
address.  But it seems pretty dangerous to *always* allow this, since
it means that any user could come in and confirm my commit.  Thus, I
think the idea of adding an excplicit 'persist' parameter is great.  I
would prefer if confirmed-commit:1.0 was clarified in 4741bis to NOT
allow this gratuitous commit from other sessions, and
confirmed-commit:1.1 should add the 'persist' parameter (etc) to
handle the use case.


/martin


> E.g.:
> 
>   feature new-commit {
>     if-feature confirmed-commit;
>     description
>       "Supports the new confirmed commit procedure and the
>        verified commit procedure.";
>   }
> 
>   typedef commit-id-type {
>      description
>        "Contains the agent-assigned identifier for this commit request.
>         This value is returned by a new <commit> operation, and
> 	must be used with the subsequent <complete-commit> or <cancel-commit>
>         operations, or the agent will not accept the request.
>         This commit identifier is only valid while a confirmed or verified
>         commit operation is in effect.  The agent should use a string value
> 	which is not predictable, and cannot be easily guessed.";
>      type string {
>         length { "8 .. 1024"; }
>      }
>   }
> 
>   rpc commit {
>     if-feature candidate;
>     description
>       "If the :new-commit capability is supported, and the
>        'verified' or 'persist' parameter is entered, then the new
>        commit procedure is in effect.  The <complete-commit> or <cancel-commit>
>        operations will be used, not the <commit> operation again.
> 
>        If the :new-commit capability is not supported, or these
>        parameters are not present, then the old commit procedure
>        is in effect, and a 2nd <commit> operation is expected
>        by any session, before the current session terminates or
>        the timeout expires.";
>     input {
>        leaf timeout {
>           if-feature confirmed-commit;
> 	  description "unchanged";
>           type timeout-type;
>        }
>        leaf confirmed {
>           if-feature confirmed-commit;
> 	  description "unchanged";
>           type empty;
>        }
>        leaf-list test-template {
>           if-feature new-commit;
>           description
> 	     "Optional list of verification control entries to
> 	      use during the verified commit procedure.";
>           type instance-identifier;
>        }
>        leaf persist {
> 	  if-feature new-commit;
>           description
>             "If present, then this commit procedure is allowed
> 	     to persist across a single session.  If the current session
> 	     is terminated, the running database will not be automatically
>              reverted.  Only a timeout or the <cancel-commit> operation
> 	     will cause the commit procedure to be terminated, if this
> 	     parameter is present.";
> 	  type empty;
>        }
>     }
>     output {
>        leaf commit-id {
> 	 if-feature new-commit;
>          type commit-id-type;
>        }
>     }
>   }
> 
>   rpc complete-commit {
>      if-feature new-commit;
>      description
>        "The 2nd commit to finalize a confirmed or verified commit operation.";
>      input {
>         leaf commit-id {
>            type commit-id-type;
>         }
>      }
>   }
> 
>   rpc cancel-commit {
>      if-feature new-commit;
>      description
>        "Cancel a confirmed or verified commit operation in progress.";
>      input {
>         leaf commit-id {
>            type commit-id-type;
>         }
>      }
>   }
> 
> 
> 
> Andy
> 
> _______________________________________________
> Netconf mailing list
> Netconf at ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.