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 | | , | +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC | | , | | +-------------+ +-----------------------------+ | | | | +-------------+ +-------------------------------------------+ | 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. 2002-05-30T09:00:00 12.23:34 top/interfaces/interface[name='3']" 333 SSH NETCONF fred01 10.0.0.1 2002-05-30T08:00:00 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 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. 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. Chisholm, et al. Expires January 8, 2009 [Page 15] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 16] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 17] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 18] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 19] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 20] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 21] Internet-Draft NETCONF Notification Content July 2008 Chisholm, et al. Expires January 8, 2009 [Page 22] Internet-Draft NETCONF Notification Content July 2008 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, . [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]