Subject: notification issues update (draft)

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2007 00:24:09 -0700

Hi,

There has been some off-line discussions with the people raising
big concerns with the notification design.  The following
changes and decisions seem to reflect the widest consensus
and the next revision (notification-09), due around Sept. 7,
will (hopefully) reflect these changes/decisions:

   - the mandatory eventTime element will be added to the
      notification element, as per Martin's XSD fragment.

   - the agent must always accept close-session, even if delivering
     notifications.

   - the agent may accept more RPC operations during notification
     delivery, and will advertise a new capability (e.g., interleave)
     to indicate it supports this optional feature.

   - multiple calls to create-subscription should not be done.
     An agent should reject this request with a 'resource-denied' error
     if notifications are already being delivered.

   - if the agent does not support the interleave capability, and
     receives an RPC operation other than 'close-session', it
     should return a 'resource-denied' error.

   - notification filter parameters startTime and stopTime refer to the
     eventTime values of the notifications.

   - notification filters are applied to the notification element contents.

   - startTime in the future is an error.

   - stopTime in the future indicates the eventTime value for
     stopping notification delivery.  (The agent exits notification
     delivery after this time passes and all notifications with
     timestamps before this time are delivered).

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

   - The agent will seamlessly transition from replayed notifications
     to notifications received after the create-subscription started,
     if stopTime is not present, or present but in the future.

   - if stopTime is not present, the notification delivery will continue
     until the session is terminated somehow: (close, kill, drop)-session.

   - there is no need for a 'now' parameter, since the eventTime
     element has been added to the notification.

Clear as mud?

If anyone has any strong objections to these decisions, they should
send an email to this mailing list by August 26.

thanks,
Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 23 Aug 2007 07:14:32 -0400

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

Sharon

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Aug 2007 13:50:06 +0200 (CEST)

> sent (if applicable). Calling it notificationComplete would seem to

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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2007 08:32:56 -0700

>> sent (if applicable). Calling it notificationComplete would seem to

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

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

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 23 Aug 2007 12:15:06 -0400

Hi

Actually we do. I've just heard from a colleague on this and he says
they need this notification to trigger that it is time to perform
mark&delete resynch clean-ups. 

Sharon

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Thursday, August 23, 2007 7:50 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: notification issues update (draft)

> sent after replayed notifications are sent and before real-time ones 
> are sent (if applicable). Calling it notificationComplete would seem 
> to imply something else.

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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2007 09:39:00 -0700

> mark&delete resynch clean-ups. 

Hmmm... the manager could do that based on eventTime, but whatever.

So is it okay with everyone if we have both event types?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Aug 2007 18:48:33 +0200 (CEST)

> Hmmm... the manager could do that based on eventTime, but whatever.

Yes I don't quite understand what "mark&delete resynch clean-ups"
means... why can't it be done with notificationComplete?

> So is it okay with everyone if we have both event types?

So notificationsComplete marks the switch back to normal mode, and
replayComplete marks the end-of-buffered events.

What if stopTime < now?  Will you get both events?  Or will you get
replayComplete *only* when EOF on the log is reached?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2007 10:00:59 -0700

> means... why can't it be done with notificationComplete?

I'm not that sure either, but I figure it's not important
enough to argue over.  Perhaps it refers to overlap in the
replayed notifications stored on the manager?

> replayComplete *only* when EOF on the log is reached?

Yes, you would get both events, so the meaning of replayComplete
is not overloaded, and event-specific handlers do not have to be
aware of the stopTime value at all.

Andy