RE: replayLogStartTime

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

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:ietf@andybierman.com] 
Sent: Wednesday, September 05, 2007 1:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; netconf@ops.ietf.org
Subject: Re: replayLogStartTime

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