RE: replayLogStartTime

["Sharon Chisholm" <schishol@nortel.com>]

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: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Tuesday, August 28, 2007 10:36 AM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: Re: replayLogStartTime

Martin Bjorklund wrote:
> 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.
> 

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

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