Re: replayLogStartTime

[Martin Bjorklund <mbj@tail-f.com>]

Simon Leinen <simon.leinen@switch.ch> wrote:
> Martin Bjorklund writes:
> > There are two things different from the current spec.  The first
> > part gives you the creation time unless notifs has been dropped.  I
> > think this is good.  The second part is that you want the timestamp
> > of the last notif dropped instead of the timestamp of the first one
> > in the log.  I'm not sure I understand why this would be better.  I
> > think both definitions work equally well - the reason this object is
> > there is to let the client know if it has missed any notifs.
> 
> I think you just answered your own question (why "timestamp of last
> notification dropped" is better): Because it tells me *exactly* from
> when on the record in the notification buffer (or "replay buffer") is
> complete.  (Which is the information you need to find out whether you
> missed something, just expressed as its complement.)
> 
> The time of the oldest notification that still is in the buffer
> (what's currently in the draft) only tells me an approximation, and
> when there was a long period of silence preceding that oldest
> notification (such long periods of silence do occur in our
> notification logs, we actually like those :-), the approximation can
> be very imprecise.

Ok, you've convinced me.  Your definition gives more information to a
client.

With the original definition, if a client's latest notification has
timestamp t, and replayLogStartTime is s, s > t, the client would have
to assume that he has missed some notifs.  Which may or may not be
true.  WIth your definition, if s > t the client knows for sure that he
has missed some notifs.

So, I agree, we should change the semantics of replayLogStartTime to
say what you said:

  * the time the buffer was created and started recording notifications,
    or,
  * if notifications already had to be dropped, the time of the most
    recent notification that had to be dropped.

Maybe modify the name replayLogStartTime as well...


/martin

--
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/>