RE: example notification seems redundant

["Sharon Chisholm" <schishol@nortel.com>]

hi

Your the one who brought up the content discussion :-) As previously
indicated, there are significant benefits to being able to send
notifications with Netconf content. In addition, there are some gaps
between existing solutions and what is required. If you make too many
changes to existing solutions, they risk not interoperating with
deployed versions of itself. You risk ending up with the worst of both
worlds - a new protocol and one that still requires expensive mediation
to exchange information with Netconf-based ones.

The content discussion I was referring to is in Appendix B1, starting on
page 38.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Friday, April 07, 2006 1:10 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: example notification seems redundant


Sharon Chisholm wrote:
> hi
> 
> There are really then three different use cases at work here
> 
> 1) I am the originator of the request and I would like some concise 
> indication that things worked out OK in the end for some reason or 
> other
> 

We have <rpc-reply> for this already.

> 2) I am creating an audit log and need to know exactly what was done 
> and by whom and how

This is a use case for a traditional dedicated notification generator ->
receiver application.

> 
> 3) I am a user of the configuration information and need to know what 
> information has been changed. This covers the cases of configuration 
> mirroring, configuration applications and people just interested in 
> the device inventory for whatever reason.

There are several ways to do this already, such as
retrieving the configuration before the change and
again after the configuration.  The application
making the changes should also know, otherwise
it might carelessly clobber existing config data.

However, this still seems like a use case for the
traditional centralized notification service, not a
per-session model.

I am in favor of a netconf capability for notifications,
which means delivery of content-independent notifications
on a session (mandatory: dedicated; optional: mixed).

The syslog WG is going to have to be responsible for standardizing
syslog content, not the netconf WG. Beyond a standard content type
wrapper for <syslog-text>, and maybe <syslog-xml>, I don't believe the
netconf WG is the right place to work on syslog.


> 
> The example content in the appendixes cover the second and the third 
> cases. I believe the message content is different for the three use 
> cases.

What page #s?

> 
> Sharon


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