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.)
> > 
> 
> This really puts the "mode changes" issue front and center.
> So stopTime in the future means "just stop sending notifications".
> Does the session hang (waiting for session termination) or
> does it silently revert to "normal mode" at the stopTime?

We already have the mode switch thing -- you always get a mode switch
if you use startTime and stopTime.

> I've got to say, I've seen cleaner designs in my career.
> This whole replay/live/termination/interleaving design is
> really a mess.

I agree.

> The interleaving seems to be a big concern
> to some people.

To who???  I think most people are in favor of interleaving.


/martin


> IMO, the manager MUST be able to send
> at least a <close-session> operation.  I don't care as much
> about interleaving because sessions are not that expensive.
> But the <kill-session> termination mechanism and silent transitions
> back into "normal" node or "hang" mode (like (D) above) are really a problem.
> 
> 
> > A special "now" value for the stopTime seems useful - it's like a
> > 'cat' on the file.
> 
> It also supports the use case where the manager has code
> that is designed to start listening to live notifications 'now',
> and back-fill via a notification log (ala SNMP). (What? Use 2 sessions!)
> 
> Andy
> 
> > 
> > 
> > /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/>