RE: replayLogStartTime

["Sharon Chisholm" <schishol@nortel.com>]

Hi

It occurs to me that we are trying to overload a single variable with
two bits of information
  - What time the log starts
  - Earliest notification in the log (still need to worry about the no
notification case).

Should we simply have two separate items? Wouldn't that be simpler?

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Friday, September 07, 2007 5:18 AM
To: simon.leinen@switch.ch
Cc: Chisholm, Sharon (CAR:ZZ00); ietf@andybierman.com;
netconf@ops.ietf.org
Subject: Re: replayLogStartTime

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