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