Hi
The draft does not specify the criteria used to age out notifications.
It doesn't assume it is the oldest, except perhaps that
replayLastAgedTime is less useful if it isn't. If you are aging on
severity, then what you would want is earliest notification and some
indication of filtering criteria. I think these management objects could
be added safely later.
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Sunday, September 09, 2007 8:26 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; simon.leinen@switch.ch; netconf@ops.ietf.org
Subject: Re: replayLogStartTime
Sharon Chisholm wrote:
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.
This is fine.
I have one final concern wrt/ replay, that may need 1 sentence to
address.
I do not want to rule out replay implementations that garbage collect
with some algorithm other than oldest-first. I can imagine an
algorithm
that considered the (non-existent) eventSeverity, e.g., delete all the
debug notifications first and none of the critical or severe faults.
Would this be compliant with the draft? Does the draft need to say more
about how the agent is expected to handle replay aging?
Does the proposed design prevent any replay buffer design other than
age-oldest-first? I don't know, but the text should say there is no
requirement that the replayLastAgedTime always moves forward, and never
backward.
Sharon
Andy
-----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/>
--
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/>