Re: Notification #9: replay in the future consensus point

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> Hi,
> >>
> >> I would like people to speak up about the startTime and/or
> >> stopTime parameters in the future issue.
> >>
> >> Do you favor:
> >>
> >> A) return an error if parameters are in the future
> > 
> > Better than B.
> > 
> >> B) return whatever the agent has in its reply log
> >>    that matches the search criteria (at the time the
> >>    request is made). Parameters only refer to the
> >>    timestamps of entries in the log.
> > 
> > No, this seems very confusing.
> > 
> >> C) treat as a request to start returning notifications
> >>    some time in the future, according to the parameters.
> >>    Parameters refer to the 'time window' that notification
> >>    delivery is desired.
> > 
> > I can live with it, but I don't prefer it.
> > 
> > I'd prefer:
> > 
> > D) treat startTime in the future as an error, but stopTime in the
> >    future is ok (it's like giving a startTime w/o a stopTime, but let
> >    the agent stop the notifications at a certain time.)
> > 
> 
> 
> IMO, this filter is not special.
> It is no different than retrieving all the log entries
> from sequence ID 'X' to sequence ID 'Y', via some Xpath filter,

This filter *is* different, because:

   1) if a start time is present, the agent should look in the log
   2) if a stop time is present, notification delivery is terminated by
      the agent and the session becomes normal again.

[But it didn't have to be different - if every event had a timestamp
(as in Sharon's original spec), you could have used the normal filter
mechanism, and let the agent implementor worry about optimizing away
the log search if the timestamp in the filter was late enough.

But if it was a normal filter, the agent would have to check the
stored notifications _unless_ the filter contained the
timestamp/sequenceID.  This is different from today where the default
(no start/stop time) means subscribe to live notifications only.

You would never get back to "normal mode" though.]

> The filter applies to the data in the log, not notifications
> that have not happened yet.

This also makes it different - the other filter applies to all
notifications, logged or live.


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