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

[Andy Bierman <ietf@andybierman.com>]

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

It started out simple enough, just trying
to model the "tail" and "tail -f" modes of
reading a log file.  The design seems to keep
straying away from that model.


> [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.

IMO, this is part of a more general problem,
that should be solved by a separate RFC.

The 'eventClass', 'eventSeverity', and 'eventTime' fields
are meta-data which could be encoded as XML attributes
in the <notification> element.  This should be
required, even if the proprietary <eventType> has
some or all of these fields already.

This is why I keep asking the WG:
Are you SURE you want to forbid all XML attributes, forever,
from being included in the <notification> element?

Are you SURE this is not going to ever come up again
as an issue, because this is the only place we can
really put inter-operable meta-data into the notification message?

(All we need is an 'anyAttribute' clause in the <element>
definition...)


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

What if the stopTime in the future happens before the agent
is done sending the replay notifications?
Does the agent stop, hang, revert to normal mode,
transition to a new mode?

That's why I want to keep it simple.

I guess I never liked the stopTime transition back to normal mode,
and it doesn't matter if it happens when the reply buffer is
empty or at some specified time 'X', after that.


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