[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?

I've got to say, I've seen cleaner designs in my career.
This whole replay/live/termination/interleaving design is
really a mess.  The interleaving seems to be a big concern
to some people.  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/>