Subject: RE: replayLogStartTime

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Sep 2007 08:29:08 -0400

Hi

Fair enough. It does allow you to tell the difference if the start time
is 1pm, you asked for 2pm, and the first notification replayed was from
2:30. We could change it to be the timestamp of the start of the log
which handles both cases. Is that what people want to do.

And did people only want this object present when replay is supported on
that stream?

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 2:50 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: replayLogStartTime

"Sharon Chisholm" <[email-masked]> wrote:
> Hi
> 
> This timestamp helps differentiate the cases that there are no logs in

> the log for a particular time period and there were no logs generated 
> for that period. The replayed events start at 2pm, is that because the

> log start them or there were no events between 1 and 2, for example.
> 
> We have seen two designs of this object
> 	- present only when replay is supported
> 	- always present, but with a particular value when replay isn't 
> supported
> 
> Back when we could replay the future, the latter was the better option

> since it was possible to just return 'now' as the value while replay 
> is supported to only support future replays.
> 
> Now, I could go either ways. I know that in the past not all SNMP 
> tools faired well with holes. I expect XML tools to fair better. The 
> important thing is to be clear in whichever we choose.

And the current text isn't very clear, since it says

  The timestamp of the earliest available notification in the log

so what happens if there is no such notification at all?

/martin

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Sep 2007 15:14:06 +0200 (CEST)

"Sharon Chisholm" <[email-masked]> wrote:
> which handles both cases.

So you want the value to be the timestamp of the first notification in
the log if any notifications are present, and log creation time
otherwise?   That would work, but more descriptive text that "start of
log" is needed.

> And did people only want this object present when replay is supported on

Yes.

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Sep 2007 11:23:16 -0400

Huh? I think I missed something.

1. Capability # notification is <create-subscription>

2. Presence of replaySupport object against a stream means that stream
supports replay.

Then we are discussing specific behaviour of the replayLogStartTime
object. Nothing in this object indicates whether or not functionality is
supported. It only tells you how much stuff is available in the log at
this point in time.  

I don't think we want it conditional like Martin indicated. I think we
need to pick one of

A. It is the timestamp of the earliest notification in the log
B. It is the timestamp of the start of the log.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 11:00 AM
To: Martin Bjorklund
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: replayLogStartTime

Martin Bjorklund wrote:
>> Fair enough. It does allow you to tell the difference if the start 
>> time is 1pm, you asked for 2pm, and the first notification replayed 
>> was from 2:30. We could change it to be the timestamp of the start of

>> the log which handles both cases.
> 

>> And did people only want this object present when replay is supported

>> on that stream?

So:

capability #notification set means the <create-subscription> operation
will be accepted.

capability #replay set means the startTime and stopTime parameters will
be accepted.

replayLogStartTime set means there is a replay log.

Capability #replay set but no replayLogStartTime means that the
completely proprietary replay log collection control setup has not been
done.

Since there are no standard controls over the size and start time of the
replay log, this timestamp object is the read-only indication of any
replay config changes, plus an indication of the implied
'delete-oldest-first' garbage collection activity.

> /martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Sep 2007 08:35:53 -0700

> 2. Presence of replaySupport object against a stream means that stream

oops -- you are right.
I confused it with the #interleave capability

> B. It is the timestamp of the start of the log.

Agreed -- it should be (A), since from a NETCONF manager POV,
there is no difference between no replay log and an empty replay log.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Sep 2007 08:00:04 -0700

So:

capability #replay set means the startTime and stopTime parameters
will be accepted.

Capability #replay set but no replayLogStartTime means that the
completely proprietary replay log collection control setup
has not been done.

Since there are no standard controls over the size and start time
of the replay log, this timestamp object is the read-only indication
of any replay config changes, plus an indication
of the implied 'delete-oldest-first' garbage collection activity.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Sep 2007 19:11:06 +0200 (CEST)

> there is no difference between no replay log and an empty replay log.

Yes, IMO B doesn't make much sense.  With A, the manager can see if it
has missed any notifications.

So we come back to my original issue. If it's not conditional, what is
it's value:

 1) if replay is not supported on the stream?
 2) if replay is supported on the stream but there are no entries in
    the log?

One solution is of course to provide some kind of dummy value, but I
don't see the point in that.

Another solution, which is my suggestion, is to make the object
conditional - in these cases the object instance will simply not be
present.

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Sep 2007 13:15:47 -0400

Hi

By the way, this seems to be the last loose end before I can complete
-09.

<Martin>
</Martin>

In the current version (or at least the version on my hard drive), the
object is conditional. So if replaySupport is not true, this object is
not there. That covers this use case. 

<Martin>
</Martin>

B handles this case better then A since its value is Tuesday 8am
regardless. For the A case, we could always may this current time, but
that's potentially confusing.

Sharon

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 1:11 PM
To: [email-masked]
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: replayLogStartTime

Andy Bierman <[email-masked]> wrote:
> > object. Nothing in this object indicates whether or not 
> > functionality is supported. It only tells you how much stuff is 
> > available in the log at this point in time.
> > 
> > I don't think we want it conditional like Martin indicated. I think 
> > we need to pick one of
> > 
> > A. It is the timestamp of the earliest notification in the log B. It

> > is the timestamp of the start of the log.
> > 
> 
> Agreed -- it should be (A), since from a NETCONF manager POV, there is

> no difference between no replay log and an empty replay log.

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 5 Sep 2007 14:10:49 -0400

Hi

It does have a minOccurs of 0. I like the idea of having two conditions
on its existence 

1) replaySupport == true
2) content in log

