[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 2.2) Notifications Proposal
Just one suggested modification to this proposal:
We should consider punting rfc 3195 to a companion document,
so it's not built-in to the base netconf protocol spec.
Rob
On Tue, Dec 02, 2003 at 03:51:54PM -0800, Andy Bierman wrote:
>
> - yes but don't define too many details in the netconf spec.
> - remove <notification> element. A specific notification
> scheme will define the top level element
> - protocol will define a conceptual channel for notifications.
> - the notification channel will only be supported if the
> underlying application mapping supports channels and if
> notifications are enabled after the capabilities exchange.
> - <open-notification> and <close-notification> may be kept or
> removed. This is added complexity without much gain.
> - The <matching> parameter for <open-notification> will be
> removed because it is unspecified and offers no chance for
> interoperability.
> - Use RFC 3195 (Reliable syslog) for notifications in v1.0.
> This is only available over BEEP. Other application mappings
> may define support for 3195 (or another scheme) in the future.
>
>
> --
> 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/>
--
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/>