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