[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]