[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replayLogStartTime
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.
Sharon
-----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/>