Re: replayLogStartTime

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
> Hi
>
> By the way, this seems to be the last loose end before I can complete
> -09.
>
> <Martin>
>  1) if replay is not supported on the stream?
> </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. 

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.


> <Martin>
>  2) if replay is supported on the stream but there are no entries in
>     the log?
> </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.

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.

> Sharon

Andy

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com] 
> Sent: Wednesday, September 05, 2007 1:11 PM
> To: ietf@andybierman.com
> Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ops.ietf.org
> Subject: Re: replayLogStartTime
>
> Andy Bierman <ietf@andybierman.com> wrote:
> > Sharon Chisholm wrote:
> > > 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.
> > Agreed -- it should be (A), since from a NETCONF manager POV, 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


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