Re: notification issues update (draft)

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> "Sharon Chisholm" <schishol@nortel.com> wrote:
> > <Andy>
> >    - the replayComplete event type is renamed to notificationComplete.
> >      It is sent if stopTime is present, just before the agent returns
> >      to accepting all RPC operations (normal mode).
> > </Andy>
> >
> > I'm not sure I agree with this one. This is the notification that gets
> > sent after replayed notifications are sent and before real-time ones are
> > sent (if applicable). Calling it notificationComplete would seem to
> > imply something else.

This event (see below) is not very interesting to the manager.


> We discussed this in Chicago.  There are two things that can happen:
>
>   1.  when the last replayed notif has been sent, and the live feed
>       starts. (replayComplete)
>
>   2.  when a stopTime is given, and the last notif has been sent;
>       after this the session switches back to normal command-response
>       mode. (notificationsComplete)
>
> A manager needs to know when the session switches back to normal mode,
> so item 2 must be signalled.  However, it has been argued that a
> manager doesn't care about item 1.

Maybe it isn't clear to everyone that both conceptual events
(replayComplete and notificationComplete) happen whenever
replay is supported by the agent and requested by the manager.

If startTime is present:
  1) send zero or more notifications from the replay buffer (as requested)
  2) replayComplete event occurs  (not needed!!)
  3a) If stopTime is in the past when create-subscription runs:
       - notificationComplete event occurs
  3b) Else if stopTime is in the future:
       - agent waits until some time after stopTime, and generates all
         notifications that happened after <create-subscription> and
         until eventTime >= stopTime.
       - notificationComplete event occurs
  3c) Else if stopTime not present:
       - agent waits until session termination, and generates all
         notifications that happened after <create-subscription>
       - there is no notificationComplete event in this case
         because the session is terminating

If startTime is not present:
 1) generate zero or more live notifications (eventTime >= now)
    until the session is terminated


One more detail I left out (probably in the draft already)

  - If replay is not supported on a stream, then an error is
    returned if startTime or stopTime is present in <create-subscription>




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