Network Working Group S. Chisholm Internet-DraftK. Curran Expires: December 23, 2006Nortel Expires: March 18, 2007 H. Trevino CiscoJune 21,September 14, 2006 NETCONF Event Notificationsdraft-ietf-netconf-notification-02.txtdraft-ietf-netconf-notification-03.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 onDecember 23, 2006.March 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to transport protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.2 Event Notifications in NETCONF . . . . . . . . . . . . . . 5 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 51.5 Architecture2. Notification-Related Operations . . . . . . . . . . . . . . . 7 2.1 Subscribing to receive Event Notifications . . . . . . . . 72. Event-Related Operations .2.1.1 create-subscription . . . . . . . . . . . . . . . . . 7 2.2 Sending Event Notifications .8 2.1 Subscribing to receive Events. . . . . . . . . . . . . . 82.1.1 create-subscription2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 82.2 Sending Event Notifications2.3 Terminating the Subscription . . . . . . . . . . . . . . . 92.2.1 Event Notification . . . . . . . . . . . . .3. Supporting Concepts . . . . .9 2.3 Changing the Subscription. . . . . . . . . . . . . . . . 102.3.1 modify-subscription .3.1 Capabilities Exchange . . . . . . . . . . . . . . . .10 2.4 Terminating the Subscription. . 10 3.2 Event Streams . . . . . . . . . . . . .11 2.4.1 cancel-subscription. . . . . . . . . 10 3.2.1 Event Stream Definition . . . . . . . .12 3. Supporting Concepts. . . . . . . 11 3.2.2 Event Stream Content Format . . . . . . . . . . . . . 11 3.2.3 Default Event Stream .13 3.1 Capabilities Exchange. . . . . . . . . . . . . . . . 11 3.2.4 Event Stream Sources . .13 3.2 Subscriptions and Datastores. . . . . . . . . . . . . . .13 3.3 Querying Subscription Properties12 3.2.5 Event Stream Discovery . . . . . . . . . . . . .13 3.4 One-way Notification Messages. . . 12 3.2.6 Event Stream Subscription . . . . . . . . . . .18 3.5 Filter Dependencies. . . 17 3.3 Subscriptions and Datastores . . . . . . . . . . . . . . . 17 3.4 Querying Subscription Properties .19 3.5.1 Named Profiles. . . . . . . . . . . . 18 3.5 One-way Notification Messages . . . . . . . .19 3.5.2 Filtering. . . . . . 22 3.6 Filter Dependencies . . . . . . . . . . . . . . . .19 3.6 Event Classes. . . 22 3.6.1 Named Profiles . . . . . . . . . . . . . . . . . . .19 3.6.1 Initial Set of Event Classes. 23 3.6.2 Filtering . . . . . . . . . . . .20 3.7 Defining Event Notifications. . . . . . . . . . 23 3.7 Message Flow . . . . .21 3.8 Interleaving Messages. . . . . . . . . . . . . . . . . .2123 4. XML Schema for Event Notifications . . . . . . . . . . . . . .2325 5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 27 5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1 One-way Notification Messages in Beep . . . . . . . . 28 5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 29 6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 32 6.1Event Classes . . . . . . . . . . . . . . . . . . . . . . 32 6.2Subtree Filtering . . . . . . . . . . . . . . . . . . . . 326.36.2 XPATH filters . . . . . . . . . . . . . . . . . . . . . .3433 7.Additional Capabilities . . .Notification Replay Capability . . . . . . . . . . . . . . . .3635 7.1Call-Home Notifications . . . . . . . . . . . . .Overview . . . .36 7.1.1 Overview. . . . . . . . . . . . . . . . . . . . . 35 7.2 Dependencies . .36 7.1.2 Dependencies. . . . . . . . . . . . . . . . . . . . .37 7.1.335 7.3 Capability Identifier . . . . . . . . . . . . . . . .37 8. Security Considerations .. . 35 7.4 New Operations . . . . . . . . . . . . . . . .41 9. IANA Considerations. . . . . . 35 7.5 Modifications to Existing Operations . . . . . . . . . . . 36 7.5.1 create-subscription . . . .42 10. Acknowledgements. . . . . . . . . . . . . 36 7.5.2 Interactions with Other Capabilities . . . . . . . . .43 11. References36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . .43 Authors' Addresses. . . . . . . . . . . . . . . . . 38 10. References . . . . .44 A. Design Alternatives. . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses .45 A.1 Suspend And Resume. . . . . . . . . . . . . . . . . . . .45 A.2 Lifecycle. 39 Intellectual Property and Copyright Statements . . . . . . . .. . . . . . . . . . . . . . . 45 B. Event Notifications and Syslog . . . . . . . . . . . . . . . . 46 B.1 Leveraging Syslog Field Definitions . . . . . . . . . . . 46 B.1.1 Field Mapping . . . . . . . . . . . . . . . . . . . . 47 B.1.2 Severity Mapping . . . . . . . . . . . . . . . . . . . 48 B.2 Syslog within NETCONF Events . . . . . . . . . . . . . . . 48 B.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 48 B.2.2 Embedding syslog messages in a NETCONF Event . . . . . 48 B.2.3 Supported Forwarding Options . . . . . . . . . . . . . 49 C. Example Configuration Notifications . . . . . . . . . . . . . 51 C.1 Types of Configuration Events . . . . . . . . . . . . . . 51 C.2 Config Event Notification Structure . . . . . . . . . . . 52 C.3 Configuration Event Content . . . . . . . . . . . . . . . 54 C.3.1 Target Datastore . . . . . . . . . . . . . . . . . . . 54 C.3.2 User Info . . . . . . . . . . . . . . . . . . . . . . 54 C.3.3 Data Source . . . . . . . . . . . . . . . . . . . . . 54 C.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . 54 C.3.5 Context . . . . . . . . . . . . . . . . . . . . . . . 54 C.3.6 Entered Command . . . . . . . . . . . . . . . . . . . 55 C.3.7 New Config . . . . . . . . . . . . . . . . . . . . . . 55 C.3.8 Old Config . . . . . . . . . . . . . . . . . . . . . . 55 C.3.9 Non-netconf commands in configuration notifications . 55 D. IP Address Schema . . . . . . . . . . . . . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . 58 1. Introduction NETCONF [NETCONF-PROTO] can be conceptually partitioned into four layers: Layer Example +-------------+ +----------------------------------------+ | Content | | Configuration data | +-------------+ +----------------------------------------+ | | +-------------+ +-------------------------------------------+ | Operations | | <get-config>, <edit-config> <notification>| +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC | | <rpc>, <rpc-reply> | | +-------------+ +-----------------------------+ | | | | +-------------+ +------------------------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +------------------------------------------+ This document defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to transport protocols. Figure 1 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 RFC 2119 [3]. Element: An XML Element[XML]. Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has access to management instrumentation. This is also known as the NETCONF server. Managed Object: A collection of one of more Elements that define an abstract thing of interest. 1.2 Event Notifications in NETCONF 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 out to interested parties to notify them that this event has occurred. This memo defines a mechanism whereby the NETCONF client indicates interest in receiving event notifications from a NETCONF server by creating a subscription to receive event notifications. The NETCONF server replies to indicate whether the subscription request was successful and, if it was successful, begins sending the event notifications to the NETCONF client as the events occur within the system. These event notifications will continue to be sent until either the NETCONF session is terminated or an explicit command to cancel the subscription is sent. The event notification subscription allows a number of options to enable the NETCONF client to specify which events are of interest. These are specified when the subscription is created, but can be modified later using a modify subscription command. 1.3 Motivation The motivation for this work is to enable the sending of asynchronous messages that are consistent with the data model (content) and security model used within a Netconf implementation. 1.4 Requirements The requirements for this solution are as follows: o Initial release should ensure it supports notification in support of configuration operations o Data content must be use the same data model as used in configuration o solution should support structured hierarchical data o solution should be able to carry configuration fragments o solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) o solution should provide reliable delivery of notifications o solution should support preconfigured notification destinations o solution should support agent initiated connections o solution should provide a subscription mechanism o solution should support multiple subscriptions o solution should provide a filtering mechanism o solution should support notification names o solution should support notification timestamps o solution should support notification classes o solution should support notification info o solution should provide the ability to specify the content of notifications to ensure predictability o solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism o solution should allow notifications to refer to prior configuration change RPCs o solution should not bind subscriptions to a connection o channels for configuration change notifications should share fate with a session that includes a configuration channel o solution should support replay of locally logged notifications o solution should support message chunking capability in cases channels carry mixed RPCs o solution should scale to 30.000-100.000 nodes which may emit notifications o solution should scale to order 30.000-100.000 nodes to send notifications [BL] See also the external website tracking requirements at http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications 1.5 Architecture [Editor's Note: add pointers to the various architecture discussions in the document and identify what people view to be gaps in architecture discussion. The following may not be what people were looking for in this section, but should at least give people something to discuss] The following figure illustrates that the netconf implementation leverages protocol-neutral event management software within the box rather then re-invent everything in Netconf specific methods. The netconf client understands which notifications are of interest to it and creates a subscription that meets its requirements. The network elements accepts the subscription requests and creates a temporary subscription to meet those needs. ---------------------------------------------- | Network Element | | ------------ | | | Alarm | | | | Management | -------------- | -------------- | ------------ |--->|Netconf Stack |<---------->| Netconf | | | | | | | | | | | | -------------- | --->| Client | | V | | | -------------- | ------------ | | | | | Event |--->| ------------------ | | | | Management | | |Other Protocols | | | | ------------ |--->| | | | | ------------------ | | |--------------------------------------------- | | ---------------------------------------------- | | Network Element | | | ------------ | | | | Alarm | | | | | Management | -------------- | | | ------------ |--->|Netconf Stack |<-------| | | | | | | | | | -------------- | | V | | | ------------ | | | | Event |--->| ------------------ | | | Management | | |Other Protocols | | | ------------ |--->| | | | ------------------ | |-------------------------------------------- 2. Event-Related Operations 2.1 Subscribing to receive Events The event notification subscription is initiated by the NETCONF client and responded to by the NETCONF server. When the event notification subscription is created, the events of interest are specified. It is possible to create more than one event notification subscription on a single underlying connection. Each event notification subscription therefore has its own unique identifier. Content for an event notification subscription can be selected by specifying which event classes are of interest and /or by applying user-specified filters. 2.1.1 create-subscription <create-subscription> Description: This operation initiates an event notification subscription which will send asynchronous event notifications to the initiator of the command until the <cancel-subscription > command is sent. Parameters: Event Classes: An optional parameter that indicates which event classes are of interest. If not present, events of all classes will be sent. Filter: An optional parameter that indicates which subset of all possible events are of interest. The format of this parameter is the same as that of the filter parameter in the NETCONF protocol operations. If not present, all events not precluded by other parameters will be sent. These filter parameters can only be modified using the modify-subscription command. Named Profile An optional parameter that points to a separately defined filter profile. The contents of the profile are specified in the provided XML Schema. If not present, no additional filtering will be applied. Note that changes to the profile after the subscription has been created will have no effect unless a modify subscription command is issued. Positive Response: If the NETCONF server can satisfy the request, the server sends an <rpc-reply> element containing a <data> element containing the subscription ID. Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason. Subscription requests will fail if a filter with invalid syntax is provided or if the name of a non-existent profile is provided. 2.2 Sending Event Notifications Once the subscription has been set up, the NETCONF server sends the event notifications asynchronously along the connection. Notifications are tagged with event classes, subscription ID, sequence number, and date and time. 2.2.1 Event Notification <notification> Description: An event notification is sent to the initiator of an <create- subscription> command asynchronously when an event of interest (i.e. meeting the specified filtering criteria) to them has occurred. An event notification is a complete XML document. Parameters: Event Classes: The event class or classes associated with this event notification Subscription Id: A unique identifier for this event subscription Sequence Number: A sequentially increasing number to uniquely identify event notifications for this subscription. It starts at 0, always increases by just one and rolls back to 0 after its maximum value is reached. Date and Time: The date and time that the event notification was sent by the NETCONF server. Data: Contains event class and notification-specific tagged content. Positive Response: No response. Negative Response: No response. 2.3 Changing the Subscription After an event notification subscription has been established, the NETCONF client can initiate a request to change properties of the event notification subscription. This prevents loss of event notifications that might otherwise occur during a cancelling and recreation of the event notification subscription. This operation is responded to by the NETCONF server 2.3.1 modify-subscription <modify-subscription> Description: Change properties of the event notification subscription. Parameters: Subscription Id: A unique identifier for this event subscription. Event Classes: An optional parameter that indicates which Event Classes are of interest. If not present, events of all classes will be sent. Filter: An optional parameter that indicates which subset of all possible events that are of interest. The format is the same filter used for other NETCONF commands. If not present, all events not precluded by other parameters will be sent. These filter parameters can only be modified using the modify- subscription command. Named Profile: An optional parameter that points to separately defined filter profile. The contents of the profile are specified in provided XML Schema. If not present, no additional filtering will be applied. Note that changes to the profile after the subscription has been created will have no effect unless a modify subscription command is issued. Positive Response: If the NETCONF server was able to satisfy the request, an <rpc- reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason. Subscription requests will fail if a filter with invalid syntax is provided or if the name of a non-existent profile is provided. 2.4 Terminating the Subscription Closing of the event notification subscription is initiated by the NETCONF client. The specific subscription to be closed is specified using a subscription ID. The NETCONF server responds. Note that the NETCONF session may also be torn down for other reasons and this will also result in the subscription being cancelled, but is not subjected to the behaviour of this operation. 2.4.1 cancel-subscription <cancel-subscription> Description: Stop and delete the event notification subscription. Parameters: Subscription Id: A unique identifier for this event notification subscription. Positive Response: If the NETCONF server was able to satisfy the request, an <rpc- reply> is sent that includes an <ok> element. Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason. 3. Supporting Concepts 3.1 Capabilities Exchange The ability to process and send event notifications is advertised during the capability exchange between the NETCONF client and server. "urn:ietf:params:xml:ns:netconf:notification:1.0" For Example <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:xml:ns:netconf:base:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:startup:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:notification:1.0 </capability> </capabilities> <session-id>4</session-id> </hello> 3.2 Subscriptions and Datastores Subscriptions are like Netconf sessions in that they don't exist Netconf datastores. The two exceptions to this are named profiles and the optional call-home notification feature. 3.3 Querying Subscription Properties The following Schema can be used to retrieve information about active event notification subscriptions <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0" targetNamespace= "urn:ietf:params:xml:ns:netconf:subscription:1.0" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ncEvent= "urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"> <xs:annotation> <xs:documentation xml:lang="en"> Schema for reporting on Event Subscriptions </xs:documentation> <xs:appinfo> <nm:identity xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"> <nm:Name>NetconfNotificationSchema</nm:Name> <nm:LastUpdated>2006-04-30T09:30:47-05:00 </nm:LastUpdated> <nm:Organization>IETF</nm:Organization> <nm:Description> A schema that can be used to learn about current NetConf Event subscriptions and creating named profiles </nm:Description> </nm:identity> </xs:appinfo> </xs:annotation> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:netconf:notifications:1.0" schemaLocation="draft-ietf-netconf-notification-01.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="draft-ietf-netconf-prot-12.xsd"/> <xs:element name="netconfSubscription"> <xs:annotation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/></nm:maxAccess> </xs:appinfo> </xs:annotation> <xs:complexType> <xs:sequence maxOccurs="unbounded"> <xs:element name="session-id" type="netconf:SessionId" > <xs:annotation> <xs:documentation xml:lang="en"> The session id associated with this subscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="subscriptionID" type="ncEvent:SubscriptionID" > <xs:annotation> <xs:documentation xml:lang="en"> The subscription id associated with this subscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="eventClasses"> <xs:annotation> <xs:documentation xml:lang="en"> The event classes associated with this subscription. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element ref="ncEvent:EventClass"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The filters associated with this subscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="namedProfile" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The named profile associated with this subscription. Note that the contents of the named profile may have changed since it was last applied. </xs:documentation> </xs:annotation> <xs:keyref name="namedProfileKeyRef" refer="nsub:namedProfileKey"> <xs:selector xpath=".//namedProfile"/> <xs:field xpath="namedProfile"/> </xs:keyref> </xs:element> <xs:element name="lastModified" type="xs:dateTime" > <xs:annotation> <xs:documentation xml:lang="en"> The last time this subscription was modified. If it has not been modified since creation, this is the time of subscription creation. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="messagesSent" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> A count of event notifications sent along this connection since the subscription was created. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="lastSequenceNumber" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The sequence number of the last event notification sent to this subscription </xs:documentation> </xs:annotation> </xs:element> <xs:element name="key"> <xs:key name="uniqueSubscription"> <xs:selector xpath=".//subscription"/> <xs:field xpath="session-id"/> <xs:field xpath="subscriptionID"/> </xs:key> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="netconfSubscriptions"> <xs:complexType> <xs:sequence> <xs:element ref="nsub:netconfSubscription" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="namedProfile"> <xs:annotation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/> <write/> <create/> <delete/> </nm:maxAccess> </xs:appinfo> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="name"/> <xs:element name="eventClasses"> <xs:annotation> <xs:documentation xml:lang="en"> The event classes associated with this named Profile. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element ref="ncEvent:EventClass"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The filters associated with this named Profile. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="lastModified" type="xs:dateTime"> <xs:annotation> <xs:documentation> The timestamp of the last modification to this named Profile. Note that modification of the profile does not cause an immediate update to all applicable subscription. Therefore, this time should be compared with the last modified time associated with the subscription. If this time is earlier, then the subscription is using the exact set of parameters associated with this named profile. If this time is later, then the subscription is using an earlier version of this named profile and the exact parameters may not match. </xs:documentation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/> </nm:maxAccess> </xs:appinfo> </xs:annotation> </xs:element> <xs:element name="key"> <xs:key name="namedProfileKey"> <xs:selector xpath="*/name" /> <xs:field xpath="name" /> </xs:key> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="namedProfiles"> <xs:complexType> <xs:sequence> <xs:element ref="nsub:namedProfile" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 3.4 One-way Notification Messages In order to support the concept that each individual event notification is a well-defined XML-document that can be processed without waiting for all events to come in, it makes sense to define events, not as an endless reply to a subscription command, but as independent messages that originate from the NETCONF server. In order to support this model, this memo introduces the concept of notifications, which are one-way messages. A one-way message is similar to the two-way RPC message, except that no response is expected to the command. In the case of event notification, this message will originate from the NETCONF server, and not the NETCONF client. 3.5 Filter Dependencies Note that when multiple filters are specified (Event Class, in-line Filter, Named Profiles), they are applied collectively, so event notifications needs to pass all specified filters in order to be sent to the subscriber. If a filter is specified to look for data of a particular value, and the data item is not present within a particular event notification for its value to be checked against, it will be filtered out. For example, if one were to check for 'severity=critical' in a configuration event notification where this field was not supported, then the notification would be filtered out. 3.5.1 Named Profiles A named profile is a filter that is created ahead of time and applied at the time an event notification subscription is created or modified. Note that changes to the profile after the subscription has been created will have no effect unless a modify subscription command is issued. Since named profiles exist outside of the subscription, they persist after the subscription has been cancelled. 3.5.2 Filtering Just-in-time filtering is explicitly stated when the event notification subscription is created. These filters can only be changed using the modify subscription command. This is specified via the Filter parameter. Filters only exist as parameters to the subscription. 3.6 Event Classes Events can be classified into one more event classes. Each event class identifies a set of event notifications which share similar content are generated from similar events The initial set of event classes is configuration, fault, state, audit, data, maintenance, metrics, security, information, heartbeat and syslogTunnel. See the IANA Considerations section for information on defining new event classes. All events shall carry the following data: list of event class, timestamp and sequence number of the notification. They may also carry additional data. ___________________________________________________________________ || Notification Header || Data | ||__________________________________________________________||______| || subscriptionId| eventClasses| sequenceNumber| dateAndTime|| | ||_______________|_____________|_______________|____________||______| 3.6.1 Initial Set of Event Classes A configuration event, alternatively known as an inventory event, is used to indicate that hardware, software, or a service has been added, changed or removed. In keeping aligned with NETCONF protocol operations, configuration events may included copy configuration event, delete configuration event, or the edit configuration event (create, delete, merge, replace). As configuration notifications could potentially carry huge amounts of data in order to properly support functions such as security audit logs, so it is expected that netconf clients will engineer their subscriptions to meet their needs and to not overwhelm their capacity to process and store event notifications. Examples include hardware board removed, software module loaded or DNS server reconfigured. Changes are reported to all subscribed clients, not just to those clients whose actions triggered the changes. A fault event notification is generated when a fault condition (error or warning) occurs. A fault event may result in an alarm. Examples of fault events could be a communications alarm, environmental alarm, equipment alarm, processing error alarm, quality of service alarm, or a threshold crossing event. See RFC3877 and RFC2819 for more information. The fault notification should carry the following data: severity, event source, probable cause, specific problem, additional information. A state event indicates a change from one state to another, where a state is a condition or stage in the existence of a managed entity. State change events are seen in many specifications. For Entity state changes, see [Entity-State-MIB] for more information. The notification shall identify the object who's state changed and the new state. Internal states of a node are important for supervision purposes and also effect how a node can be configured. Audit events provide event of very specific actions within a managed device. In isolation an audit events provides very limited data. A collection of audit information forms an audit trail. A data dump event is an asynchronous event containing information about a system, its configuration, state, etc. A maintenance event signals the beginning, process or end of an action either generated by a manual or automated maintenance action. If the maintenance event is a direct result of a configuration management operation on this Netconf session then an rpc-reply notification should be used. This event class is intended instead for reporting on scheduled maintenance activities. Expected data includes a description of the maintenance process, the stage the process has reached, the manual action, automatic process that triggered the notification. Examples include automatic backup completed. A metrics event contains a metric or a collection of metrics. This includes performance metrics. A heart beat event is sent periodically to enable testing that the communications channel is still functional. It behaves much like the other event classes, with the exception that implementations may not want to include an event log, if supported. Although widely used throughout the industry, no current corresponding work within the IETF. However, other standards bodies such as the TeleManagement Forum have similar definitions. An Information event is something that happens of interest which is within the expected operational behaviour and not otherwise covered by another class. syslogTunnel event is when syslog content is sent, unmodified, within a Netconf event Notification. See appendix X.X for more information.. 3.7 Defining Event Notifications Event Notifications are defined ahead of time by defining an XML element and assigning it to particular event classes. This will be done using an "eventClasses" attribute. 3.8 Interleaving Messages While each NETCONF message must be a complete XML document, the design of the event system allows for the interleaving of complete asynchronous event notifications with complete synchronous messages. It is possible to still send command-response type messages such as <modify-subscription> while events are being generated. The only restriction is that each message must be complete The following sequence diagram demonstrates an example NETCONF session where after basic session establishment and capability exchange, NETCONF client (C), subscribes to receive event notifications. The NETCONF server (S), starts sending event notifications as events of interest happen within the system. The NETCONF client decides to change the characteristics of their event subscription by sending a <modify-subscription> command. Before the NETCONF server, receives this command, another event is generated and the NETCONF server starts to send the event notification. The NETCONF server finishes sending this event notification before processing the <modify-subscription> command and sending the reply. C S40 1. Introduction NETCONF [NETCONF-PROTO] can be conceptually partitioned into four layers: Layer Example +-------------+ +----------------------------------------+ | Content | | Configuration data |capability exchange+-------------+ +----------------------------------------+ ||-------------------------->| |<------------------------->|| +-------------+ +-------------------------------------------+ | Operations |<create-subscription>||-------------------------->| |<--------------------------|<get-config>, <edit-config> <notification>| +-------------+ +-------------------------------------------+ | | |<notification>+-------------+ +-----------------------------+ ||<--------------------------|| RPC | |<notification><rpc>, <rpc-reply> ||<--------------------------|| +-------------+ +-----------------------------+ | |<modify-subscription>||-------------------------->| (buffered)|<notification>+-------------+ +------------------------------------------+ ||<--------------------------|Transport |<rpc-reply>||<--------------------------| 4. XML SchemaBEEP, SSH, SSL, console | | Protocol | | | +-------------+ +------------------------------------------+ This document defines a framework forEvent Notifications <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"> <!-- import standardsending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to transport protocols. Figure 1 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 RFC 2119 [3]. Element: An XMLdefinitions --> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation>Element[XML]. Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has access to management instrumentation. Thisimport accessesis also known as the NETCONF server. Managed Object: A collection of one of more Elements that define an abstract thing of interest. Subscription: A concept related to the delivery of notifications (if any to send) involving destination and selection of notifications. It is bound to the lifetime of a session. 1.2 Event Notifications in NETCONF 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 thexml: attribute groupssystem, forthe xml:langexample. Often this results in an asynchronous message, sometimes referred to asdeclared on the error-message element. </xs:documentation> </xs:annotation> </xs:import> <!-- import base netconf definitions --> <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" /> <!-- ************** Type definitions ***********************--> <xs:simpleType name="SubscriptionID"> <xs:annotation> <xs:documentation> The unique identifier fora notification or event notification, being sent out to interested parties to notify them that thisparticular subscription withinevent has occurred. This memo defines a mechanism whereby thesession. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="SequenceNumber"> <xs:annotation> <xs:documentation> A monotonically increasing integer. Starts at 0. Always increasesNETCONF client indicates interest in receiving event notifications from a NETCONF server byjust one. Roll back to 0 after maximum value is reached. </xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"/> </xs:simpleType> <xs:complexType name="EventClassType"/> <xs:element name="EventClass" type="EventClassType" abstract="true"/> <xs:element name="fault" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="information" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="state" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="configuration" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="data" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="maintenance" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="metrics" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="security" type="EventClassType" substitutionGroup="EventClass"/> <xs:element name="heartbeat" type="EventClassType" substitutionGroup="EventClass"/> <xs:complexType name="EventClasses"> <xs:sequence maxOccurs="unbounded"> <xs:element ref="EventClasses" /> </xs:sequence> </xs:complexType> <!-- ************** Symmetrical Operations ********************--> <!-- <create-subscription> operation --> <xs:complexType name="createSubscriptionType"> <xs:complexContent> <xs:extension base="netconf:rpcOperationType"> <xs:sequence> <xs:element name="event-classes" minOccurs="0"> <xs:complexType> <xs:complexContent> <xs:extension base="EventClasses"/> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"/> <xs:element name="named-profile" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="create-subscription" type="createSubscriptionType" substitutionGroup="netconf:rpcOperation"/> <!-- <modify-subscription> operation --> <xs:complexType name="modifySubscriptionType"> <xs:complexContent> <xs:extension base="netconf:rpcOperationType"> <xs:sequence> <xs:element name="subscription-id" type="SubscriptionID" /> <xs:element name="event-classes" minOccurs="0"> <xs:complexType> <xs:complexContent> <xs:extension base="EventClasses"/> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"/> <xs:element name="named-profile" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="modify-subscription" type="modifySubscriptionType" substitutionGroup="netconf:rpcOperation"/> <!-- <cancel-subscription> operation --> <xs:complexType name="cancelSubscriptionType"> <xs:complexContent> <xs:extension base="netconf:rpcOperationType"> <xs:sequence> <xs:element name="subscription-id" type="SubscriptionID" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="cancel-subscription" type="cancelSubscriptionType" substitutionGroup="netconf:rpcOperation"/> <!-- ************** One-way Operations ******************--> <!-- <Event> operation --> <xs:complexType name="NotificationType"> <xs:sequence> <xs:element name="subscriptionId" type="SubscriptionID" /> <xs:element name="eventClasses" type="EventClasses" /> <xs:element name="sequenceNumber" type="SequenceNumber" /> <xs:element name="dateAndTime" type="xs:dateTime"> <xs:annotation> <xs:documentation>creating a subscription to receive event notifications. Thedate and time thatNETCONF server replies to indicate whether thenotificationsubscription request wassent bysuccessful and, if it was successful, begins sending thenetconf server. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:element name="notification" type="NotificationType"/> </xs:schema> 5. Mappingevent notifications toTransport Protocols Currently,the NETCONFfamilyclient as the events occur within the system. These event notifications will continue to be sent until either the NETCONF session is terminated or some event, outside the scope ofspecificationthis specification, causes the subscription to terminate. The event notification subscription allowsfor running NETCONF overa number oftransport protocols, some ofoptions to enable the NETCONF client to specify whichsupport multiple configurations. Someevents are ofthese options willinterest. These are specified when the subscription is created. An agent is not required to process RPC requests until the notification stream is done. A capability may bebetter suiteddefined to announce that a server is able to process RPCs while a notification stream is active on a session. 1.3 Motivation The motivation forsupporting event notifications then others. 5.1 SSH Session establishment and two-waythis work is to enable the sending of asynchronous messages that arebased onconsistent with theNETCONF over SSH transport mapping [NETCONF-SSH] One-way event messagesdata model (content) and security model used within a Netconf implementation. 1.4 Requirements The requirements for this solution aresupportedas follows:Once the session has been established and capabilities have been exchanged, the server may send complete XML documents to the NETCONF client containingo Initial release should ensure it supports notificationelements. No response is expected fromin support of configuration operations o Data content must not preclude theNETCONF client. Asuse of theother examplessame data model as used in[NETCONF-SSH] illustrate,configuration o solution should support aspecial character sequence, MUST be sent by both the clientreasonable message size limit (syslog andthe server after each XML documentSNMP are rather constrained in terms of message sizes) o solution should provide reliable delivery of notifications o solution should support agent initiated connections o solution should provide a subscription mechanism (An agent does not send notifications before asked to do so and theNETCONF exchange. This character sequence cannot legally appearmanager initiates the flow of notifications) o solution should provide a filtering mechanism o solution should send sufficient information inan XML document,a notification so that it can beunambiguously used to identify the end of the current document in the event notification of an XML syntax or parsing error, allowing resynchronizationanalyzed independent of theNETCONF exchange. The NETCONF over SSH sessiontransport mechanism (data content fully describes a notification; protocol information is not needed toreceive an event notification might look like the following. Note the event notification contents (delimited by <data> </data> tags) areunderstand a notification) o solution should notdefined in this document and are provided herein simplybind subscriptions to a connection o channels forillustration purposes: <?xml version="1.0" encoding="UTF-8"?> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <subscription-id>123456</subscription-id> <eventClasses><configuration/><audit/></eventClasses> <sequenceNumber>2</sequenceNumber> <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> <data> <user>Fred Flinstone</user> <operation> <edit-config> <target> <running/> </target> <config> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>1500</mtu> </interface> </top> </config> </edit-config> </operation> </data> </notification> ]]> ]]> 5.2 BEEP Session establishmentconfiguration change notifications should share fate with a session that includes a configuration channel o solution should support replay of locally logged notifications 2. Notification-Related Operations 2.1 Subscribing to receive Event Notifications The event notification subscription is initiated by the NETCONF client andtwo-way messages are based onresponded to by the NETCONFover BEEP transport mapping NETCONF-BEEP 5.2.1 One-way Notification Messages in Beep One-wayserver. When the event notificationmessagessubscription is created, the events of interest are specified. Content for an event notification subscription can besupported eitherselected bymappingapplying user-specified filters. 2.1.1 create-subscription <create-subscription> Description: This operation initiates an event notification subscription which will send asynchronous event notifications to theexisting one-to-many BEEP constructinitiator of the command until the NETCONF session terminates orby creating a new one-to- none construct. This area is for future study. 5.2.1.1 One-way messages viasome event, outside theOne-to-many Construct Messages in one-to-many exchanges: "rpc", "notification", "rpc-reply" Messagesscope of this specification, causes the subscription to terminate. Parameters: Stream: An optional parameter that indicates which stream(s) of events are of interest. If not present, then events inpositive replies: "rpc-reply", "rpc-one-way" 5.2.1.2 One-way notification messages viatheOne-to-none Construct Notedefault NETCONF stream will be sent. Filter: An optional parameter that indicates which subset of all possible events are of interest. The format of thisconstruct would need to be added to an extension or update to 'The Blocks Extensible Exchange Protocol Core' RFC 3080. MSG/NoANS:parameter is theclient sends a "MSG" message,same as that of theserver, sends no reply. In one-to-none exchanges, no replyfilter parameter in the NETCONF protocol operations. If not present, all events not precluded by other parameters will be sent. Named Profile An optional parameter that points to a separately defined filter profile. The contents of the"MSG" message is expected. 5.3 SOAP Session management and message exchangeprofile arebased onspecified in theNETCONF over SOAP transport mapping NETCONF-SOAPprovided XML Schema. If not present, no additional filtering will be applied. Note that changes to theuse of "persistent connections" "chunked transfer- coding" when using HTTP becomes even more important inprofile after thesupporting of event notifications 5.3.1 A NETCONF over Soap over HTTP Example C: POST /netconf HTTP/1.1 C: Host: netconfdevice C: Content-Type: text/xml; charset=utf-8 C: Accept: application/soap+xml, text/* C: Cache-Control: no-cache C: Pragma: no-cache C: Content-Length: 465 C: C: <?xml version="1.0" encoding="UTF-8"?> C: <soapenv:Envelope C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> C: <soapenv:Body> C: <rpc message-id="101" C: xmlns= "xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> C: <create-subscription> C: </create-subscription> C: </rpc> C: </soapenv:Body> C: </soapenv:Envelope> The response: S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <rpc-reply message-id="101" S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> S: <data> S: <top xmlns= "http://example.com/schema/1.2/notification"> S: <subscriptionId>123456</subscriptionId> S: </top> S: </data> S: </rpc-reply> S: </soapenv:Body> S: </soapenv:Envelope> And then some time later S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> S: <subscriptionID>123456</subscriptionID> S: <eventClasses><configuration/><audit/></eventClasses> S: <sequenceNumber>2</sequenceNumber> S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> S: <data> S: <user>Fred Flinstone</user> S: <operation> S: <edit-config> S: <target> S: <running/> S: </target> S: <config> S: <top xmlns="http://example.com/schema/1.2/config"> S: <interface> S: <name>Ethernet0/0</name> S: <mtu>1500</mtu> S: </interface> S: </top> S: </config> S: </edit-config> S: </operation> S: </data> S: </notification> S: </soapenv:Body> S: </soapenv:Envelope> 6. Filtering examples The following section provides examples to illustratesubscription has been created will have no effect. Positive Response: If thevarious methods of filtering content onNETCONF server can satisfy the request, the server sends anevent notification subscription. 6.1<rpc-reply> element containing a <data> element containing the subscription ID. Negative Response: An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason. Subscription requests will fail if a filter with invalid syntax is provided or if the name of a non-existent profile or stream is provided. 2.2 Sending EventClasses The following example illustrates selecting allNotifications Once the subscription has been set up, the NETCONF server sends the event notificationsfor EventClasses fault, state or config <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <eventClasses> <fault/> <state/> <config/> </eventClasses> </create-subscription> </rpc> 6.2 Subtree Filtering XML subtree filteringasynchronously along the connection. 2.2.1 Event Notification <notification> Description: An event notification isnot well suited for creating elaborate filter definitions given that it only supports equality comparisons (e.g. insent to the initiator of an <create- subscription> command asynchronously when an eventsubtree give me allof interest (i.e. meeting the specified filtering criteria) to them has occurred. An eventnotifications which have severity=critical or severity=major or severity=minor). Nevertheless, it may be usednotification is a complete XML document. Parameters: Subscription Id: A unique identifier fordefining simplethis event subscription Data: Contains notification-specific tagged content. Positive Response: No response. Negative Response: No response. 2.3 Terminating the Subscription Closing of the event notificationforwarding filters as shown below. The following example illustrates selecting fault EventClass which have severitiessubscription is done by terminating the Netconf session ( <kill-session> )or via some action outside the scope ofcritical, major, or minor.this specification. 3. Supporting Concepts 3.1 Capabilities Exchange Thefiltering criteria evaluationability to process and send event notifications isas follows: ((fault) & ((severity=critical) | (severity=major) | (severity = minor))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <eventClasses> <fault/> </eventClasses> <netconf:filter type="subtree"> <neb xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <event> <severity>critical</severity> </event> <event> <severity>major</severity> </event> <event> <severity>minor</severity> </event> </neb> </netconf:filter> </create-subscription> </rpc> The following example illustrates selecting fault, state, config EventClasses which have severities of critical, major, or minoradvertised during the capability exchange between the NETCONF client andcome from card Ethernet0. The filtering criteria evaluationserver. "urn:ietf:params:xml:ns:netconf:notification:1.0" For Example <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:xml:ns:netconf:base:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:startup:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:notification:1.0 </capability> </capabilities> <session-id>4</session-id> </hello> 3.2 Event Streams An event stream is defined herein asfollows: ((fault | state | config) & ((fault & severity=critical) | (fault & severity=major) | (fault & severity = minor) | (card=Ethernet0))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <eventClasses> <fault/> <state/> <config/> </eventClasses> <netconf:filter type="subtree"> <neb xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <event> <eventClasses>fault</eventClasses> <severity>critical</severity> </event> <event> <eventClasses>fault</eventClasses> <severity>major</severity> </event> <event> <eventClasses>fault</eventClasses> <severity>minor</severity> </event> <event> <card>Ethernet0</card> </event> </neb> </netconf:filter> </create-subscription> </rpc> 6.3 XPATH filters The following example illustrates selecting fault EventClass which have severitiesa set ofcritical, major, or minor. The filtering criteria evaluation is as follows: ((fault) & ((severity=critical) | (severity=major) | (severity = minor))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <eventClasses> <fault/> </eventClasses> <netconf:filter type="xpath"> (/event[eventClasses/fault]event notifications matching some forwarding criteria. System components generate event notifications which are passed to a central component for classification and(/event[severity="critical"] or /event[severity="major"] or /event[severity="minor"])) </netconf:filter> </create-subscription> </rpc>distribution. Thefollowing example illustrates selecting fault, state, config EventClasses which have severitiescentral component inspects each event notification and matches the event notification against the set of stream definitions. When a match occurs, the event notification is considered to be a member ofcritical, major, or minorthat event stream. An event notification may be part of multiple event streams. When a NETCONF client subscribes to a given event stream, user- defined filters, if applicable, are applied to the event stream andcome from card Ethernet0. The filtering criteria evaluation is as follows: ((faultmatching event notifications are forwarded to the NETCONF server for distribution to subscribed NETCONF clients. +----+ |statec1 |---+ available streams +----+ |config) & ((fault & severity=critical)+---------+ +----+ |(fault & severity=major)|central |-> stream 1 |(fault & severity = minor)c2 |(card=Ethernet0))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <eventClasses> <fault/> <state/> <config/> </eventClasses> <netconf:filter type="xpath"> ((/event[eventClasses/fault] or /event[eventClasses/state] or /event[eventClasses/config]) and+--->|event |-> stream 2 filter +-------+ +----+ | |processor|-> netconf stream --->|netconf| ... | | |-> stream n |server | see System | +---------+ +-------+ below Components| | // ... | | // +----+ | | (------------) | cn |---+ | (notification) +----+ +-----> ((/event[eventClasses/fault] and /event[severity="critical"]) or (/event[eventClasses/fault] and /event[severity="major"]) or (/event[eventClasses/fault] and /event[severity="minor"]) or /event[card="Ethernet0"])) </netconf:filter> </create-subscription> </rpc> 7. Additional Capabilities 7.1 Call-Home Notifications 7.1.1 Overview Call-Home Notificationslogging ) ( service ) (------------) +-------+ +-------+ |netconf|<--->|netconf| -> |server | |client | +-------+ +-------+ 3.2.1 Event Stream Definition Event streams arean alternative model for providing notificationspre-defined on the managed device. The configuration of event streams is outside the scope of this document. However, it is envisioned that event streams are either pre- established by the vendor (pre-configured) or user configurable (e.g. part of the device's configuration) or both. Device vendors may allow event stream configuration via NETCONF protocol (i.e. edit- config operation) 3.2.2 Event Stream Content Format The contents of all event streams made available to a NETCONF client (i.e. the notification sent by the NETCONF server) must bepreferred for two particular use cases.encoded in XML. 3.2.3 Default Event Stream A NETCONF server implementation supporting the notification capability must support the "NETCONF" notification event stream. This stream contains all NETCONF XML event notifications supported by the NETCONF server. Thefirst use casedefinition of the event notification and their contents for this event stream is outside the scope of this document. 3.2.4 Event Stream Sources With the exception of the default event stream (NETCONF notifications) specification of additional event stream sources (e.g. SNMP, syslog, etc.) isNAT traversal as inoutside the scope of thismodel,document. NETCONF server implementations may leverage any desired event stream source in theNetconfcreation of supported event streams. 3.2.5 Event Stream Discovery A NETCONF client retrieves the list of supported event streams from a NETCONF serverinitiatesusing theNotification session.<get> or <get-config> RPC request. 3.2.5.1 Name Retrieval using get, get-config RPC Thesecond use caselist of available event streams iswhen a manager hasretrieved by requesting the <eventStreams> subtree via alarge number of low-priority devices that<get> or <get-config> operation. Available event streams for the requesting session are returned in the reply containing <name> and <description> elements, where <name> element is mandatory and its value is unique [Editor's Note: should we then define itonly wants to deal with when thereas aknown issue. While this risks losskey?]. The returned list must only include the names ofinformation,those event streams for which the NETCONF sessions has sufficient privileges. The NETCONF session privileges are determined via access control mechanisms which are beyond the scope of thisparticular use case, thisdocument. An empty reply isnot considered an issue.returned if there are no available event streams. Retrieving available event stream list using <get-config> operation: <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <sessionEventStream> <eventStreams/> </sessionEventStream> </top> </filter> </get-config> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <sessionEventStream> <eventStreams> <stream> <name>NETCONF</name> <description>Default netconf event stream </description> </stream> <stream> <name>snmp</name> <description>SNMP notifications</description> </stream> <stream> <name>syslog-critical</name> <description>Critical and higher severity </description> </stream> </sessionEventStreams> </eventStreams> </top> </data> </rpc-reply> Retrieving available event stream list using <get> operation: <get> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <sessionEventStreams> <eventStreams/> </sessionEventStreams> </top> </filter> </get> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <sessionEventStreams> <eventStreams> <stream> <name>NETCONF</name> <description>Default netconf event stream </description> </stream> <stream> <name>snmp</name> <description>SNMP notifications</description> </stream> <stream> <name>syslog-critical</name> <description>Critical and higher severity </description> </stream> </eventStreams> </sessionEventStreams> </top> </data> </rpc-reply> 3.2.5.2 Device Supported Event Streams (System) TheCall-home-Notification feature supports the conceptlist of all event streams configured on ashort-lived notificationdevice may be retrieved over a NETCONF session with sufficient privileges (e.g. administrator). The information is retrieved by requesting the <systemEventStreams> subtree via a <get> or <get-config> operation. <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <systemEventStreams/> </top> </filter> </get-config> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <top xmlns="http://example.com/schema/1.2/config"> <systemEventStreams> <stream> <name>NETCONF</name> <description>Default netconf event stream </description> </stream> <stream> <name>snmp</name> <description>SNMP notifications </description> </stream> <stream> <name>syslog-critical</name> <description>Critical and higher severity </description> </stream> </systemEventStreams> </top> </data> </rpc-reply> 3.2.5.3 Stream Retrieval Schema <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:documentation xml:lang="en"> Schema for event streams </xs:documentation> <xs:appinfo> <nm:identity xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"> <nm:Name> NetconfNotificationSchema </nm:Name> <nm:LastUpdated> 2006-09-06T09:30:47-05:00 </nm:LastUpdated> <nm:Organization>IETF </nm:Organization> <nm:Description> A schema thatonly exists when there is somethingcan be used toreport. In this feature, a subscription consists of a named profile, and an association with a Netconf client. Unlike normal subscriptions, which only exist when they are active, theselearn about current NetConf Event subscriptionslive while both dormantandactive. When an eventcreating named profiles </nm:Description> </nm:identity> </xs:appinfo> </xs:annotation> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="./draft-ietf-netconf-prot-12.xsd"/> <xs:element name="sessionEventStreams"> <xs:annotation> <xs:documentation> The list ofinterest happens on the managed resource,event streams supported by theNetconf server checkssystem. When a query is issued, thelistreturned set ofdormant subscriptionsstreams is determined based on user privileges </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence maxOccurs="unbounded"> <xs:element name="stream"> <xs:annotation> <xs:documentation> Stream name andif the filtering parameters in the subscription indicate interest in the Notification resultingdescription </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="description" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 3.2.6 Event Stream Subscription A NETCONF client may request from theevent, then the NetconfNETCONF serverinitiatestheconnectionlist of available event streams tothe specific Netconf clientthis session andsendsthen issue a <create- subscription> request with theNotification. Whendesired event stream name. Omitting theNotification has been sent,event stream name from theconnection is terminated. A<create-subscription> request results in subscriptionis active when it is currently session between the Netconf client and server relatedtothis subscription on which Notifications can be sent. A subscription is dormant when there is currently no session set up betweentheNetconf client and server related to this notification subscription. 7.1.1.1 Session Lifecycle In order to avoid situationsdefault NETCONF event stream. 3.2.6.1 Filtering Event Stream Contents The set of event notifications delivered inwhich a sessions is continuously setup and torn down,aninactivity timer is configured on the server. The timeout interval valueevent stream may be further refined by applying a user-specified filter at subscription creation time ( <create-subscription> ). This is a transient filter associated with thesame for all sessions (i.e. system wide)event notification subscription andeach session has its own timer. Upon expiration of the inactivity timer, the connection is terminated, otherwise if activity is detected,does not modify thetimer is reset. [Editor's note: alternatives here wereevent stream configuration. 3.2.6.2 Subscription toeither createMultiple Event Streams Multiple event streams may be configured on a device andtear down the session for each notification received ora NETCONF client may subscribe tohave the server somehow figure out that there areone or morenotifications coming soon after it has sent a notification and therefore keepsof theconnection up.] The session establishment procedure is as follows: 1) Theavailable event streams. A NETCONFserver checksclient subscribing toensure there isn't alreadymultiple event streams must do so by either establishing asuitable notification session open. 2) Thenew NETCONFserver initiates asessionusing a recognized transport protocol (SSH, Beep, SOAP, etc). In order to "activate" this reverse behavioror opening a newSSH subsystem may need to be defined. This is for further study. In addition, the NE hosting thechannel on an existing NETCONFserver must support both client and server modes in the case of SSH. 3) Clientsession. 3.3 Subscriptions andserverDatastores Subscriptions areauthenticated according to the underlying transport protocol (e.g. SSH, BEEP) 4) If using BEEP, as describedlike NETCONF sessions in[NETCONF-BEEP] either party may initiate the BEEP session. Once this occurs, the assumption isthatboth parties know their roles. At this point, the NETCONF client, initiatesthey don't exist in NETCONFsession establishment whether running SSH or BEEP. 7.1.2 Dependencies This featuredatastores. The exception to this isdependant onthe named profilesconcept from the normal subscription method as well as the definition of <notification>. It also uses the same <notification> 7.1.3 Capability Identifier urn:ietf:params:xml:ns:netconf:callHomeNotification:1.0 7.1.3.1 New Operations 7.1.3.1.1 New Data Modelfeature. 3.4 Querying Subscription Properties The following Schema can be used to retrieve information about active event notification subscriptions <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"targetNamespace= "urn:ietf:params:xml:ns:netconf:callHomeSubscription:1.0"targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"xmlns:ncEvent= "urn:ietf:params:xml:ns:netconf:notification:1.0"xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"> <xs:annotation> <xs:documentation xml:lang="en"> Schema for reporting ondormant Call-Home NotificationEvent Subscriptions </xs:documentation> <xs:appinfo> <nm:identity xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"><nm:Name>NetConfCallHomeSchema</nm:Name> <nm:LastUpdated>2006-04-30T09:30:47-05:00<nm:Name>NetconfNotificationSchema</nm:Name> <nm:LastUpdated>2006-09-13T09:30:47-05:00 </nm:LastUpdated> <nm:Organization>IETF</nm:Organization> <nm:Description> A schema that can be used to learn aboutcallHome Notificationcurrent NetConf Event subscriptions and creating named profiles </nm:Description> </nm:identity> </xs:appinfo> </xs:annotation> <xs:importnamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0" schemaLocation="urn:ietf:params:xml:ns:netconf:subscription:1.0"/>namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:import namespace="urn:ietf:params:xml:ns:netconf:notification:1.0" schemaLocation= "urn:ietf:params:xml:ns:netconf:notification:1.0"/> <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/> <!-- Associations --> <xs:element name="associatedNamedProfile" type="xs:string"/> <xs:element name="relationships"> <xs:keyref name="subscriptionToNamedProfile" refer="nsub:namedProfileKey"> <xs:selector xpath=".//netconfSubscription"/> <xs:field xpath="nsub:associatedNamedProfile"/> </xs:keyref> <!-- Keys --> <xs:key name="namedProfileKey"> <xs:selector xpath=".//namedProfile"/> <xs:field xpath="name"/> </xs:key> </xs:element> <xs:elementname="callHomeSubscription">name="netconfSubscription"> <xs:annotation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/></nm:maxAccess> </xs:appinfo> </xs:annotation> <xs:complexType><xs:sequence> <xs:element name="subscriber"<xs:sequence ><xs:annotation> <xs:documentation> The Netconf client that is subscribed to receive these notifications as part of the call-home subscription. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element type="ip:IPAddressOrSysname" name="iPAddressOrSysname"/> <xs:element type="xs:integer" name="port"/> </xs:sequence> </xs:complexType> </xs:element><xs:elementname="namedProfile" type="xs:string" minOccurs="0">name="session-id" type="netconf:SessionId" > <xs:annotation> <xs:documentation xml:lang="en"> Thenamed profilesession id associated with this subscription.Note that the contents of the named profile may have changed since it was last applied</xs:documentation> </xs:annotation><xs:keyref refer="nsub:namedProfileKey" name="namedProfileKeyRef"> <xs:selector xpath=".//namedProfile"> </xs:selector> <xs:field xpath="namedProfile"></xs:field> </xs:keyref></xs:element> <xs:elementname="status"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Dormant"/> <xs:enumeration value="Active"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 7.1.3.1.2 Modifications to Existing Operations 7.1.3.1.2.1 <create-subscription> This capability adds a new attribute to the <create-subscription> command. This attribute is callHome: An optional parameter that, when present, indicates whether this will be a call-home Notification subscription. If not present, this will be a normal subscription. 7.1.3.1.3 Interactions with Other Capabilities It is only when these subscriptions move from the dormant state to the active state that they have sessions associated with them. It is only at this point that they show up in the active subscription list. 8. Security Considerations To be determined once specific aspects of this solution are better understood. In particular, the access control framework and the choice of transport will have a major impact on the security of the solution 9. IANA Considerations Event Classes will likely be an IANA-managed resource. The initial set of values is defined in this specification. In order for new event classes to be allocated, the following requirements must be met: o There must be working group consensus to add the new class o A detailed description of its purpose in the netconf protocol must be provided o A detailed description of all manager and agent implementation requirementsname="subscriptionID" type="ncEvent:SubscriptionID" > <xs:annotation> <xs:documentation xml:lang="en"> The subscription id associated withthe event class must be provided othis subscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> Thedescription must make clear to developers how to determine when it is appropriate to choosefilters associated with thisevent classification for a new notification type list 10. Acknowledgements Thanks to Gilbert Gagnon and Greg Wilbur for providing their input into the early work onsubscription. </xs:documentation> </xs:annotation> </xs:element> <xs:element ref="nsub:associatedNamedProfile" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The named profile associated with thisdocument. In addition, the editors would like to acknowledge input atsubscription. Note that theVancouver editing session fromcontents of thefollowing people: Orly Nicklass, James Bakstrieve, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave Partain, Ray Atarashi and Dave Perkins. In addition, they would like to thank Balazs Lengyel his contributions tonamed profile may have changed since it was last applied. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="lastModified" type="xs:dateTime" > <xs:annotation> <xs:documentation xml:lang="en"> The last time this subscription was modified. If it has not been modified since creation, this is the time of subscription creation. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="messagesSent" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> A count of eventclass text. 11. References [NETCONF] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-12, February 2006. [NETCONF BEEP] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", ID draft-ietf-netconf-beep-10, March 2006. [NETCONF Datamodel] Chisholm, S. and S. Adwankar, "Framework for NETCONF Content", ID draft-chisholm-netconf-model-05.txt, April 2006. [NETCONF SOAP] Goddard, T., "Using the Network Configuration Protocol (NETCONF) Overnotifications sent along this connection since theSimple Object Access Protocol (SOAP)", ID draft-ietf-netconf-soap-08, March 2006. [NETCONF SSH] Wasserman, M. and T. Goddard, "Usingsubscription was created. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="key"> <xs:key name="uniqueSubscription"> <xs:selector xpath=".//subscription"/> <xs:field xpath="session-id"/> <xs:field xpath="subscriptionID"/> </xs:key> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="netconfSubscriptions"> <xs:complexType> <xs:sequence> <xs:element ref="nsub:netconfSubscription" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="namedProfile"> <xs:annotation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/> <write/> <create/> <delete/> </nm:maxAccess> </xs:appinfo> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="name"/> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en"> The filters associated with this named profile. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="lastModified" type="xs:dateTime"> <xs:annotation> <xs:documentation> The timestamp of theNETCONF Configuration Protocol over Secure Shell (SSH)", ID draft-ietf-netconf-ssh-06.txt, March 2006. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>. [refs.RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [refs.RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements Levels", RFC 2119, March 1997. [refs.RFC2223] Postel, J. and J. Reynolds, "Instructionslast modification toRFC Authors", RFC 2223, October 1997. [refs.RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Authors' Addresses Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada Email: schishol@nortel.com Kim Curran Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada Email: kicurran@nortel.com Hector Trevino Cisco Suite 400 9155 E. Nichols Ave Englewood, CO 80112 USA Email: htrevino@cisco.com Appendix A. Design Alternatives A.1 Suspend And Resume The purposethis named Profile. Note that modification of the<cancel-subscription> operationprofile does not cause an immediate update to all applicable subscription. Therefore, this time should be compared with the last modified time associated with the subscription. If this time isto stop event notification forwarding and sinceearlier, then thenotificationsubscription istransientusing theoperation naturally removes all subscription configuration; Forexact set of parameters associated with thisreasons, a different mechanism might be needed for shutting down the notification session but preservingnamed profile. If this time is later, then the subscriptioninformation thus allowing the NETCONF server to re- establish the parametersis using an earlier version of this named profile andreproducethenotification subscription. The suspend and resume commands would allows a NETCONF clientexact parameters may not match. </xs:documentation> <xs:appinfo> <nm:minAccess><read/></nm:minAccess> <nm:maxAccess><read/> </nm:maxAccess> </xs:appinfo> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="namedProfiles"> <xs:complexType> <xs:sequence> <xs:element ref="nsub:namedProfile" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 3.5 One-way Notification Messages In order tosuspendsupport the concept that each individual event notificationforwarding without removing the existing subscription information. It couldis a well-defined XML-document that can beused for both subscriptions based on persistent and non-persistent subscription information. Operations <suspend-subscription> and ><resume-subscription> are proposedprocessed without waiting forthis purpose. If event subscription information is now persistent, unsolicited session termination (i.e. other than <cancel-subscription)) is treatedall events to come in, it makes sense to define events, not asif a <suspend-subscription> command was issued. Event forwarding is resumed by sending a <resume-subscription>an endless reply tothe NETCONF server onanew connection. A.2 Lifecycle Configuration information associated with the eventsubscription(event classes and filters) could persist beyond the life ofcommand, but as independent messages that originate from theevent subscription session. (i.e. it is maintained byNETCONF server. In order to support this model, this memo introduces thenetwork element as partconcept ofits configuration). This configuration informationnotifications, which are one-way messages. A one-way message issubjectsimilar to thebehaviour of the datastore it resides in and may or may not persist across re-boots (e.g. it could be part of the running configuration but nottwo-way RPC message, except that no response is expected to thestartup configuration). Appendix B. Event Notifications and Syslog This appendix describescommand. In themapping between syslogcase of event notification, this messagefieldswill originate from the NETCONF server, and not the NETCONF client. 3.6 Filter Dependencies Note that when multiple filters are specified (in-line Filter, Named Profiles), they are applied collectively, so eventnotification fields. The purpose of this mapping isnotifications need toprovide an unambiguous mappingpass all specified filters in order toenable consistent multi-protocol implementations as well asbe sent toenable future migration. The second part oftheappendix describes an optional capability to embed an entire syslog message (hereafter referred to as syslog message(s)subscriber. If a filter is specified toavoid confusion withlook for data of a particular value, and themessage field in syslog)data item is not present within aNETCONF event notification. B.1 Leveraging Syslog Field Definitions This section provides a semantic mapping between NETCONFparticular eventfields and syslog message fields. ------------------------------------------------------------------- | PRI | HEADER | MESSAGE | ------------------------------------------------------------------- | FACILITY | SEVERITY | TIMESTAMP | HOSTNAME | TAG CONTENT | ------------------------------------------------------------------- Figure 2 - syslog message (RFC3164) ------------------------------------------------------------------- | HEADER | STRUCTURED DATA | MESSAGE | ------------------------------------------------------------------- Figure 3 - syslog message (draft-ietf-syslog-protocol-14.txt) HEADER (Version, Facility, Severity, Truncate, Flag, TimeStamp, HostName, AppName, ProcId, MsgId) STRUCTURED DATA (Zero or more Structured Data Elements - SDEs) MESSAGE ( Text message ) B.1.1 Field Mapping ------------------------------------------------------ RFC3164 Syslog ID NETCONF Event ------------------------------------------------------ VERSION ------------------------------------------------------ FACILITY FACILITY ------------------------------------------------------ SEVERITY SEVERITY PerceivedSeverity ------------------------------------------------------ TRUNCATE FLAG ------------------------------------------------------ TIMESTAMP TIMESTAMP EventTime ------------------------------------------------------ HOSTNAME HOSTNAME EventOrigin ------------------------------------------------------ TAG APP-NAME EventOrigin ------------------------------------------------------ PROC-ID ------------------------------------------------------ MSG-ID ------------------------------------------------------ CONTENT CONTENT AdditionalText ------------------------------------------------------ Figure 4 - syslog to NETCONF Event field mapping Notes: VERSION: Schema version is found in XML Schema namespace. However, no correspondence to syslog. FACILITY: No well defined semanticsnotification forthis field. Therefore not used at this time. TRUNCATE: Not applicable. NETCONF events mustits value to becomplete XML documents therefore cannotchecked against, it will betruncated. TIME: TIMESTAMPfiltered out. For example, if one were to check for 'severity=critical' insyslog ID is derived from RFC3339 but with additional restrictions PROC-ID: No equivalent field CONTENT: This isafree form text field with not defined semantics. The contents ofconfiguration event notification where this fieldmay be included inwas not supported, then theAdditionalText field. B.1.2 Severity Mapping The severity value mappings stated in (draft-ietf-syslog-protocol-14) are used: ITU Perceived Severity syslog SEVERITY Critical Alert Major Critical Minor Error Warning Warning Indeterminate Notice Cleared Notice Figure 5. ITU Perceived Severity to syslog SEVERITY mapping. B.2 Syslog within NETCONF Events B.2.1 Motivation The syslog protocol (RFC3164)notification would be filtered out. Note that the order that filters are applied does not matter since the resulting set of notifications iswidely used by equipment vendors as a means to deliver event messages. Due tothewidespread useintersection ofsyslog as well as a potential phased availability and coveragethe set ofNETCONF events by equipment vendors, it is envisionednotifications thatusers will also follow a phased migration. Aspass each filtering criteria. 3.6.1 Named Profiles A named profile is away to facilitate migrationfilter that is created ahead of time and applied at thesametimeallow equipment vendors to provide comprehensive event coverage over a NETCONFan event notification subscriptionsession, syslog messages could be embedded in their entirety within the body of a NETCONF event notification. The information provided in this appendix describes a mechanismis created . Note that changes toleverage syslog messages forthepurpose of complementingprofile after theavailable NETCONF event notification set. The intent is to promotesubscription has been created will have no effect on theusesubscription. Since named profiles exist outside of theNETCONF interface and not to simply provide a wrapper and additional delivery mechanism for syslog messages. NETCONF events are intended to be well defined and structured, therefore providing an advantage over the unstructured and often times arbitrarily defined syslog messages (i.e.subscription, they persist after themessage field). Covered hereinsubscription has been torn down. 3.6.2 Filtering Just-in-time filtering is explicitly stated when thesyslog protocol as defined in RFC3164 and draft-ietf-syslog-protocol-14.txt. B.2.2 Embedding syslog messages in a NETCONF Event Wheneventnotifications are supported, the default behaviour for a NETCONF servernotification subscription is created. This is specified via the Filter parameter. Filters only exist as parameters tosend NETCONF event notifications over an established event subscription. As an option,theNETCONF server may embed a syslogsubscription. 3.7 Message Flow The following figure depicts message flow between a Netconf client (C) and Netconf server (S) inits entirety (e.g. RFC3164 - PRI, Header,order create a subscription andMessage fields), placing it withinbegin theEvent Info field (SyslogInfo sub-field) - see Figure 1. ______________________________________________________flow of notifications. C S |NETCONF Event Header|Data||________________________ |___________________________|capability exchange | |-------------------------->| |<------------------------->| |Event Info||_________________________|___________________________||v ____________________________<create-subscription> |Event Fields|-------------------------->| |<--------------------------| |SyslogInfo<rpc-reply> ||___________________________| Figure 1 - Embedding syslog in a NETCONF| | | <notification> | |<--------------------------| | | | <notification> | |<--------------------------| | | | | | | | <notification> | |<--------------------------| | | | | 4. XML Schema for Event NotificationsB.2.3 Supported Forwarding Options Three event forwarding options may be supported by the NETCONF server: a) XML only (mandatory if NETCONF events capability is supported) b)<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"> <!-- import standard XMLand syslog (Optional) c) syslog only (optional) Note todefinitions --> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> This import accesses thereader: Option "a" above refers to event notification messages definedxml: attribute groups foruse overtheNETCONF protocol. While their use is not necessarily limited to NETCONF protocol, they are referred toxml:lang as"NETCONF XML-event" indeclared on theremainder oferror-message element. </xs:documentation> </xs:annotation> </xs:import> <!-- import base netconf definitions --> <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" /> <!-- ************** Type definitions ***********************--> <xs:simpleType name="SubscriptionID"> <xs:annotation> <xs:documentation> The unique identifier for thissection simplyparticular subscription within the session. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="SequenceNumber"> <xs:annotation> <xs:documentation> A monotonically increasing integer. Starts at 0. Always increases by just one. Roll back toavoid ambiguity. B.2.3.1 XML and Syslog option - Forwarding Behaviour It0 after maximum value ispossible, duereached. </xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"/> </xs:simpleType> <!-- ************** Symmetrical Operations ********************--> <!-- <create-subscription> operation --> <xs:complexType name="createSubscriptionType"> <xs:complexContent> <xs:extension base="netconf:rpcOperationType"> <xs:sequence> </xs:element> <xs:element name="filter" type="netconf:filterInlineType" minOccurs="0"/> <xs:element name="named-profile" type="xs:string" minOccurs="0"/> <xs:element name="startTime" type="xs:dateTime" minOccurs="0" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="create-subscription" type="createSubscriptionType" substitutionGroup="netconf:rpcOperation"/> <!-- ************** One-way Operations ******************--> <!-- <Event> operation --> <xs:complexType name="NotificationType"> <xs:sequence> <xs:element name="subscriptionId" type="SubscriptionID" /> </xs:sequence> </xs:complexType> <xs:element name="notification" type="NotificationType"/> </xs:schema> 5. Mapping tocoverage, for a givenTransport Protocols Currently, the NETCONFimplementation to not support a comprehensive setfamily ofNETCONF event notifications. Therefore, it is possiblespecification allows fora given event to trigger the generation of a syslog message without a NETCONF-aware counterpart. In such situations, therunning NETCONFserver could formover aNETCONF event notification, embed the syslog message in the SyslogInfo field and forward the NETCONFnumber of transport protocols, some of which support multiple configurations. Some of these options will be better suited for supporting event notificationsto all subscribed destinations. Otherwise, both NETCONF eventthen others. 5.1 SSH Session establishment andsyslogtwo-way messagesmust be included in the Event Info field. B.2.3.2 Event Class Identification The event class field is found inare based on the NETCONF over SSH transport mapping [NETCONF-SSH] One-way eventheader informationmessages are supported asdescribed in the main body of this document. It conveys information describing what type of event for whichfollows: Once theevent notification is generatedsession has been established andlets the consumer of the message know what sort of content to expect. NETCONF event notifications which only contain a syslog message (Options c) mustcapabilities have been exchanged, theEventClass field setserver may send complete XML documents to"syslog". Thethe NETCONF clientparsescontaining notification elements. No response is expected from themessage inNETCONF client. As thesame manner as any other message, findsexamples in [NETCONF-SSH] illustrate, a special character sequence, MUST be sent by both thenormal fields (ie, XML- marked content) not presentclient andeither proceeds to parse the SyslogInfo field or handsthesyslog message toserver after each XML document in theentity responsible for processing syslog messages. B.2.3.3 Event Subscription Options ANETCONFclient may request subscription to options b)exchange. This character sequence cannot legally appear in an XMLand syslog or c) syslog only listeddocument, so it can be unambiguously used to identify the end of the current document in"Supported Forwarding Options" at subscription time viatheuser-specified filter. The FILTERevent notification of an XML syntax orNAMED FILTER parameter in <create-subscription>. As previously indicated,parsing error, allowing resynchronization of thedefault behaviour is to forwardNETCONFXML only event notifications. [Editor's Note: How is this done exactly?] B.2.3.4 Supported Forwarding Option Discovery A potential means for aexchange. The NETCONFserverover SSH session toconvey its feature set support is via capabilities. However, in this particular case,receive an event notification might look like the following. Note the eventcontent is not a protocol feature therefore other meansnotification contents (delimited by <data> </data> tags) areneeded. A future version ofnot defined in this documentwill address this issue. Appendix C. Example Configuration Notifications This non-normative appendix provides a detailed description of a configuration change event notification definitionand are provided herein simply for illustration purposes: <?xml version="1.0" encoding="UTF-8"?> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <subscription-id>123456</subscription-id> <data> <eventClasses><configuration/><audit/></eventClasses> <sequenceNumber>2</sequenceNumber> <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> <user>Fred Flinstone</user> <operation> <edit-config> <target> <running/> </target> <config> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>1500</mtu> </interface> </top> </config> </edit-config> </operation> </data> </notification> ]]> ]]> 5.2 BEEP Session establishment and two-way messages are based on the NETCONF over BEEP transport mapping NETCONF-BEEP 5.2.1 One-way Notification Messages insupport ofBeep One-way notification messages can be supported either by mapping to theconfiguration operations, particularly those definedexisting one-to-many BEEP construct or by creating a new one-to- none construct. This area is for future study. 5.2.1.1 One-way messages via theNETCONF protocol. C.1 Types of Configuration Events Configuration event notifications include: o All-triggered Configuration Events o NETCONF-triggered Configuration Events All-triggered Configuration events report on changes fromOne-to-many Construct Messages in one-to-many exchanges: "rpc", "notification", "rpc-reply" Messages in positive replies: "rpc-reply", "rpc-one-way" 5.2.1.2 One-way notification messages via theperspective ofOne-to-none Construct Note that this construct would need to be added to an extension or update to 'The Blocks Extensible Exchange Protocol Core' RFC 3080. MSG/NoANS: themanaged resource, rather thanclient sends a "MSG" message, thecommands which createdserver, sends no reply. In one-to-none exchanges, no reply to theconfiguration change. They"MSG" message is expected. 5.3 SOAP Session management and message exchange arereported regardless of what specific method was used to initiatebased on thechange. They indicateNETCONF over SOAP transport mapping NETCONF-SOAP Note thata change has occurred around hardware, software, services or other managed resources within a system. Specific events includes o Resource Added o Resource Removed o Resource Modified NETCONF-triggered events are those which correspond totheexecutionuse of "persistent connections" "chunked transfer- coding" when using HTTP becomes even more important in the supporting ofexplicit NETCONF operations. These include: o copy-config event * This is a data store leveleventgeneratednotifications 5.3.1 A NETCONF over Soap over HTTP Example C: POST /netconf HTTP/1.1 C: Host: netconfdevice C: Content-Type: text/xml; charset=utf-8 C: Accept: application/soap+xml, text/* C: Cache-Control: no-cache C: Pragma: no-cache C: Content-Length: 465 C: C: <?xml version="1.0" encoding="UTF-8"?> C: <soapenv:Envelope C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> C: <soapenv:Body> C: <rpc message-id="101" C: xmlns= "xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> C: <create-subscription> C: </create-subscription> C: </rpc> C: </soapenv:Body> C: </soapenv:Envelope> The response: S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <rpc-reply message-id="101" S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> S: <data> S: <top xmlns= "http://example.com/schema/1.2/notification"> S: <subscriptionId>123456</subscriptionId> S: </top> S: </data> S: </rpc-reply> S: </soapenv:Body> S: </soapenv:Envelope> And then some time later S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> S: <subscriptionID>123456</subscriptionID> S: <data> S: <eventClasses><configuration/><audit/></eventClasses> S: <sequenceNumber>2</sequenceNumber> S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> S: <user>Fred Flinstone</user> S: <operation> S: <edit-config> S: <target> S: <running/> S: </target> S: <config> S: <top xmlns="http://example.com/schema/1.2/config"> S: <interface> S: <name>Ethernet0/0</name> S: <mtu>1500</mtu> S: </interface> S: </top> S: </config> S: </edit-config> S: </operation> S: </data> S: </notification> S: </soapenv:Body> S: </soapenv:Envelope> 6. Filtering examples The following section provides examples to illustrate thesuccessful completion of a copy-config operation. This represents the creation of a new configuration file or replacementvarious methods of filtering content on anexisting one. o delete-configevent* Thisnotification subscription. 6.1 Subtree Filtering XML subtree filtering isa data store levelnot well suited for creating elaborate filter definitions given that it only supports equality comparisons and logical OR operations (e.g. in an eventgenerated following the successful completion of a delete-config operation. This represents the deletion of a configuration file. o edit-configsubtree give me all event* This is annotifications which have severity=critical or severity=major or severity=minor). Nevertheless, it may be used for defining simple eventgenerated following a change in configuration due to an edit-config operation, e.g., duenotification forwarding filters as shown below. In order to illustrate thecompletionuse ofan edit-config operation which successfully changedfilter expressions it is necessary to assume somepartof theconfiguration. See edit-config error-options (stop-on- error, ignore-error, rollback-on-error)event notification content (only for example purposes). Thecontents of thisexamples herein assume that the eventare dependent onnotification schema definition has an <eventClasses> element identifying thetype of operation performed: edit- config (merge, replace, delete, create). Thisevent category (e.g. fault, state, config, etc.) and events have a <severity> element The following example illustrates selecting events which have severities of critical, major, or minor (presumably fault events). The filtering criteria evaluation isnot intendedas follows: ((severity=critical) | (severity=major) | (severity=minor)) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <netconf:filter type="subtree"> <neb xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <event> <severity>critical</severity> </event> <event> <severity>major</severity> </event> <event> <severity>minor</severity> </event> </neb> </netconf:filter> </create-subscription> </rpc> The following example illustrates selecting fault, state, config EventClasses or events which are related toreport completely unsuccessful configuration operations. o lock-config event * Thiscard Ethernet0. The filtering criteria evaluation isa data store level event generatedas follows: (fault | state | config | card=Ethernet0) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <netconf:filter type="subtree"> <neb xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <event> <eventClasses>fault</eventClasses> </event> <event> <eventClasses>state</eventClasses> </event> <event> <eventClasses>config</eventClasses> </event> <event> <card>Ethernet0</card> </event> </neb> </netconf:filter> </create-subscription> </rpc> 6.2 XPATH filters The followingthe successful lockingexample illustrates selecting fault EventClass notifications that have severities ofa configuration data store. o unlock-config event * Thiscritical, major, or minor. The filtering criteria evaluation isa data store level event generatedas follows: ((fault) & ((severity=critical) | (severity=major) | (severity = minor))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <netconf:filter type="xpath"> (/event[eventClasses/fault] and (/event[severity="critical"] or /event[severity="major"] or /event[severity="minor"])) </netconf:filter> </create-subscription> </rpc> The followingthe successful releaseexample illustrates selecting fault, state and config EventClasses which have severities ofa lock previously held on a configuration data store. C.2 Config Event Notification Structurecritical, major, or minor and come from card Ethernet0. Thetable below lists the EventInfo parameters for a config event notification. Nomenclature: O - This is marked optional field because itfiltering criteria evaluation isimplementation/ notification category dependent. In some cases this may be user configurable. M - Thisas follows: ((fault | state | config) & ((fault & severity=critical) | (fault & severity=major) | (fault & severity = minor) | (card=Ethernet0))) <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <create-subscription> <netconf:filter type="xpath"> ((/event[eventClasses/fault] or /event[eventClasses/state] or /event[eventClasses/config]) and ( (/event[eventClasses/fault] and /event[severity="critical"]) or (/event[eventClasses/fault] and /event[severity="major"]) or (/event[eventClasses/fault] and /event[severity="minor"]) or /event[card="Ethernet0"])) </netconf:filter> </create-subscription> </rpc> 7. Notification Replay Capability 7.1 Overview Replay isa mandatory field that must be included. Dependency onthe ability to create an eventclass may existsubscription that will resend recently sent notifications. These notifications are sent the same way asnoted below ----------------------------------------------------- Parameter Name Restrictions ----------------------------------------------------- EventInfo ----------------------------------------------------- EventID O ----------------------------------------------------- ResourceInstance M ----------------------------------------------------- ConfigChangeType M ----------------------------------------------------- TargetDataStore M ----------------------------------------------------- UserInfo O ----------------------------------------------------- UserName ----------------------------------------------------- SourceIndicator ----------------------------------------------------- TransactionId ----------------------------------------------------- CopyConfigInfo -- copy-config only ----------------------------------------------------- DataSource M ----------------------------------------------------- EditConfigInfo -- edit-config only ----------------------------------------------------- EventTime M ----------------------------------------------------- Context O ----------------------------------------------------- EnteredCommand M ----------------------------------------------------- NewConfig M ----------------------------------------------------- MergeReplaceInfo ----------------------------------------------------- OldConfig O ----------------------------------------------------- EventTime M ----------------------------------------------------- EventGenerationTime ----------------------------------------------------- EventSysUpTime ----------------------------------------------------- C.3 Configuration Event Content The applicabilitynormal notifications. A replay ofthese fields to other event classesnotifications isfor further study. C.3.1 Target Datastore Target datastore refers to the data store (startup, candidate, running) which was modifiedspecified bythe management operation. C.3.2 User Info This is usedincluding an optional parameter toconvey information describing who originatedtheconfiguration event andsubscription command that indicates themeans for submittingstart time of therequest.replay. Theuser info field contains the following information: user Name: User id which was authorized to execute the associated management operation causing the generationend time ofthis event. source Indicator: Indicatesthemethod employedreplay is implicitly defined toinitiatebe themanagement operation telnet, NETCONF, console, etc. transaction Id: If available, this field contains a unique identifier fortime theassociated management operation. This isreplay request was initiated. An implementationdependent and may require additional information to be communicated between server and client. A possible optionthat supports replay is not expected tomake usehave an unlimited supply of saved notifications available to accommodate any replay request. If a client requests a replay of notifications that predate themessage-id inoldest notification available, then the NETCONFrpc header C.3.3 Data Source The data source is used, for example,server must return an warning message in thecopy configuration command to indicatedRPC reply and start replaying thesource of information used innotifications it does have available, within thecopy operation Applicable Event Classes: configuration (usefulother constraints, such as filtering, that the client has provided. The actual number of stored notifications available forcopy-config) C.3.4 Operation Operationretrieval at any given time isused,an agent implementation specific matter. Control parameters forexample, inthis aspect of theedit configuration command to indicatedfeature are outside thespecific operation that has taken place - create, delete, merge, replace. Applicable Event Classes: configuration (useful for edit-config) C.3.5 Context The configuration sub-mode underscope of the current work. A given subscription is either a replay subscription or a normal subscription, which sends event notifications as they happen. A replay subscription terminates once thecommand was executed. Applicable Event Classes: configuration C.3.6 Entered Command The command entered and executedit has completed replaying past events. 7.2 Dependencies This capability is dependent on thedevice. C.3.7 New Config The device's configuration followingnotification capability being supported. It also requires that the device support some form of notification logging, although it puts no restrictions on thesuccessful executionsize or form of theentered command. Applicable Event Classes: configuration C.3.8 Old Configlog. 7.3 Capability Identifier Theconfiguration priorEvent Notification Replay capability is identified by following capability string: http://ietf.org/netconf/notificationReplay/1.0 7.4 New Operations None 7.5 Modifications to Existing Operations 7.5.1 create-subscription This capability adds an optional parameter to theexecution of<create- subscription> command called 'startTime'. This identifies theentered command. Applicable Event Classes: configuration C.3.9 Non-netconf commands in configuration notifications To support legacy implementationsearliest date and time of interest forbetter integrationevent notifications being replayed. Events generated before this time are not matched. 7.5.2 Interactions with Other Capabilities [Edtitor's Note: If this capability does not interact with otherdeployed solutions on the box, sending information via netconf about configuration changes that were originated via other solutions, such as command line interfaces is necessary.capabilities, this section may be omitted.] 8. Security Considerations To be determined once specific aspects of this solution are better understood. Inorder to do this,particular, theinformation inaccess control framework and themessage needs to be clearly tagged so thatchoice of transport will have a major impact on theconsumersecurity of theinformation knows whatsolution 9. Acknowledgements Thanks toexpect.Gilbert Gagnon, Greg Wilbur and Kim Curran for providing their input into the early work on this document. In addition, thecreation ofeditors would like to acknowledge input at thesubscription needs allow forVancouver editing session from theclient to indicate whether this non-XML formatted information is of interest The latter is done by identifyingfollowing people: Orly Nicklass, James Balestriere, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave Partain, Ray Atarashi and Dave Perkins and theXML namespace under whichfollowing additional people from thedata syntax/schema is defined. AMontreal editing session: Balazs Lengyel, Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William Chow 10. References [NETCONF] Enns, R., "NETCONF Configuration Protocol", ID draft-ietf-netconf-prot-12, February 2006. [NETCONF BEEP] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)", ID draft-ietf-netconf-beep-10, March 2006. [NETCONF Datamodel] Chisholm, S. and S. Adwankar, "Framework for NETCONFclient requestsContent", ID draft-chisholm-netconf-model-05.txt, April 2006. [NETCONF SOAP] Goddard, T., "Using theformat in which it wantsNetwork Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)", ID draft-ietf-netconf-soap-08, March 2006. [NETCONF SSH] Wasserman, M. and T. Goddard, "Using the NETCONFserverConfiguration Protocol over Secure Shell (SSH)", ID draft-ietf-netconf-ssh-06.txt, March 2006. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>. [refs.RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [refs.RFC2119] Bradner, s., "Key words for RFCs toissue the event notifications at subscription time by specifying the appropriate namespace under the Filter parameter in the <create-subscription> operation. An example is provided below: <netconf:filter> <data-format:config-format-xml xmlns="http://www.example.com/xmlnetevents"/> </netconf:filter> Appendix D. IP Address Schema <?xml version="1.0" encoding="UTF-8"?> <!-- IETF Netconf Working Group http://www.ietf.org/html.charters/netconf-charter.html --> <xs:schema elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.2" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:netmod:ipAddress:1.0" targetNamespace="urn:ietf:params:xml:ns:netmod:ipAddress:1.0"> <xs:simpleType name = "ipV4Addr"> <xs:annotation> <xs:documentation> An IP version 4 address in dotted notation decimal. Example: 15.13.120.22 </xs:documentation> </xs:annotation> <xs:restriction base = "xs:string"> <xs:pattern value = "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name = "ipV6Addr"> <xs:annotation> <xs:documentation> An IP version 6 address in colon separated 2 byte block hexadecimal notation. Example: FEDC:AB19:12FE:0234:98EF:1178:8891:CAFF </xs:documentation> </xs:annotation> <xs:restriction base = "xs:string"> <xs:pattern value = "[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}: [0-9a-fA-F]{4}:[0-9a-fA-F]{4}: [0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}"/> </xs:restriction> </xs:simpleType> <xs:complexType name="IPAddressOrSysname"> <xs:choice> <xs:element name="ipv4Address" type="ipV4Addr"/> <xs:element name="ipv6Address" type="ipV6Addr"/> <xs:element name="sysName" type="xs:string"/> </xs:choice> </xs:complexType> </xs:schema>Indicate Requirements Levels", RFC 2119, March 1997. [refs.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [refs.RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Authors' Addresses Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada Email: schishol@nortel.com Hector Trevino Cisco Suite 400 9155 E. Nichols Ave Englewood, CO 80112 USA Email: htrevino@cisco.com Intellectual Property Statement 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.