[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replayLogStartTime
Hi,
I agree it is important to not dictate age as the drop-selector.
dbh
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Sunday, September 09, 2007 8:26 PM
> To: Sharon Chisholm
> 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/>
>
--
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/>