Subject: Additional proposed update to Netconf Notification Draft

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 15 Jun 2006 14:44:04 -0400

hi

Here are some additional proposed edits in addition to those that I sent
a while back
	https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html

1. Replace the Event Class section with the following:
"
Events can be classified into one more event classes. Each event class
identifies a set of event notifications which
    - share similar content
    - are generated from similar events
   
The initial set of event classes is configuration, fault, state, audit,
data, maintenance, metrics, security, information, heartbeat and
syslogTunnel. See the IANA Considerations section for information on
defining new event classes.

All events shall carry the following data: list of event class,
timestamp and sequence number of the notification. They may also carry
additional data.

A configuration event, alternatively known as an inventory event, is
used to indicate that hardware, software, or a service has been added/
changed/removed.  In keeping aligned with NETCONF protocol operations,
configuration events may included copy configuration event, delete
configuration event, or the edit configuration event (create, delete,
merge, replace). As configuration notifications could potentially carry
huge amounts of data in order to properly support functions such as
security audit logs, so it is expected that netconf clients will
engineer their subscriptions to meet their needs and to not overwhelm
their capacity to process and store event notifications. Examples
include hardware board removed, software module loaded or DNS server
reconfigured. Changes are reported to all subscribed clients, not just
to those clients whose actions triggered the changes.

A fault event notification is generated when a fault condition (error or
warning) occurs.  A fault event may result in an alarm.  Examples of
fault events could be a communications alarm, environmental alarm,
equipment alarm, processing error alarm, quality of service alarm, or a
threshold crossing event.  See RFC3877 and RFC2819 for more information.
The fault notification should carry the following data: severity, event
source, probable cause, specific problem, additional information.

A state event indicates a change from one state to another, where a
state is a condition or stage in the existence of a managed entity.
State change events are seen in many specifications.  For Entity state
changes, see [Entity-State-MIB] for more information. The  notification
shall identify the object who's state changed and the new state.
Internal states of a node are important for supervision purposes and
also effect how a node can be configured. 

 Audit events provide event of very specific actions within a managed
device.  In isolation an audit events provides very limited data.  A
collection of audit information forms an audit trail.

A data dump event is an asynchronous event containing information about
a system, its configuration, state, etc.

A maintenance event signals the beginning, process or end of an action
either generated by a manual or automated  maintenance action. If the
maintenance event is a direct result of a configuration management
operation on this Netconf session then an rpc-reply notification should
be used. This event class is intended instead for reporting on scheduled
maintenance activities.
Expected data includes a description of the maintenance process, the
stage the process has reached, the manual action, automatic process that
triggered the notification. Examples include .automatic backup completed

A metrics event contains a metric or a collection of metrics.  This
includes performance metrics.

A heart beat event is sent periodically to enable testing that the
communications channel is still functional.  It behaves much like the
other event classes, with the exception that implementations may not
want to include an event log, if supported.  Although widely used
throughout the industry, no current corresponding work within the IETF.
However, other standards bodies such as the TeleManagement Forum have
similar definitions.

syslogTunnel event is when syslog content is sent, unmodified, within a
Netconf event Notification. See appendix X.X for more information.
"

2. Add text clarifying that session-based subscriptions are stored only
in the running configuration.

3.  To the callHome section, discuss target port and any implications on
transport and other things missing [I've asked Balazs if he could help
out with some text]

4. Clarify that the filters will be applied against the content of the
notifications (including the event class which is part of the header).

5. Add clarification that if a subscription request will fail if either
the filter is syntactically invalid or the named profile does not exist.
Note that while you could also say it fails if the filter points at
garbage, but someone consider it just pointing at something that does
not yet exist yet and consider that a filter. 

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
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: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2006 12:25:38 -0700

Sharon Chisholm wrote:

IMO, the text that Balazs proposed on 5/25/06 better.
Can you highlight the diffs; this doesn't look very changed.
It still contains all the same overlapping, vague classifications.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 15 Jun 2006 15:48:25 -0400

hi

This is a merge of the 5/25/06  text and the existing text. He had
discussion about expectations on the client side which people had
indicated was not something we could really talk about so that has not
been included. I also reworked things to be sentences instead of "foo:
stuff".

Remember it is expected that message can belong to more then one event
class. The event class is a predictor of content (and some behaviour).
There will always be overlap. Just like the real-world.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 3:26 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Additional proposed update to Netconf Notification Draft

Sharon Chisholm wrote:

Andy

> hi
> 
> Here are some additional proposed edits in addition to those that I 
> sent a while back

> The initial set of event classes is configuration, fault, state, 
> audit, data, maintenance, metrics, security, information, heartbeat 
> and syslogTunnel. See the IANA Considerations section for information 
> on defining new event classes.
> 

> merge, replace). As configuration notifications could potentially 
> carry huge amounts of data in order to properly support functions such

> as security audit logs, so it is expected that netconf clients will 

> changes, see [Entity-State-MIB] for more information. The  
> notification shall identify the object who's state changed and the new

> state. Internal states of a node are important for supervision 
> purposes and also effect how a node can be configured.
> 
> A data dump event is an asynchronous event containing information 
> about a system, its configuration, state, etc.
> 

> operation on this Netconf session then an rpc-reply notification 
> should be used. This event class is intended instead for reporting on 
> scheduled maintenance activities. Expected data includes a description

> of the maintenance process, the stage the process has reached, the 
> manual action, automatic process that triggered the notification. 
> Examples include .automatic backup completed
> 
> throughout the industry, no current corresponding work within the 
> IETF. However, other standards bodies such as the TeleManagement Forum

> have similar definitions.
> 
> syslogTunnel event is when syslog content is sent, unmodified, within 
> a Netconf event Notification. See appendix X.X for more information. "
> 
> 2. Add text clarifying that session-based subscriptions are stored 
> only in the running configuration.
> 
> 3.  To the callHome section, discuss target port and any implications 
> on transport and other things missing [I've asked Balazs if he could 
> help out with some text]
> 

> 5. Add clarification that if a subscription request will fail if 
> either the filter is syntactically invalid or the named profile does 
> not exist. Note that while you could also say it fails if the filter 
> points at garbage, but someone consider it just pointing at something 
> that does not yet exist yet and consider that a filter.
> 
> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
> 
> --
> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Jun 2006 13:20:06 -0700

> There will always be overlap. Just like the real-world.

There are 2 standards issues here:

1) The standard field in a netconf notification that will
    always be present, for the purpose of classifying the event type.

2) The set of actual values that this stable event type
    field is allowed to contain.

Unless it is very clear to implementors which standard classification
to use, there isn't much value in standardizing (2), since an NMS
will not be able to rely on consistent classification across agent vendors.

If (2) should be standardized, it should be a small, non-overlapping
list.  IMO, the purpose of a really generalized, overlapping classification
system is to provide agent vendors with a flexible mechanism
which they can call a standard, but without any interoperability requirements.

Why bother?  Either standardize with interoperable enumerations, or
leave it up to the vendors completely.

Andy