Subject: Real Notification Requirements

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Mar 2006 07:48:34 -0800

Hi,

This new thread is for people to articulate use cases
to support functional requirement requests. 

Translation: What is the developer or operator doing now, and
how will it change to something great and wonderful because
of this new feature?

Let's try some top-down design, since ad-hoc design isn't
going so well.

I believe there is consensus so far for 2 uses of notifications
in the NETCONF protocol:

Content Layer Requirements
--------------------------

C1) 'Full XML' or 'XML Wrapper' notification for SYSLOG content

C2) NETCONF configuration change notification

C3) ???

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Mar 2006 20:28:28 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Netconf (E-mail)" <[email-masked]>
> Sent: Monday, March 27, 2006 7:48 AM
> Subject: Real Notification Requirements

...
> Content Layer Requirements
...

Based on experience with a product for which management protocol was
the sole means of configuration, the following are some events that the
notification protocol should be able to represent.  (there were more, but
these are some I remember as being important to the configuration
management part)  These are low-level, but I think they make the point that
configuration change notification isn't the only thing a configuration management
system will need to know about.

   - (configurable) hardware resource added (e.g. card plugged into chassis of
     running system, or a cable to an expansion chassis plugged in)
   - hardware resource removed (e.g. card pulled out of running system, or
     expansion chassis cable unplugged)
   - failover in n:m redundancy (failover results in 1 of m posible configurations
     being activated on 1 of the n backup resources - this is a very interesting event)
   - system reverting to configuration version foo (because version bar is corrupt
     or has become unusable, e.g. due to swapped hardware version compatibility issues)
   - configuration data store off-line (e.g., disk drive failed or removed from chassis)

Randy

---

From: Shane Kerr <[email-masked]>
Date: Tue, 28 Mar 2006 17:02:25 +0200

> Content Layer Requirements

I had a quick look at draft-ietf-syslog-protocol-16, and was interested
to see it supports structured data in addition to traditional syslog
free-form text. It also has a way for vendors to specify their own
structured data identifiers, and several standard ones defined already.

I wonder what the key differences are between the SYSLOG stuff and
anything within the NETCONF notification. Perhaps:

- XML (of course)
- Registration vs. complete log feed

Is there anything else?

Perhaps it would be better to focus on adding a subscription mechanism
to SYSLOG?

--
Shane

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Mar 2006 17:18:11 +0200

> Perhaps it would be better to focus on adding a subscription mechanism

Certainly an option. Having a subcription mechanism is actually for me
an important feature. Some 12 years ago, we hacked our central syslog
daemon to actually ship syslog messages once you connected to it and
it was a lovely hack which we used a lot (since it makes access to
syslog message real simply for programs).

On the classification question: I think you can put anything into
syslog, so the distinction between syslog messages, configuration
change notifications, or SNMP notifications is kind of artificial.

In fact, it seems popular in many operational environments to have
SNMP notification receivers which simply write to syslog, probably
because there are also pretty nice syslog readers that can trigger all
sorts of actions when they discover certain input patterns.

If we do an interim, it would be valuable to get some syslog experts
there as well so that we can evaluate whether structured syslog and
syslog enhancements will actually solve the problem.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 28 Mar 2006 20:12:27 +0200

Plugging in a new blade.  Most of the network boxes I deal with are chassis with
hot-pluggable blades.  When  a new blade is plugged in, or an old one removed,
then I want a notfication so that the other party has a chance to amend the
configuration.

Tom Petch

---

From: David Harrington <[email-masked]>
Date: Tue, 28 Mar 2006 15:38:05 -0600

Hi,

I don't doubt the usefulness of notifications. That's why syslog and
snmp notifications are commonly available in devices.

I am not convinced we need to deliver the notifications via Netconf. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Tuesday, March 28, 2006 12:12 PM
> To: Andy Bierman; Netconf (E-mail)
> Subject: Re: Real Notification Requirements
> 
>