Subject: [Netconf] 4741bis, sec. 8.4.1

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Sep 2009 11:33:43 -0700

Hi,

It is clear how the 'shared' aspect of confirmed-commit
works without locking.

I am still unclear on at least 3 points in 8.4.1:

1 - Does each new confirming-commit to extend the timer
    (i.e., <confirmed/> included in the 2nd to Nth <commit>)
    reset the saved config that will be used to rollback
    if needed?

    The 'revert' text says 'the' confirmed commit, but there
    can be more than one of these, right?  Or is the first commit
    the confirmed-commit, and all others are the confirming-commit,
    even if they do nothing but extend the timer?

2 - There is nothing in the NETCONF protocol to support the sentence below:

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

   The only standard way to do this is to terminate the 'magic' session
   that triggers the rollback sequence.

3- If the candidate and/or running was not locked by the original
   session that issued the first confirmed-commit, but one or both
   is locked by another session before the confirmed-commit finishes:

      - the original session is now incapable of issuing commit
        because running and/or candidate is locked.

      - if the confirmed-commit times out or the
        originator's session is terminated, then 1 of 2 'rules'
        cannot be honored (A or B must be true, but not both):

        outcome A) the lock fails and the rollback works:
                  rollback prevents the lock semantics
                  from being honored

        outcome B) the lock works and the rollback fails:
                   lock prevents the semantics of :confirmed-commit
                   from being honored

Is there any consensus that any text in 8.4.1 needs to be altered,
or are these 'server free to decide' issues?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Sep 2009 22:56:02 +0200 (CEST)

>     even if they do nothing but extend the timer?

I agree that this needs to be clarified.  I'm sure different people
have interpreted this text differently.  I thought the second
confirming-commit does not reset the saved config, i.e. each
additional confirming-commit would just extend the timer, but I don't
know if this was the original intention.

>    that triggers the rollback sequence.

Yes, I think this text should be removed, or if we do a
confirmed-commit:1.1 we can clarify this text.

> or are these 'server free to decide' issues?

This must be fixed.  There is actually a trac ticket for this
issue (http://trac.tools.ietf.org/wg/netconf/trac/ticket/17), and it
was brought up by Balazs on the ML
(http://www.ietf.org/mail-archive/web/netconf/current/msg02753.html).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Sep 2009 15:30:03 -0700

> know if this was the original intention.

I don't remember any discussion on it.

I interpret it to mean only the first commit
saves the backup-copy.

As each new edit-candidate+confirmed-commit extends the
timer and alters running, the non-original edits
are going to get zapped along with all the others.

> confirmed-commit:1.1 we can clarify this text.

It should say s/restore the configuration/restore the configuration
by terminating the session/

> (http://www.ietf.org/mail-archive/web/netconf/current/msg02753.html).

Well, denying the lock request seems bad because the original user
ignored locks.  He is the one who should get stomped on.
IMO, the lock should be honored and the rollback should fail.

Another issue is warnings//notifications.
IMO, a <confirmedCommit> event would help,
with a (started, canceled, finished) status enum.
It doesn't seem like we will ever use warnings,
because <ok/> and <rpc-error> can never appear together.
At least a notification gives some warning that config-clobbering
mode is active.

Andy

---

From: WashamFan <[email-masked]>
Date: Tue, 22 Sep 2009 13:27:17 +0800

Hi,
 
>  IMO, the lock should be honored and the rollback should fail.

I agree that lock requested by another session should be honored, as
<confirmed-commit> didn't imply lock acquisition automatically. But I think
some text like below could be added:
It is RECOMMENDED that grab a lock before <confirmed-commit> if there
might be a potential interruption later.

washam

>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>