-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
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:
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
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 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/>