[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
notification issues update (draft)
- To: "Netconf (E-mail)" <netconf@ops.ietf.org>
- Subject: notification issues update (draft)
- From: Andy Bierman <ietf@andybierman.com>
- Date: Thu, 23 Aug 2007 00:24:09 -0700
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
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 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/>