[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replayLogStartTime
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.
> I'd be happy if the definition of replayLogStartTime stated that it's
> the log creation time unless there are any entires in the log.
I think that's a natural and useful generalization.
>> But since everybody else on this list is an implementor, you will
>> simply ignore this as overly complicated/hard to implement.
> I will simply ignore that comment :)
Sorry for that comment of mine, I admit that it was uncalled for.
--
Simon.
--
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/>