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

notification issues update (draft)



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