anchor.diff:      {qwrite_deny, _ReqId, _Round, Lease, {content_check_failed, Reason}}}, State) ->
       ct:pal("split second step failed: ~p~n", [Reason]),
       case Reason of
  -        lease_does_not_exist -> ok;
  -        owner_changed -> ok;
  -        range_unchanged -> ok;
  -        aux_unchanged -> ok;
  +        lease_does_not_exist -> State; %@todo
  +        owner_changed -> State; %@todo
  +        range_unchanged -> State; %@todo
  +        aux_unchanged -> State; %@todo
           timeout_is_not_newer_than_current_lease ->
               % retry
               gen_component:post_op(State, {l_on_cseq, split_reply_step1, Lease, R1, R2,
  
positive.code: -spec delta() -> pos_integer().
  delta() -> 10.
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %
  % qwrite_done messages should always be received by the current owner
  % of the message. The message handler can directly change the lease
  % list in the dht_node. The next message will than be handled under
  % the new lease list.
  %
  % If we would update the lease of another node and the qwrite_done is
  % received by us, the system assumes that the lease was updated but
  % the owner will still work according to the old version of the
  % lease. In some cases such a remote-modify is acceptable and correct.
  % E.g. if we use a remote-modify to extend the lease's range, the
  % remote node can continue to work with his old lease until the next
  % renewal. On renewal, he will notice that it fails because the lease
  % changed and additionally he will get notified of the range
  % extension.
  %
  % The goal is to limited remote-modifies to correct operations,
  % i.e. renewals, aux updates and range extensions.
  %
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %
  
negative.code: % - improve error handling for deny in renewal
  %
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %
  % qwrite_done messages should always be received by the current owner
  % of the message. The message handler can directly change the lease
  % list in the dht_node. The next message will than be handled under
  % the new lease list.
  %
  % If we would update the lease of another node and the qwrite_done is
  % received by us, the system assumes that the lease was updated but
  % the owner will still work according to the old version of the
  % lease. In some cases such a remote-modify is acceptable and correct.
  % E.g. if we use a remote-modify to extend the lease's range, the
  % remote node can continue to work with his old lease until the next
  % renewal. On renewal, he will notice that it fails because the lease
  % changed and additionally he will get notified of the range
  % extension.
  %
  % The goal is to limited remote-modifies to correct operations,
  % i.e. renewals, aux updates and range extensions.
  %
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %
  % Lease agreement
  %
  % Rule 16: The lease's id never changes.
  % Rule 17: Every content check has to perform the checks in the same order.
  %          1. Does the lease exist?
  %          2. Is the value of the owner field as expected?
  %          3. Is the value of the aux   field as expected?
  %          4. Is the value of the range field as expected?
  %          5. Are the values of the epoch and version fields as expected?
  %          6. Is the proposed timeout newer than the current one and is it in
  %             the future (for debugging only)?
  
  
  