I think this is easy enough to understand.  My earlier interpretation on
making this field conditional was something different.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 1:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: replayLogStartTime

> not there. That covers this use case.

This does not help.
As Martin pointed out (a few times now) there needs to be a
minOccurs="0" clause in the <replayLogStartTime> element, and the
condition is not just if replay is supported on the stream, but also if
there are any entries in the log at the moment.

It is possible replay is supported on the stream, but the log is not
currently running or it is empty.  Who knows what proprietary replay
control mechanisms (like reset-log) will be supported, so it is better
to just not have this object present unless there is at least one log
entry.

> that's potentially confusing.

Yes, very confusing, especially with clock skew between the machines to
deal with.  IMO, no object instance means nothing to check in the log,
and object present means there is something to check in the log.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Sep 2007 10:56:46 -0700

> not there. That covers this use case. 

This does not help.
As Martin pointed out (a few times now) there needs
to be a minOccurs="0" clause in the <replayLogStartTime> element,
and the condition is not just if replay is supported on the
stream, but also if there are any entries in the log at the moment.

It is possible replay is supported on the stream, but the
log is not currently running or it is empty.  Who knows
what proprietary replay control mechanisms (like reset-log)
will be supported, so it is better to just not have this object
present unless there is at least one log entry.

> that's potentially confusing.

Yes, very confusing, especially with clock skew between the machines
to deal with.  IMO, no object instance means nothing to check in the log,
and object present means there is something to check in the log.

Andy

---

From: Simon Leinen <[email-masked]>
Date: Thu, 06 Sep 2007 19:38:50 +0200

I don't expect anybody to listen, but here's my take on
replayLogStartTime from the point of view of an operator.

As an operator, what I'm interested in is the temporal extent for
which the record of notifications in the buffer is complete.  Assuming
the end of that extent is "now", the ("start") time I need is either

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

But since everybody else on this list is an implementor, you will
simply ignore this as overly complicated/hard to implement.
-- 
Simon.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Sep 2007 10:51:02 -0700

> simply ignore this as overly complicated/hard to implement.

I don't think we are ignoring comments.
This is the first time you brought up this requirement.
I don't think replayLogStartTime was added with much WG discussion
at all, so it is not surpising that there is not much agreement
on how it works, or even why it is needed.

I would prefer that the replayLogStartTime not change constantly,
but people seem to want to use it to optimize the startTime parameter.
You are describing some different, more traditional data objects.
Following good MIB design practices, one would likely put
a replayLastDroppedTime type of object in the MIB module.
Then one might discover that drops before the log are also
interesting and we should monitor that event as well.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Sep 2007 19:51:49 +0200

Actually I would hope that

1. your input is listened by and answered by the implementers on the
list. 
2. more operators participate in such discussions, articulate their
needs and provide feedback to the solutions that are proposed

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Leinen
> Sent: Thursday, September 06, 2007 8:39 PM
> To: Sharon Chisholm
> Cc: Andy Bierman; Martin Bjorklund; [email-masked]

....

[some crazy operator requirements]

.....

> But since everybody else on this list is an implementor, you 
> will simply ignore this as overly complicated/hard to implement.
> --
> Simon.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Sep 2007 21:14:33 +0200 (CEST)

>   recent notification that had to be dropped.

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'd be happy if the definition of replayLogStartTime stated that it's
the log creation time unless there are any entires in the log.

> simply ignore this as overly complicated/hard to implement.

I will simply ignore that comment :)

/martin

---

From: Simon Leinen <[email-masked]>
Date: Fri, 07 Sep 2007 10:56:15 +0200

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.

> the log creation time unless there are any entires in the log.

I think that's a natural and useful generalization.

> I will simply ignore that comment :)

Sorry for that comment of mine, I admit that it was uncalled for.
-- 
Simon.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Sep 2007 11:18:26 +0200 (CEST)

> notification logs, we actually like those :-), the approximation can

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:

Maybe modify the name replayLogStartTime as well...

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 7 Sep 2007 07:20:31 -0400

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?

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 5:18 AM
To: [email-masked]
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked];
[email-masked]

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:

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Sep 2007 09:12:28 -0700

> 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?

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 9 Sep 2007 19:42:22 -0400

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.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 12:12 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]; [email-masked]
Subject: Re: replayLogStartTime

I like Simon's proposal.

   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?

Andy

> to assume that he has missed some notifs.  Which may or may not be
true.
> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Sep 2007 17:25:57 -0700

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

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Sep 2007 07:24:51 -0400

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:[email-masked]] 
Sent: Sunday, September 09, 2007 8:26 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]; [email-masked]
Subject: Re: replayLogStartTime

Sharon Chisholm wrote:
> second object has a name without a negative connotation but has the 
> same value.
> 

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.

Andy

>>>> think both definitions work equally well - the reason this object 
>>>> is there is to let the client know if it has missed any notifs.

>> the

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2007 07:13:47 -0700

> indication of filtering criteria. I think these management objects could

okay -- but it is understood that the object is not going
to be that helpful if the agent ages out debug messages in 3 hours
and critical alarms in 1 week.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Sep 2007 12:04:03 -0400

Hi Simon,

I think your comment is unfair to implementers.

We will ignore your operator-input because we are IETF NM protocol
designers. ;-)

dbh 

> Sent: Thursday, September 06, 2007 1:39 PM
> To: Sharon Chisholm

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Sep 2007 12:40:48 -0400

Hi,

I agree it is important to not dictate age as the drop-selector.

dbh

> [mailto:[email-masked]] On Behalf Of Andy Bierman