Internet DRAFT - draft-chisholm-netconf-not-content
draft-chisholm-netconf-not-content
Network Working Group S. Chisholm
Internet-Draft Nortel
Intended status: Standards Track A. Clemm
Expires: January 8, 2009 Cisco
M. Betts
Nortel
July 7, 2008
NETCONF Notification Content
draft-chisholm-netconf-not-content-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Chisholm, et al. Expires January 8, 2009 [Page 1]
Internet-Draft NETCONF Notification Content July 2008
Abstract
The NETCONF Event Notifications standard specifies the mechanism by
which NETCONF clients can subscribe to and receive event
notifications. However, with the exception of a timestamp, no
standard Notification content was defined. This memo defines a set
of information that should be included in all NETCONF notifications,
information that should be included based on class of notification
and also defines a set of specific notifications to support specific
management functions, such as configuration.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Types of Notifications . . . . . . . . . . . . . . . . . . 4
1.4. Notification Content Definition and Inheritence . . . . . 5
1.4.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6
2. General Notification Content . . . . . . . . . . . . . . . . . 8
2.1. Event Identifier . . . . . . . . . . . . . . . . . . . . . 8
2.2. Event Class . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Resource Instance . . . . . . . . . . . . . . . . . . . . 8
3. Event Class Specific Notification Content and Definitions . . 9
3.1. Configuration Change Notifications . . . . . . . . . . . . 9
3.1.1. Heavy Configuration Change Notifications . . . . . . . 9
3.1.2. Light Configuration Change Notifications . . . . . . . 9
3.2. Inventory Change Notifications . . . . . . . . . . . . . . 9
3.3. Software Change Notification . . . . . . . . . . . . . . . 10
3.4. State Change Notifications . . . . . . . . . . . . . . . . 11
3.5. Audit Notifications . . . . . . . . . . . . . . . . . . . 11
3.6. Alarm Notifications . . . . . . . . . . . . . . . . . . . 12
3.7. Metrics Snapshot Notifications . . . . . . . . . . . . . . 13
3.8. Data Dump Notifications . . . . . . . . . . . . . . . . . 13
3.9. Threshold Crossing Notifications . . . . . . . . . . . . . 13
3.10. Heartbeat Notifications . . . . . . . . . . . . . . . . . 14
3.11. Informational Notifications . . . . . . . . . . . . . . . 14
4. XML Schema for Notification Content . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Chisholm, et al. Expires January 8, 2009 [Page 2]
Internet-Draft NETCONF Notification Content July 2008
1. Introduction
[NETCONF] can be conceptually partitioned into four layers:
Layer Example
+-------------+ +-------------------------------------------+
| Content | | Configuration data |
+-------------+ +-------------------------------------------+
| |
+-------------+ +-------------------------------------------+
| Operations | | <get-config>, <edit-config> <notification>|
+-------------+ +-------------------------------------------+
| | |
+-------------+ +-----------------------------+ |
| RPC | | <rpc>, <rpc-reply> | |
+-------------+ +-----------------------------+ |
| | |
+-------------+ +-------------------------------------------+
| Transport | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-------------------------------------------+
Figure 1
The NETCONF Event Notifications [NETCONF-NOTIFICATION] standard
specifies the mechanism by which NETCONF clients can subscribe to and
receive event notifications. However, with the exception of a
timestamp, no standard Notification content was defined. This memo
defines a set of information that should be included in all NETCONF
notifications, information that should be included based on class of
notification and also defines a set of specific notifications to
support specific management functions, such as configuration.
1.1. Definition of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Element: An [XML] Element.
Subscription: An agreement and method to receive event notifications
over a NETCONF session. A concept related to the delivery of
notifications (if there are any to send) involving destination and
selection of notifications. It is bound to the lifetime of a
session.
Chisholm, et al. Expires January 8, 2009 [Page 3]
Internet-Draft NETCONF Notification Content July 2008
Operation: This term is used to refer to NETCONF protocol operations
[NETCONF]. Within this document, operation refers to NETCONF
protocol operations defined in support of NETCONF notifications.
Event: An event is something that happens which may be of interest -
a configuration change, a fault, a change in status, crossing a
threshold, or an external input to the system, for example. Often
this results in an asynchronous message, sometimes referred to as
a notification or event notification, being sent to interested
parties to notify them that this event has occurred.
Event Class: A collection of events that serve a similar purpose and
that share parameters sent as part of the notification.
1.2. Motivation
The motivation for this work is to enable consistent and predictable
Notification content from multiple NETCONF server implementations.
1.3. Types of Notifications
For management to be effective and scalable, it cannot solely rely on
request-response based management patterns. Instead, it is crucial
that also event-driven management is supported. In general, event-
driven management obviates the need for polling cycles that are
wasteful in terms of the management bandwidth and CPU load they
consume - bearing in mind that many polling cycles do not result in
any new information. This makes management inherently more scalable
(more efficient use of resources) and also improves response time, as
a noteworthy event is picked up immediately, not after the next
polling cycle.
The enabler for event-driven management are event notifications.
Different classes of events can be distinguished. Each event Class
serves a different management purpose, hence applications should be
able to differentiate between classes of events they are interested
in from those that they are not. In addition, each event Class
contains a set of unique event information that is common to that
Class. The definition of Event Notification content specific to this
event category.
The following subsections define a list of management event classs
that can be distinguished and that NETCONF implementations may need
to support. Subsequently, Event Notification content associated with
these classes will be defined.
Chisholm, et al. Expires January 8, 2009 [Page 4]
Internet-Draft NETCONF Notification Content July 2008
o configuration change
o inventory change
o software change
o alarm
o state change
o audit
o metrics snapshot
o data dump
o threshold crossing
o informational
This list does not include accounting or debug event notifications.
These are beyond the scope of this document.
1.4. Notification Content Definition and Inheritence
The method defined in NETCONF Event Notifications
[NETCONF-NOTIFICATION] is that notifications are defined as
extensions to the NotificationContentType type. The definition of
NotificationContentType only contains an eventTime element. This
document defines an extension this type that defines additional
fields that must be included in all Notifications. It then defines a
series of event class specific type definitions that extend this
definition with additional content. It is expected that individual
Notification definitions will be defined as extensions of one of
these types, rather then directly as extensions of
NotificationContentType so they will pick up the appropriate content
and behaviour definitions.
Chisholm, et al. Expires January 8, 2009 [Page 5]
Internet-Draft NETCONF Notification Content July 2008
1.4.1. Example
The following figure illustrates inheriting information via type
extensions.
NotificationContentType (eventTime)
|
V
CommonEventContentNotificationType (eventIdentifier,
eventclass, resource)
|
V
ConfigurationChangeNotificationType (user, session, change)
Chisholm, et al. Expires January 8, 2009 [Page 6]
Internet-Draft NETCONF Notification Content July 2008
The following is an example Notification instance of a Notification
defined as a extension of ConfigurationChangeNotificationType.
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:netconf:notification:1.0
content.xsd">
<eventTime>2002-05-30T09:00:00</eventTime>
<configurationChangeLight
xmlns="urn:ietf:params:xml:ns:netmod:notifications">
<eventIdentifier xmlns="">12.23:34</eventIdentifier>
<eventclass xmlns=""><configurationChange
xmlns="urn:ietf:params:xml:ns:netmod:notifications"/>
</eventclass>
<resource xmlns="">top/interfaces/interface[name='3']"</resource>
<changeSource xmlns="">
<sessionId
xmlns="urn:ietf:params:xml:ns:netconf:state">333</sessionId>
<transport
xmlns="urn:ietf:params:xml:ns:netconf:state">SSH</transport>
<protocol
xmlns="urn:ietf:params:xml:ns:netconf:state"
>NETCONF</protocol>
<username
xmlns="urn:ietf:params:xml:ns:netconf:state"
>fred01</username>
<sourceHost
xmlns="urn:ietf:params:xml:ns:netconf:state"
>10.0.0.1</sourceHost>
<loginTime
xmlns="urn:ietf:params:xml:ns:netconf:state"
>2002-05-30T08:00:00</loginTime>
</changeSource>
</configurationChangeLight>
</notification>
Chisholm, et al. Expires January 8, 2009 [Page 7]
Internet-Draft NETCONF Notification Content July 2008
2. General Notification Content
This section outlines content for all notifications, regardless of
the event class.
2.1. Event Identifier
The event identifier uniquely identifies the event type that
generated this notification. It may be suitable to be included in
Notifications sent via other protocols, such as syslog, to help
determine that the event reported in both protocols is the same. It
may also be suitable for identifying events to help provide good data
to event correlation engines.
2.2. Event Class
This field identifies one of the event classes introduced above.
Event classess are 'big buckets' that event Notifications get mapped
to. They are useful in defining Notification subscription filters as
well as for being able to predict the content of a Notification.
Multiple Notification definitions can belong to a single Event class.
2.3. Resource Instance
The resource instance provides an XPath expression to identify the
managed resource experiencing the event.
Chisholm, et al. Expires January 8, 2009 [Page 8]
Internet-Draft NETCONF Notification Content July 2008
3. Event Class Specific Notification Content and Definitions
3.1. Configuration Change Notifications
Configuration change events indicate changes to the device
configuration. The mechanism through which the change was triggered
should be accounted for. Configuration change events come in two
different flavours. In one flavour, they indicate in detail what
changes actually occurred. In another flavour, they merely indicate
the fact that a change occurred, without indicating the precise
change.
NETCONF Event Notifications for configuration change events include
the following information in addition to common notification content:
o Config change mechanism used
o Config change originator
o Config change request ID
o Optionally, the new configuration
Whether it is possible to configure a NETCONF server to send
configuration change with or without the new configuration is outside
the scope of this document.
3.1.1. Heavy Configuration Change Notifications
This notification contains the complete XML content defining the
change in the configuration that has occurred. The body of the
messages takes the form of the NETCONF <edit-config> operation
required to make the change, even if the change originated in another
protocol, such as CLI.
3.1.2. Light Configuration Change Notifications
This notification indicates that a change has occurred and indicates
which resources have been changed, but not does not include the
complete list of changes that have occurred.
3.2. Inventory Change Notifications
This notification indicates that there has been a change of physical
inventory, such as a card being inserted or removed. Detecting the
insertion of new hardware might be used to trigger a configuration
activity by the NETCONF client.
Chisholm, et al. Expires January 8, 2009 [Page 9]
Internet-Draft NETCONF Notification Content July 2008
NETCONF Event Notifications for inventory change events include the
following information in addition to common notification content:
o Indication of Insertion or removal
o Type of hardware
o hardware instance identifier
It is expected that inventory change events may be augmented with
additional information in case of highly available and redundant
hardware. An inventory change event might result in an alarm if the
removed entity was not in maintenance state or not protected by
another piece of hardware.
3.3. Software Change Notification
This notification indicates that the software load or a file
containing a software image, or a supporting data file for an event-
driven piece of device software that alters the software's behaviour
running on all or part of the managed resource has changed. This
change includes actual software and any supporting data files that
are never subjected to user configuration (changes to the later would
be reported via configuration change events). [Editor's Note:
Different devices have different models for software upgrade. It
needs to be clarified if this is intended to alert the operator to
the new load being on the file system and ready to apply or that the
new load is already applied. Not all devices are upgraded using the
first method and certainly operators need to be alerted to the
second.]
Note that in some implementations, default values may change after a
software change, which potentially effects the configuration running
on the managed resource.
NETCONF Event Notifications for software change events include the
following information, in addition to common notification content:
o Name of Software
o Location of Software
o Optionally, the size of software files
Chisholm, et al. Expires January 8, 2009 [Page 10]
Internet-Draft NETCONF Notification Content July 2008
3.4. State Change Notifications
This notification indicates that a managed resource has changed
state.
Information contained in a state change notification includes to new
state.
State change example include changing from a state where it is able
to provide service to a state where is not, e.g because it is
shutting down or because of an error in a recent configuration
change. Unlike an alarm, a state change is not followed by a
"clear", but another state change. Another example of a state change
event is an event indicating a change in maintenance state, i.e. a
device that is taken out of service to perform maintenance
operations.
NETCONF Event Notifications for state change events include the
following information in addition to common notification content:
o State name
o New state
o Optionally, the previous state
The configuration of state change events - specifically, which state
change transitions of what object to monitor - is outside the scope
of this specification.
3.5. Audit Notifications
This notification transmits information such as users logging in and
out, sessions being created and destroyed. Taken collectively with
other notification instances of this class as well as others, audit
notifications form an audit trail.
Information contained in a audit notification includes what was done
and by whom.
Audit events can indicate (successful and unsuccessful) attempts to
tamper with the box - e.g. management requests that were issued,
through NETCONF or through another management interface. They are
the basis for audit trails that allow administrators to exactly track
management activities that have taken place, specifically the
configuration history of a box. Audit events should include an
indication of the mechanism that was used for tampering.
Chisholm, et al. Expires January 8, 2009 [Page 11]
Internet-Draft NETCONF Notification Content July 2008
NETCONF Event Notifications for audit events include the following
information in addition to common notification content:
o Management mechanism used
o Request originator
o Request ID
The event occurs when the request is made - the event time
accordingly refers to the time the request was received, not the time
it was generated or a response received. It is expected that audit
events will be extended with additional information to account for
different management mechanisms, for example the type of request
(e.g. set in the case of SNMP, edit-config or copy-config in case of
NETCONF).
3.6. Alarm Notifications
An alarm notification corresponds to the definition of alarms in
[RFC3877]. An alarm may result from an error in configuration or
some other event within the system.
Alarms are associated with some specific information, including the
severity of the alarm (indicating the scope of resources or services
affected and whether or not there is a workaround), a probable cause,
and a recommended action.
NETCONF Event Notifications for alarms include the following
information in addition to common notification content, roughly in
line with [RFC3877]:
o Alarm type: per X.733, one of communications alarm, quality of
service alarm, processing error alarm, equipment alarm
environmental alarm
o Perceived severity - one of indeterminate, critical, major, minor,
warning, cleared
o Optionally, correlated notifications. For example, alarms related
to removal of hardware should identify any corresponding inventory
change events.
o Optionally, a recommended action
A separate probable cause field is not required. Instead, the event
identifier is used to indicate the probable cause.
Chisholm, et al. Expires January 8, 2009 [Page 12]
Internet-Draft NETCONF Notification Content July 2008
In case of an environmental alarm, the affected entity should
identify the environmental sensor that triggered the alarm.
3.7. Metrics Snapshot Notifications
A metrics notification transmits a current snapshot of statistics
about a managed resource. These metrics may be sent periodically or
when specific events occur. Periodic snapshot events are sent in
periodic time intervals that could also be retrieved on request.
Instead of communicating snapshots periodically, conditional snapshot
events are emitted only when certain defined conditions are met (for
example, a value of a monitored object reaches a threshold) or when
other events occur (for example, a port failure).
Information contained in a metrics notification is a list of name
value pairs corresponding to individual metrics.
3.8. Data Dump Notifications
A Data Dump Notification transmits an opaque chunk of data. The data
is not meant to be parsed by the NETCONF client, but will get passed
onto specific applications that are able to understand its meaning.
The triggering of data dump Notifications is beyond the scope of this
document.
3.9. Threshold Crossing Notifications
Threshold Crossing Notification indicate that the value of a
parameter has crossed a certain threshold, which in many cases is
preconfigured. Unlike alarms, threshold notifications are not
associated with a severity.
A notification is sent when the value exceeds its threshold but
another is not sent until the original condition has been cleared, no
matter how long the condition persists.
The remission of a threshold crossing is generally reported through a
separate threshold crossing notification of an inverse, "hysteresis"
threshold, whose value is set slightly below that of the threshold
itself to avoid oscillating threshold crossing notifications.
NETCONF Event Notifications for Threshold Crossing Alerts (TCAs)
include the following information in addition to common notification
content:
o Monitored object
Chisholm, et al. Expires January 8, 2009 [Page 13]
Internet-Draft NETCONF Notification Content July 2008
o Threshold value - the value of the threshold or, in case of a
perceived importance of "cleared", the value of the hysteresis
threshold
o Crossing direction - one of rising, falling, clear or
intervalValueExceeded
The configuration of thresholds, and the assignment of perceived
importance, is outside the scope of this document.
The clearing of a previous threshold crossing is indicated through a
separate threshold crossing alert that crosses the threshold value in
the other direction (falling if the original TCA was rising above a
threshold, rising if the original TCA was raised falling below the
threshold). The threshold value in that case reflects a hysteresis
threshold slightly below (or above, in case the threshold crossing
alert is triggered in the falling direction) the original threshold
to avoid oscillating TCAs. [Editor's Note: while aligned to RMON, an
approach that does not require so much context should also be
considered]
3.10. Heartbeat Notifications
Heartbeat notifications are a special type of Notifications. They
have no additional payload and are not stored in Notification Logs.
They are used to support deployments with high-reliability
requirements. While NETCONF Notifications running over connected
sessions provides ensures a great deal of reliability at the TCP
layer, it may still be possible that there is an issue with the
NETCONF server that is preventing Notifications from being sent out.
Receiving a heartbeat means that the NETCONF server's Notification
sending mechanism is fully functioning. In addition, the heartbeat
feature allows to have long-lived Notification subscriptions that do
not time out during periods when no Notifications are being sent
without having to setting TCP timeouts to be infinitely long, which
could be considered an operational or security issue for non-
Notification sessions.
3.11. Informational Notifications
An informational notification contains information not captured by
another event class.
NETCONF Event Notifications for informational events do not include
no specific additional information. The information is covered by
common notification content, coupled with the ability to include
additional information that is event specific.
Chisholm, et al. Expires January 8, 2009 [Page 14]
Internet-Draft NETCONF Notification Content July 2008
4. XML Schema for Notification Content
This section outlines the XML Schema that defines both the complex
types to be used to derived implementation-specific Notification
definitions as well as specific standard Notification definitions.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netmod:notifications"
xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:monitor="urn:ietf:params:xml:ns:netconf:state"
targetNamespace="urn:ietf:params:xml:ns:netmod:notifications"
>
<xs:import namespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>
<xs:import namespace=
"urn:ietf:params:xml:ns:netconf:state"
schemaLocation="../../netconf_monitoring/monitoring.xsd"/>
<!-- Event Identifier -->
<xs:simpleType name="eventIdentifier">
<xs:annotation>
<xs:documentation>
Each event message has its own unique identifier. This
identifier is the same regardless of how this message is
communicated (protocol, verbosity, etc). If an event
such as a configuration change subsequently causes a
alarm event, the state change event and the alarm event
have separate identifiers.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!-- Name Value Pair -->
<xs:complexType name="NameValuePairType">
<xs:sequence>
<xs:element name="name"/>
<xs:element name="value"/>
<xs:element minOccurs="0" name="description"/>
</xs:sequence>
</xs:complexType>
Chisholm, et al. Expires January 8, 2009 [Page 15]
Internet-Draft NETCONF Notification Content July 2008
<!-- Event Class -->
<xs:complexType name="EventClassType">
<xs:sequence>
<xs:element ref="eventClassInstance"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
eventClassInstanceType: used as a base type for all
Event Classes
-->
<xs:complexType name="eventClassInstanceType"/>
<xs:element name="eventClassInstance"
type="eventClassInstanceType" abstract="true"/>
<!--
-->
<xs:complexType name="configurationChangeType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="configurationChange"
type="configurationChangeType"
substitutionGroup="eventClassInstance"/>
<!-- -->
<xs:complexType name="inventoryChangeType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="inventoryChange" type="inventoryChangeType"
substitutionGroup="eventClassInstance"/>
<!-- -->
<xs:complexType name="stateChangeType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="stateChange" type="stateChangeType"
substitutionGroup="eventClassInstance"/>
Chisholm, et al. Expires January 8, 2009 [Page 16]
Internet-Draft NETCONF Notification Content July 2008
<!--
-->
<xs:complexType name="alarmType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="alarm" type="alarmType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="auditType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="audit" type="auditType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="metricsType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="metrics" type="metricsType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="informationType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="informational" type="informationType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="dataDumpType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
Chisholm, et al. Expires January 8, 2009 [Page 17]
Internet-Draft NETCONF Notification Content July 2008
</xs:complexContent>
</xs:complexType>
<xs:element name="dataDump" type="dataDumpType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="thresholdCrossingType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="thresholdCrossing" type="thresholdCrossingType"
substitutionGroup="eventClassInstance"/>
<!--
-->
<xs:complexType name="heartbeatCrossingType">
<xs:complexContent>
<xs:extension base="eventClassInstanceType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="heartbeat" type="heartbeatCrossingType"
substitutionGroup="eventClassInstance"/>
<!-- Common Notification Content -->
<xs:complexType name="CommonEventContentNotificationType">
<xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType">
<xs:sequence>
<xs:element name="eventIdentifier"
type="eventIdentifier"/>
<xs:element name="eventClass"
type="EventClassType">
<xs:unique name="eventClass-value">
<xs:selector xpath="event"/>
<xs:field xpath="@eventClasses"/>
</xs:unique>
</xs:element>
<xs:element name="resource"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Chisholm, et al. Expires January 8, 2009 [Page 18]
Internet-Draft NETCONF Notification Content July 2008
<!-- Configuration Change -->
<xs:complexType name="ConfigurationChangeNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="changeSource"
type="monitor:ManagementSession"/>
<xs:element name="change" minOccurs="0" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="configurationChangeLight"
type="ConfigurationChangeNotificationType"
substitutionGroup="ncEvent:notificationContent">
</xs:element>
<!-- Inventory Change -->
<xs:simpleType name="InventoryActionType">
<xs:restriction base="xs:string">
<xs:enumeration value="insersion"/>
<xs:enumeration value="removal"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="InventoryChangeNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="action"
type="InventoryActionType"/>
<xs:element name="hardwareType" />
<xs:element name="hardwareInstanceIdentifier"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Software Change -->
<xs:complexType name="SoftwareChangeNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
Chisholm, et al. Expires January 8, 2009 [Page 19]
Internet-Draft NETCONF Notification Content July 2008
<xs:element name="softwareName"/>
<xs:element name="location" />
<xs:element name="size" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Software Change -->
<xs:complexType name="StateChangeNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="stateName"/>
<xs:element name="newStateValue" />
<xs:element name="oldStateValue" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Audit Message -->
<xs:complexType name="AuditNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="activitySource"
type="monitor:ManagementSession"/>
<xs:element name="occurrence"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Alarm Message -->
<xs:simpleType name="SeverityType">
<xs:restriction base="xs:string">
<xs:enumeration value="Cleared"/>
<xs:enumeration value="Critical"/>
<xs:enumeration value="Major"/>
<xs:enumeration value="Minor"/>
<xs:enumeration value="Warning"/>
<xs:enumeration value="Indeterminate"/>
Chisholm, et al. Expires January 8, 2009 [Page 20]
Internet-Draft NETCONF Notification Content July 2008
<xs:enumeration value="Info"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="EventTypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="Communications"/>
<xs:enumeration value="QualityOfService"/>
<xs:enumeration value="ProcessingError"/>
<xs:enumeration value="Equipment"/>
<xs:enumeration value="Environment"/>
<xs:enumeration value="IntegrityViolation"/>
<xs:enumeration value="OperationalViolation"/>
<xs:enumeration value="PhysicalViolation"/>
<xs:enumeration value="SecurityServiceOrMechanismViolation"/>
<xs:enumeration value="TimeDomainViolation"/>
<xs:enumeration value="Capacity"/>
<xs:enumeration value="Data"/>
<xs:enumeration value="ManagementCommunication"/>
<xs:enumeration value="Software"/>
<xs:enumeration value="SynchronizationTiming" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TrendIndicationType">
<xs:restriction base="xs:string">
<xs:enumeration value="LessSevere"/>
<xs:enumeration value="NoChange"/>
<xs:enumeration value="MoreSevere"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="AlarmNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="severity" type="SeverityType"/>
<xs:element name="eventType" type="EventTypeType"/>
<xs:element name="trendIndication"
type="TrendIndicationType"
minOccurs="0"/>
<xs:element name="correlatedAlarms" minOccurs="0"/>
<xs:element name="recommendedAction"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Chisholm, et al. Expires January 8, 2009 [Page 21]
Internet-Draft NETCONF Notification Content July 2008
<!-- Metrics Message -->
<xs:complexType name="MetricsNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="metrics">
<xs:complexType>
<xs:sequence>
<xs:element name="metric"
type="NameValuePairType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Informational Message -->
<xs:complexType name="InfomationalNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Data Dump Message -->
<xs:complexType name="DataDumpNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="opaqueData" type="xs:hexBinary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Threshold Crossing Message -->
<xs:simpleType name="CrossingType">
<xs:restriction base="xs:string">
<xs:enumeration value="rising"/>
Chisholm, et al. Expires January 8, 2009 [Page 22]
Internet-Draft NETCONF Notification Content July 2008
<xs:enumeration value="falling"/>
<xs:enumeration value="cleared"/>
<xs:enumeration value="intervalValueExceeded"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="ThresholdCrossingNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType">
<xs:sequence>
<xs:element name="monitoredObject"/>
<xs:element name="monitoredObjectValue"/>
<xs:element name="event" type="CrossingType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Heartbeat Message -->
<xs:complexType name="HeartbeatNotificationType">
<xs:complexContent>
<xs:extension base="CommonEventContentNotificationType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="heartbeatNotification"
type="HeartbeatNotificationType"
substitutionGroup="ncEvent:notificationContent">
</xs:element>
</xs:schema>
Chisholm, et al. Expires January 8, 2009 [Page 23]
Internet-Draft NETCONF Notification Content July 2008
5. Security Considerations
The security considerations from the base [NETCONF] document also
apply to the Notification capability.
The access control framework and the choice of transport will have a
major impact on the security of the solution.
Chisholm, et al. Expires January 8, 2009 [Page 24]
Internet-Draft NETCONF Notification Content July 2008
6. IANA Considerations
-- Editor note to IANA/RFC-Editor: we request that you make these
assignments, in which case it is to be documented as below
This document registers N URIs for the NETCONF XML namespace in the
IETF XML registry [RFC3688].
Following the format in RFC 3688, IANA has made the following
registration. Note that the capability urns as also compliant to
[NETCONF] section 10.3.
URI: urn:ietf:params:xml:ns:netmod:notifications
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
Chisholm, et al. Expires January 8, 2009 [Page 25]
Internet-Draft NETCONF Notification Content July 2008
7. Acknowledgements
Thanks to ...
Chisholm, et al. Expires January 8, 2009 [Page 26]
Internet-Draft NETCONF Notification Content July 2008
8. Normative References
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[NETCONF-NOTIFICATION]
Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", ID draft-ietf-netconf-notifications-14,
June 2007.
[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997.
[RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January
2004.
[RFC3877] Chisholm, S. and D. Romascanu, "The Alarm MIB", RFC 3877,
September 2004.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML Schema]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C http:/
/www.w3.org/TR/2004/REC-xmlschema-1-20041028/
structures.html, October 2004.
Chisholm, et al. Expires January 8, 2009 [Page 27]
Internet-Draft NETCONF Notification Content July 2008
Authors' Addresses
Sharon Chisholm
Nortel
3500 Carling Ave
Nepean, Ontario K2H 8E9
Canada
Email: schishol@nortel.com
Alex Clemm
Cisco
560 McCarthy
Milpitas, California 95035
USA
Email: alex@cisco.com
Malcolm Betts
Nortel
3500 Carling Ave
Nepean, Ontario K2H 8E9
Canada
Email: betts01@nortel.com
Chisholm, et al. Expires January 8, 2009 [Page 28]
Internet-Draft NETCONF Notification Content July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chisholm, et al. Expires January 8, 2009 [Page 29]
