Re: [Netconf] Is there a problem with confirmed commits?

["Jonathan Hansford" <[e-mail]>]

I think the text you refer to on page 45 is open to interpretation. If a 
persistent confirmed commit has occurred then the changes have been 
committed (albeit in a confirmed commit), and the candidate and running 
configuration datastores are the same (unless and until the confirmed 
commit times out). The text depends on the definition of 'modified' (and 
how the server detects it) and 'committed'.

------ Original Message ------
From: "Juergen Schoenwaelder" <[e-mail]>
To: "Jonathan Hansford" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 14/01/2019 15:40:26
Subject: Re: [Netconf] Is there a problem with confirmed commits?

>It seems the <candidate> datastore should not be allowed to be used as
>long as a persistent confirmed commit is still ongoing. I leave it to
>Martin to check whether this is said somewhere or an omission.
>
>In general, an application can't assume that <candidate> contains
>anything sensible. Hence, the proper way is to lock <candidate> and
>then to make sure it contains something sensible, i.e., issuing a
>discard_changes. And I think implementations should not allow an
>application to obtain a lock on <candidate> while a commit is active.
>The text on page 45 already says:
>
>       A lock MUST NOT be granted if any of the following conditions is
>       true:
>
>       [...]
>
>       *  The target configuration is <candidate>, it has already been
>          modified, and these changes have not been committed or rolled
>          back.
>
>I think this covers the case of an ongoing but not completed
>persistent confirmed commit, no?
>
>/js
>
>On Mon, Jan 14, 2019 at 03:14:02PM +0000, Jonathan Hansford wrote:
>>  If a persistent confirmed commit has not timed out, the running
>>  configuration datastore will be the same as the candidate and
>>  <discard-changes> won't change its contents. Any edit of candidate will be
>>  based on the configuration resulting from the persistent confirmed commit.
>>
>>  If the persistent confirmed commit has timed out, the running configuration
>>  datastore will have reverted and <discard-changes> will change candidate.
>>  Any edit of candidate in this case will be based on the configuration prior
>>  to the start of the persistent confirmed commit.
>>
>>  ------ Original Message ------
>>  From: "Juergen Schoenwaelder" <[e-mail]>
>>  To: "Jonathan Hansford" <[e-mail]>
>>  Cc: "[e-mail]" <[e-mail]>
>>  Sent: 14/01/2019 13:50:56
>>  Subject: Re: [Netconf] Is there a problem with confirmed commits?
>>
>>  > Hi,
>>  >
>>  > I have not yet understood where you see a problem. In general,
>>  > <candidate/> contains arbitrary stuff and hence it is the client's
>>  > responsibility to clear any arbitrary stuff found in <candidate/>
>>  > after obtaining a lock. If does not really matter whether there has
>>  > been a failed confirmed commit before or something else. I think the
>>  > general safe pattern is:
>>  >
>>  > lock(candidate)
>>  > discard_changes()
>>  > push_whatever_needed()
>>  > commit()
>>  > unlock(candidate)
>>  >
>>  > If you do a confirmed commit and the session disappears, then the lock
>>  > will disappear as well. But I do not think this creates a race
>>  > condition, or I am just not yet seeing it. Perhaps it helps to write
>>  > down the sequence of actions that leads to a race.
>>  >
>>  > /js
>>  >
>>  > On Mon, Jan 14, 2019 at 12:50:38PM +0000, Jonathan Hansford wrote:
>>  > >  Hi,
>>  > >
>>  > >  No one seems to be responding to my email and proposed erratum around
>>  > >  the subject of confirmed commits (apart from Martin), but I would really
>>  > >  like to know it I am missing something here. As far as I can tell,
>>  > >  session termination during a confirmed commit leads to unpredictable
>>  > >  behaviour and I would like to know whether anyone is using confirmed
>>  > >  commits and how (if at all) they address the issues outlined below. My
>>  > >  assumptions are that locks are used and :writable-running is not
>>  > >  supported.
>>  > >
>>  > >  If the <candidate> and <running> configuration datastores are locked to
>>  > >  prevent concurrent access, and a confirmed commit sequence is
>>  > >  interrupted by the session terminating, the locks will automatically be
>>  > >  released but the server MUST NOT accept a lock on <running> from any
>>  > >  session if another session has an ongoing confirmed <commit>.
>>  > >  Consequently, after session termination no client can acquire a <lock>
>>  > >  on <running>, not even the one that initiated the confirmed <commit>,
>>  > >  until after the confirmed <commit> has timed out. However, if the
>>  > >  confirmed <commit> included the <persist> parameter, the original client
>>  > >  could still issue a <commit> using the persist-id to complete the
>>  > >  sequence prior to the timeout, even without a lock.
>>  > >
>>  > >  Of course, the problem now is the race for the new lock on <candidate>.
>>  > >  If the original client is successful then all is good. But if a new
>>  > >  client locks <candidate> before the timeout on the confirmed commit,
>>  > >  whether or not they precede <lock> with <discard-changes>, <candidate>
>>  > >  will be the same as <running> and the new client will pick up everything
>>  > >  from the previous session. However, the client won’t be able to lock
>>  > >  <running> until after the timeout, at which point <running> reverts but
>>  > >  <candidate> still represents the previous session. If the client tries
>>  > >  to lock <candidate> after the timeout, <running> will have reverted and
>>  > >  the lock will only be granted after a <discard-changes> which will cause
>>  > >  the <candidate> to revert. So, depending on when the lock on <candidate>
>>  > >  occurs relative to the confirmed commit timeout, the client could be
>>  > >  editing <candidate> in one of two states. Further, before the timeout on
>>  > >  the confirmed commit, even if the new client has locked candidate, the
>>  > >  original client could still issue a confirming commit (they don’t need a
>>  > >  lock on <candidate> to do so) which would persistently commit any edits
>>  > >  made by the new client. NOTE: it is not the use of the persist-id that
>>  > >  introduces this behaviour; a new client would have the same problem even
>>  > >  if a confirmed commit was not intended to persist beyond a session
>>  > >  termination.
>>  > >
>>  > >  If the server also supports the :startup capability then, if the session
>>  > >  termination was due to the server rebooting, the behaviour above would
>>  > >  be further complicated by <running> now containing the configuration
>>  > >  from the <startup> configuration datastore.
>>  > >
>>  > >  Am I right?
>>  > >
>>  > >  Jonathan
>>  > >
>>  > >  ---
>>  > >  This email has been checked for viruses by Avast antivirus software.
>>  > >  https://www.avast.com/antivirus
>>  >
>>  > >  _______________________________________________
>>  > >  Netconf mailing list
>>  > >  [e-mail]
>>  > >  https://www.ietf.org/mailman/listinfo/netconf
>>  >
>>  >
>>  > --
>>  > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>  > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>  > Fax:   [phone]         <https://www.jacobs-university.de/>
>
>--
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   [phone]         <https://www.jacobs-university.de/>