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