RE: replayLogStartTime

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

Hi

I would be ok with replayLogCreationTime and replayLastAgedTime. The
second object has a name without a negative connotation but has the same
value. 

If there are no objections, this is what I am going to put in the
document, which I plan on submitting tomorrow.

Sharon 

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

Sharon Chisholm wrote:
> 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?

I like Simon's proposal.
Should there be 2 timestamps (per stream)?

   replayLogCreationTime -- if exists, the time the log was opened
   replayLastDropTime -- if exists, eventTime value of the last
notification
            deleted from the replay log

Is the log creation time really needed, or just the timestamp of the
last dropped notification from the log?

> 
> Sharon

Andy

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


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