Subject: replayLogStartTime

From: Martin Bjorklund <[email-masked]>
Date: Tue, 28 Aug 2007 11:16:57 +0200 (CEST)

Hi,

We briefly talked about this in Chicago.

The draft says, about replayLogStartTime:

    The timestamp of the earliest available notification in the log
    used to support the replay function. This object MUST be present
    if replay is supported.

What should this timestamp be if there are no entries in the log?  

Since there's already a replaySupport element, which indicates if the
stream supports replay, I suggest that the replayLogStartTime should
not be present if there are no entries in the log.  The text could
maybe be changed to

    The timestamp of the earliest available notification in the log
    used to support the replay function. This object MUST be present
    if replay is supported and there are entires in the log.

/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: Andy Bierman <[email-masked]>
Date: Tue, 28 Aug 2007 07:35:45 -0700

>     if replay is supported and there are entires in the log.

What is the purpose of this timestamp within the overall system?

Is the manager supposed to check this object before every
call to create-subscription?  The intended algorithm
should be in the draft, since the author obviously has one in mind.

I have some concern about an object instance that comes and goes,
and keeps changing, because of the complexity on the agent and manager.
Does this place implementation restrictions on the log?
Do entries always have to be added with ever-increasing eventTime
values?  This may be difficult if multiple sub-agents feed the log,
and the timestamp is not centrally generated.  I.e., can replayLogStartTime
ever go backwards?  Can it disappear and come back with a lower value?

On the other hand, a static timestamp representing the file creation
time of the log is not very useful for picking optimal startTime values.

(BTW, how come there are all these bells and whistles for replay,
but no switch to actually turn it on or off?  Oh yeah, that's
configuration, so it's out of scope ;-)

> /martin

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 28 Aug 2007 14:25:21 -0400

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.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Tuesday, August 28, 2007 10:36 AM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: replayLogStartTime

Is the manager supposed to check this object before every call to
create-subscription?  The intended algorithm should be in the draft,
since the author obviously has one in mind.

I have some concern about an object instance that comes and goes, and
keeps changing, because of the complexity on the agent and manager.
Does this place implementation restrictions on the log?
Do entries always have to be added with ever-increasing eventTime
values?  This may be difficult if multiple sub-agents feed the log, and
the timestamp is not centrally generated.  I.e., can replayLogStartTime
ever go backwards?  Can it disappear and come back with a lower value?

(BTW, how come there are all these bells and whistles for replay, but no
switch to actually turn it on or off?  Oh yeah, that's configuration, so
it's out of scope ;-)

Andy

> 
> 
> --
> to unsubscribe send a message to [email-masked] with the

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

--
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: Tue, 28 Aug 2007 20:50:22 +0200 (CEST)

> thing is to be clear in whichever we choose.

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

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

/martin