draft-ietf-netconf-notification-04.txt | draft-ietf-netconf-notification-05.txt | |||
---|---|---|---|---|
Network Working Group S. Chisholm | Network Working Group S. Chisholm | |||
Internet-Draft Nortel | Internet-Draft Nortel | |||
Intended status: Standards Track H. Trevino | Intended status: Standards Track H. Trevino | |||
Expires: April 25, 2007 Cisco | Expires: June 22, 2007 Cisco | |||
October 22, 2006 | December 19, 2006 | |||
NETCONF Event Notifications | NETCONF Event Notifications | |||
draft-ietf-netconf-notification-04.txt | draft-ietf-netconf-notification-05.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 25, 2007. | This Internet-Draft will expire on June 22, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document defines mechanisms which provide an asynchronous | This document defines mechanisms which provide an asynchronous | |||
message notification delivery service for the NETCONF protocol. This | message notification delivery service for the NETCONF protocol. This | |||
is an optional capability built on top of the base NETCONF | is an optional capability built on top of the base NETCONF | |||
definition. This document defines the capabilities, operations, | definition. This document defines the capabilities and operations | |||
transport mappings, and data models necessary to support this | necessary to support this service. | |||
service. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 | 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Event Notifications in NETCONF . . . . . . . . . . . . . . 5 | 1.2. Event Notifications in NETCONF . . . . . . . . . . . . . . 5 | |||
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Notification-Related Operations . . . . . . . . . . . . . . . 7 | 2. Notification-Related Operations . . . . . . . . . . . . . . . 7 | |||
2.1. Subscribing to receive Event Notifications . . . . . . . . 7 | 2.1. Subscribing to receive Event Notifications . . . . . . . . 7 | |||
2.1.1. <create-subscription> . . . . . . . . . . . . . . . . 7 | 2.1.1. <create-subscription> . . . . . . . . . . . . . . . . 7 | |||
2.1.2. Filter Dependencies . . . . . . . . . . . . . . . . . 8 | ||||
2.2. Sending Event Notifications . . . . . . . . . . . . . . . 8 | 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 8 | |||
2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 8 | 2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 8 | |||
2.3. Terminating the Subscription . . . . . . . . . . . . . . . 9 | 2.3. Terminating the Subscription . . . . . . . . . . . . . . . 9 | |||
3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10 | 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10 | 3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10 | |||
3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 10 | ||||
3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 10 | ||||
3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10 | 3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 11 | 3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 11 | |||
3.2.2. Event Stream Content Format . . . . . . . . . . . . . 11 | 3.2.2. Event Stream Content Format . . . . . . . . . . . . . 11 | |||
3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 11 | 3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 11 | |||
3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12 | 3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12 | |||
3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12 | 3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12 | |||
3.2.6. Event Stream Subscription . . . . . . . . . . . . . . 15 | 3.2.6. Event Stream Subscription . . . . . . . . . . . . . . 15 | |||
3.3. Subscriptions not Configuration Data . . . . . . . . . . . 15 | 3.3. Subscriptions not Configuration Data . . . . . . . . . . . 15 | |||
3.4. Querying Subscription Properties . . . . . . . . . . . . . 16 | 3.4. Filter Dependencies . . . . . . . . . . . . . . . . . . . 15 | |||
3.5. Filter Dependencies . . . . . . . . . . . . . . . . . . . 20 | 3.4.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 15 | |||
3.5.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 21 | 3.4.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 21 | 3.5. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.6. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21 | 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 17 | |||
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 23 | 5. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 20 | |||
5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 25 | 5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 20 | |||
5.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 21 | |||
5.2. BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 6. Notification Replay . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.2.1. One-way Notification Messages in Beep . . . . . . . . 26 | 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6.2. Creating a Subscription with Replay . . . . . . . . . . . 23 | |||
5.3.1. A NETCONF over Soap over HTTP Example . . . . . . . . 27 | 6.3. Replay Complete Notification . . . . . . . . . . . . . . . 24 | |||
6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 30 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | |||
6.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 30 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 31 | 9. Normative References . . . . . . . . . . . . . . . . . . . . . 28 | |||
7. Notification Replay Capability . . . . . . . . . . . . . . . . 33 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 33 | Intellectual Property and Copyright Statements . . . . . . . . . . 30 | |||
7.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
7.3. Capability Identifier . . . . . . . . . . . . . . . . . . 33 | ||||
7.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
7.5. Modifications to Existing Operations . . . . . . . . . . . 34 | ||||
7.5.1. create-subscription . . . . . . . . . . . . . . . . . 34 | ||||
7.5.2. Interactions with Other Capabilities . . . . . . . . . 34 | ||||
7.6. Replay Complete Notification . . . . . . . . . . . . . . . 34 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | ||||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
10. Normative References . . . . . . . . . . . . . . . . . . . . . 38 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 40 | ||||
1. Introduction | 1. Introduction | |||
[NETCONF] can be conceptually partitioned into four layers: | [NETCONF] can be conceptually partitioned into four layers: | |||
Layer Example | Layer Example | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
| Content | | Configuration data | | | Content | | Configuration data | | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
| | | | | | |||
skipping to change at page 4, line 30 | skipping to change at page 4, line 30 | |||
+-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | | |||
| | | | | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
| Transport | | BEEP, SSH, SSL, console | | | Transport | | BEEP, SSH, SSL, console | | |||
| Protocol | | | | | Protocol | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
This document defines mechanisms which provide an asynchronous | This document defines mechanisms which provide an asynchronous | |||
message notification delivery service for the [NETCONF] protocol. | message notification delivery service for the [NETCONF] protocol. | |||
This is an optional capability built on top of the base NETCONF | This is an optional capability built on top of the base NETCONF | |||
definition. This memo defines the capabilities, operations, | definition. This memo defines the capabilities and operations | |||
transport mappings, and data models necessary to support this | necessary to support this service. | |||
service. | ||||
Figure 1 | Figure 1 | |||
1.1. Definition of Terms | 1.1. Definition of Terms | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Element: An [XML] Element. | Element: An [XML] Element. | |||
skipping to change at page 5, line 26 | skipping to change at page 5, line 26 | |||
notification or event notification, being sent out to interested | notification or event notification, being sent out to interested | |||
parties to notify them that this event has occurred. | parties to notify them that this event has occurred. | |||
This memo defines a mechanism whereby the NETCONF client indicates | This memo defines a mechanism whereby the NETCONF client indicates | |||
interest in receiving event notifications from a NETCONF server by | interest in receiving event notifications from a NETCONF server by | |||
creating a subscription to receive event notifications. The NETCONF | creating a subscription to receive event notifications. The NETCONF | |||
server replies to indicate whether the subscription request was | server replies to indicate whether the subscription request was | |||
successful and, if it was successful, begins sending the event | successful and, if it was successful, begins sending the event | |||
notifications to the NETCONF client as the events occur within the | notifications to the NETCONF client as the events occur within the | |||
system. These event notifications will continue to be sent until | system. These event notifications will continue to be sent until | |||
either the NETCONF session is terminated or some event, outside the | either the NETCONF session is terminated or the subscription to | |||
scope of this specification, causes the subscription to terminate. | terminate for some other reason. The event notification subscription | |||
The event notification subscription allows a number of options to | allows a number of options to enable the NETCONF client to specify | |||
enable the NETCONF client to specify which events are of interest. | which events are of interest. These are specified when the | |||
These are specified when the subscription is created. | subscription is created. | |||
An NETCONF server is not required to process RPC requests on the | An NETCONF server is not required to process RPC requests on the | |||
session associated with the subscription until the notification | session associated with the subscription until the notification | |||
stream is done. A capability may be advertised to announce that a | subscription is done. A capability may be advertised to announce | |||
server is able to process RPCs while a notification stream is active | that a server is able to process RPCs while a notification stream is | |||
on a session. | active on a session. | |||
1.3. Motivation | 1.3. Motivation | |||
The motivation for this work is to enable the sending of asynchronous | The motivation for this work is to enable the sending of asynchronous | |||
messages that are consistent with the data model (content) and | messages that are consistent with the data model (content) and | |||
security model used within a Netconf implementation. | security model used within a NETCONF implementation. | |||
1.4. Requirements | 1.4. Requirements | |||
The following requirements have been addressed by the solution: | The following requirements have been addressed by the solution: | |||
o Initial release should ensure it supports notification in support | o Initial release should ensure it supports notification in support | |||
of configuration operations | of configuration operations | |||
o Data content must not preclude the use of the same data model as | o Data content must not preclude the use of the same data model as | |||
used in configuration | used in configuration | |||
o solution should support a reasonable message size limit (syslog | o solution should support a reasonable message size limit (syslog | |||
and SNMP are rather constrained in terms of message sizes) | and SNMP are rather constrained in terms of message sizes) | |||
o solution should provide reliable delivery of notifications | o solution should provide reliable delivery of notifications | |||
o solution should provide a subscription mechanism (A NETCONF server | o solution should provide a subscription mechanism (A NETCONF server | |||
does not send notifications before asked to do so and the NETCONF | does not send notifications before being asked to do so and the | |||
client initiates the flow of notifications) | NETCONF client initiates the flow of notifications) | |||
o solution should provide a filtering mechanism within the Netconf | o solution should provide a filtering mechanism within the NETCONF | |||
server | server | |||
o solution should send sufficient information in a notification so | o solution should send sufficient information in a notification so | |||
that it can be analyzed independent of the transport mechanism | that it can be analyzed independent of the transport mechanism | |||
(data content fully describes a notification; protocol information | (data content fully describes a notification; protocol information | |||
is not needed to understand a notification) | is not needed to understand a notification) | |||
o solution should support replay of locally logged notifications | o solution should support replay of locally logged notifications | |||
2. Notification-Related Operations | 2. Notification-Related Operations | |||
skipping to change at page 7, line 23 | skipping to change at page 7, line 23 | |||
Content for an event notification subscription can be selected by | Content for an event notification subscription can be selected by | |||
applying user-specified filters. | applying user-specified filters. | |||
2.1.1. <create-subscription> | 2.1.1. <create-subscription> | |||
Description: | Description: | |||
This operation initiates an event notification subscription which | This operation initiates an event notification subscription which | |||
will send asynchronous event notifications to the initiator of the | will send asynchronous event notifications to the initiator of the | |||
command until the NETCONF session terminates or some event, | command until the subscription to terminates. | |||
outside the scope of this specification, causes the subscription | ||||
to terminate. | ||||
Parameters: | Parameters: | |||
Streams: | Stream: | |||
An optional parameter that indicates which stream(s) of events | An optional parameter that indicates which stream of events is | |||
are of interest. If not present, then events in the default | of interest. If not present, then events in the default | |||
NETCONF stream will be sent. | NETCONF stream will be sent. | |||
Filter: | Filter: | |||
An optional parameter that indicates which subset of all | An optional parameter that indicates which subset of all | |||
possible events are of interest. The format of this parameter | possible events are of interest. The format of this parameter | |||
is the same as that of the filter parameter in the NETCONF | is the same as that of the filter parameter in the NETCONF | |||
protocol operations. If not present, all events not precluded | protocol operations. If not present, all events not precluded | |||
by other parameters will be sent. | by other parameters will be sent. This is mutually exclusive | |||
with the named profile parameter. | ||||
Named Profile: | Named Profile: | |||
An optional parameter that points to a separately defined | An optional parameter that points to a separately defined | |||
filter profile. The contents of the profile are specified in | filter profile. If not present, no additional filtering will | |||
the provided [XML Schema]. If not present, no additional | be applied. Note that changes to the profile after the | |||
filtering will be applied. Note that changes to the profile | subscription has been created will have no effect. This is | |||
after the subscription has been created will have no effect. | mutually exclusive with the filter parameter | |||
Start Time: | Start Time: | |||
A parameter used with the optional replay capability to signals | A parameter used to trigger the replay feature and indicates | |||
that this is a replay subscription and that the replay should | that the replay should start at the time specified. If start | |||
start at the time specified. If start time is not present, | time is not present, this is not a replay subscription. | |||
this is not a replay subscription. Stop time for replay is | ||||
implicitly defined to be the time the create-subscription | Stop Time: | |||
command was received by the Netconf server. | ||||
An optional parameter used with the optional replay feature to | ||||
indicate the newest notifications of interest. If stop time is | ||||
not present, the notifications will continue until the | ||||
subscription is terminated. Must be used with 'startTime'. | ||||
Positive Response: | Positive Response: | |||
If the NETCONF server can satisfy the request, the server sends an | If the NETCONF server can satisfy the request, the server sends an | |||
<ok> element. | <ok> element. | |||
Negative Response: | Negative Response: | |||
An <rpc-error> element is included within the <rpc-reply> if the | An <rpc-error> element is included within the <rpc-reply> if the | |||
request cannot be completed for any reason. Subscription requests | request cannot be completed for any reason. Subscription requests | |||
will fail if a filter with invalid syntax is provided or if the | will fail if a filter with invalid syntax is provided or if the | |||
name of a non-existent profile or stream is provided. | name of a non-existent profile or stream is provided. | |||
2.1.2. Filter Dependencies | ||||
When multiple filters are specified (in-line Filter, Named Profiles), | ||||
they are applied collectively (i.e. logical AND operation). That is, | ||||
event notifications must pass all specified filters in order to be | ||||
sent to the subscriber. | ||||
2.2. Sending Event Notifications | 2.2. Sending Event Notifications | |||
Once the subscription has been set up, the NETCONF server sends the | Once the subscription has been set up, the NETCONF server sends the | |||
event notifications asynchronously along the connection. | event notifications asynchronously along the connection. | |||
2.2.1. <notification> | 2.2.1. <notification> | |||
Description: | Description: | |||
An event notification is sent to the initiator of a <create- | An event notification is sent to the initiator of a <create- | |||
skipping to change at page 9, line 15 | skipping to change at page 9, line 13 | |||
Data: | Data: | |||
Contains notification-specific tagged content. | Contains notification-specific tagged content. | |||
Response: | Response: | |||
No response. Not applicable. | No response. Not applicable. | |||
2.3. Terminating the Subscription | 2.3. Terminating the Subscription | |||
Closing of the event notification subscription is done by terminating | Closing of the event notification subscription can be done by | |||
the Netconf session ( <kill-session> )or via some action outside the | terminating the NETCONF session ( <kill-session> ). | |||
scope of this specification. | ||||
3. Supporting Concepts | 3. Supporting Concepts | |||
3.1. Capabilities Exchange | 3.1. Capabilities Exchange | |||
The ability to process and send event notifications is advertised | The ability to process and send event notifications is advertised | |||
during the capability exchange between the NETCONF client and server. | during the capability exchange between the NETCONF client and server. | |||
"urn:ietf:params:xml:ns:netconf:capability:notification:1.0" | 3.1.1. Capability Identifier | |||
For Example | "urn:ietf:params:netconf:capability:notification:1.0" | |||
3.1.2. Capability Example | ||||
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | |||
<capabilities> | <capabilities> | |||
<capability> | <capability> | |||
urn:ietf:params:xml:ns:netconf:base:1.0 | urn:ietf:params:xml:ns:netconf:base:1.0 | |||
</capability> | </capability> | |||
<capability> | <capability> | |||
urn:ietf:params:xml:ns:netconf:capability:startup:1.0 | urn:ietf:params:netconf:capability:startup:1.0 | |||
</capability> | </capability> | |||
<capability> | <capability> | |||
urn:ietf:params:xml:ns:netconf:capability:notification:1.0 | urn:ietf:params:netconf:capability:notification:1.0 | |||
</capability> | </capability> | |||
</capabilities> | </capabilities> | |||
<session-id>4</session-id> | <session-id>4</session-id> | |||
</hello> | </hello> | |||
3.2. Event Streams | 3.2. Event Streams | |||
An event stream is defined herein as a set of event notifications | An event stream is defined herein as a set of event notifications | |||
matching some forwarding criteria. | matching some forwarding criteria. | |||
skipping to change at page 12, line 22 | skipping to change at page 12, line 22 | |||
3.2.5. Event Stream Discovery | 3.2.5. Event Stream Discovery | |||
A NETCONF client retrieves the list of supported event streams from a | A NETCONF client retrieves the list of supported event streams from a | |||
NETCONF server using the <get> RPC request. | NETCONF server using the <get> RPC request. | |||
3.2.5.1. Name Retrieval using <get> operation | 3.2.5.1. Name Retrieval using <get> operation | |||
The list of available event streams is retrieved by requesting the | The list of available event streams is retrieved by requesting the | |||
<eventStreams> subtree via a <get>operation. Available event streams | <eventStreams> subtree via a <get>operation. Available event streams | |||
for the requesting session are returned in the reply containing | for the requesting session are returned in the reply containing the | |||
<name> and <description> elements, where <name> element is mandatory | <name> and <description> elements, where <name> element is mandatory | |||
and its value is unique [Editor's Note: should we then define it as a | and its value is unique. The returned list must only include the | |||
key?]. The returned list must only include the names of those event | names of those event streams for which the NETCONF session has | |||
streams for which the NETCONF sessions has sufficient privileges. | sufficient privileges. The NETCONF session privileges are determined | |||
The NETCONF session privileges are determined via access control | via access control mechanisms which are beyond the scope of this | |||
mechanisms which are beyond the scope of this document. An empty | document. An empty reply is returned if there are no available event | |||
reply is returned if there are no available event streams. | streams. | |||
Retrieving available event stream list using <get> operation: | The list of all event streams configured on a device may be retrieved | |||
over a NETCONF session with sufficient privileges (e.g. | ||||
administrator). The information is retrieved by requesting the | ||||
<eventStreams> subtree via a <get> operation. | ||||
Example: Retrieving available event stream list using <get> | ||||
operation: | ||||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | |||
<get> | <get> | |||
<filter type="subtree"> | <filter type="subtree"> | |||
<top xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"> | <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"/> | |||
<eventStreams/> | ||||
</top> | ||||
</filter> | </filter> | |||
</get> | </get> | |||
</rpc> | </rpc> | |||
The NETCONF server returns a list of event streams available for | ||||
subscription: NETCONF, snmp, and syslog-critical in this example. | ||||
<rpc-reply message-id="101" | <rpc-reply message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | |||
<data> | <data> | |||
<top ="urn:ietf:params:xml:ns:netmod:base:1.0"> | <eventStreams xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"> | |||
<eventStreams> | ||||
<stream> | <stream> | |||
<name>NETCONF</name> | <name>NETCONF</name> | |||
<description>Default netconf event stream | <description>Default netconf event stream | |||
</description> | </description> | |||
<replaySupport>true</replaySupport> | ||||
</stream> | </stream> | |||
<stream> | <stream> | |||
<name>snmp</name> | <name>snmp</name> | |||
<description>SNMP notifications</description> | <description>SNMP notifications</description> | |||
<replaySupport>false</replaySupport> | ||||
</stream> | </stream> | |||
<stream> | <stream> | |||
<name>syslog-critical</name> | <name>syslog-critical</name> | |||
<description>Critical and higher severity | <description>Critical and higher severity | |||
</description> | </description> | |||
<replaySupport>true</replaySupport> | ||||
</stream> | </stream> | |||
</eventStreams> | </eventStreams> | |||
</top> | ||||
</data> | </data> | |||
</rpc-reply> | </rpc-reply> | |||
3.2.5.2. Device Supported Event Streams (System) | 3.2.5.2. Stream Retrieval Schema | |||
The list of all event streams configured on a device may be retrieved | ||||
over a NETCONF session with sufficient privileges (e.g. | ||||
administrator). The information is retrieved by requesting the | ||||
<eventStreams> subtree via a <get> operation. | ||||
3.2.5.3. Stream Retrieval Schema | ||||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | |||
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
elementFormDefault="qualified" | elementFormDefault="qualified" | |||
attributeFormDefault="unqualified"> | attributeFormDefault="unqualified"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
Schema for event streams | Schema for event streams | |||
</xs:documentation> | </xs:documentation> | |||
skipping to change at page 14, line 49 | skipping to change at page 14, line 31 | |||
<xs:element name="eventStreams"> | <xs:element name="eventStreams"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
The list of event streams supported by the system. | The list of event streams supported by the system. | |||
When a query is issued, the returned set of streams is | When a query is issued, the returned set of streams is | |||
determined based on user privileges | determined based on user privileges | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence maxOccurs="unbounded"> | <xs:sequence minOccurs="0" maxOccurs="unbounded"> | |||
<xs:element name="stream"> | <xs:element name="stream"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
Stream name and description | Stream name and description | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="name" type="xs:string"/> | <xs:element name="name" type="xs:string"/> | |||
<xs:element name="description" type="xs:string"/> | <xs:element name="description" type="xs:string"/> | |||
<xs:element name="replaySupport" type="xs:boolean"/> | ||||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
</xs:schema> | </xs:schema> | |||
3.2.6. Event Stream Subscription | 3.2.6. Event Stream Subscription | |||
skipping to change at page 15, line 38 | skipping to change at page 15, line 21 | |||
in subscription to the default NETCONF event stream. | in subscription to the default NETCONF event stream. | |||
3.2.6.1. Filtering Event Stream Contents | 3.2.6.1. Filtering Event Stream Contents | |||
The set of event notifications delivered in an event stream may be | The set of event notifications delivered in an event stream may be | |||
further refined by applying a user-specified filter at subscription | further refined by applying a user-specified filter at subscription | |||
creation time ( <create-subscription> ). This is a transient filter | creation time ( <create-subscription> ). This is a transient filter | |||
associated with the event notification subscription and does not | associated with the event notification subscription and does not | |||
modify the event stream configuration. | modify the event stream configuration. | |||
3.2.6.2. Subscription to Multiple Event Streams | ||||
Multiple event streams may be configured on a device and a NETCONF | ||||
client may subscribe to one or more of the available event streams. | ||||
3.3. Subscriptions not Configuration Data | 3.3. Subscriptions not Configuration Data | |||
While it is possible to retrieve information about subscriptions via | While it is possible to retrieve information about subscriptions via | |||
a get operation, subscriptions are not stored configuration. They | a get operation, subscriptions are not stored configuration. They | |||
are non-persistent state information. In this respect, they are | are non-persistent state information. In this respect, they are | |||
comparable to NETCONF sessions. | comparable to NETCONF sessions. | |||
Named profiles, if used, are considered configuration data. | Named profiles, if used, are considered configuration data. | |||
3.4. Querying Subscription Properties | 3.4. Filter Dependencies | |||
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-09-13T09: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: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: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 > | ||||
<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="streams" | ||||
type="ncEvent:StreamsList" minOccurs="0"> | ||||
<xs:annotation> | ||||
<xs:documentation xml:lang="en"> | ||||
A list of event streams associated with this | ||||
subscription. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</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 ref="nsub:associatedNamedProfile" | ||||
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: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:unsignedInt" 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="key"> | ||||
<xs:key name="uniqueSubscription"> | ||||
<xs:selector xpath=".//subscription"/> | ||||
<xs:field xpath="session-id"/> | ||||
</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="streams" | ||||
type="ncEvent:streamsList" minOccurs="0"> | ||||
<xs:annotation> | ||||
<xs:documentation xml:lang="en"> | ||||
The event streams associated with this named | ||||
profile. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</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: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. Filter Dependencies | ||||
Note that when multiple filters are specified (in-line Filter, Named | Note that when multiple filters are specified, they are applied | |||
Profiles), they are applied collectively, so event notifications need | collectively, so event notifications need to pass all specified | |||
to pass all specified filters in order to be sent to the subscriber. | filters in order to be sent to the subscriber. If a filter is | |||
If a filter is specified to look for data of a particular value, and | specified to look for data of a particular value, and the data item | |||
the data item is not present within a particular event notification | is not present within a particular event notification for its value | |||
for its value to be checked against, it will be filtered out. For | to be checked against, it will be filtered out. For example, if one | |||
example, if one were to check for 'severity=critical' in a | were to check for 'severity=critical' in a configuration event | |||
configuration event notification where this field was not supported, | notification where this field was not supported, then the | |||
then the notification would be filtered out. | notification would be filtered out. | |||
Note that the order that filters are applied does not matter since | Note that the order that filters are applied does not matter since | |||
the resulting set of notifications is the intersection of the set of | the resulting set of notifications is the intersection of the set of | |||
notifications that pass each filtering criteria. | notifications that pass each filtering criteria. | |||
3.5.1. Named Profiles | 3.4.1. Named Profiles | |||
A named profile is a filter that is created ahead of time and applied | A named profile is a filter that is created ahead of time and applied | |||
at the time an event notification subscription is created . Note | at the time an event notification subscription is created . Note | |||
that changes to the profile after the subscription has been created | that changes to the profile after the subscription has been created | |||
will have no effect on the subscription. Since named profiles exist | will have no effect on the subscription. Since named profiles exist | |||
outside of the subscription, they persist after the subscription has | outside of the subscription, they persist after the subscription has | |||
been torn down. | been torn down. | |||
3.5.2. Filtering | 3.4.2. Filtering | |||
Just-in-time filtering is explicitly stated when the event | Just-in-time filtering is explicitly stated when the event | |||
notification subscription is created. This is specified via the | notification subscription is created. This is specified via the | |||
Filter parameter. Filters only exist as parameters to the | 'filter' parameter. Filters only exist as parameters to the | |||
subscription. | subscription. | |||
3.6. Message Flow | 3.5. Message Flow | |||
The following figure depicts message flow between a Netconf client | ||||
(C) and Netconf server (S) in order create a subscription and begin | The following figure depicts message flow between a NETCONF client | |||
(C) and NETCONF server (S) in order create a subscription and begin | ||||
the flow of notifications. | the flow of notifications. | |||
C S | C S | |||
| | | | | | |||
| capability exchange | | | capability exchange | | |||
|-------------------------->| | |-------------------------->| | |||
|<------------------------->| | |<------------------------->| | |||
| | | | | | |||
| <create-subscription> | | | <create-subscription> | | |||
|-------------------------->| | |-------------------------->| | |||
skipping to change at page 23, line 32 | skipping to change at page 17, line 32 | |||
This import accesses the xml: attribute groups for the | This import accesses the xml: attribute groups for the | |||
xml:lang as declared on the error-message element. | xml:lang as declared on the error-message element. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:import> | </xs:import> | |||
<!-- import base netconf definitions --> | <!-- import base netconf definitions --> | |||
<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" | <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" /> | schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" /> | |||
<!-- ******************** Type definitions ***********************--> | ||||
<xs:complexType name="StreamsList"> | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
A list of event streams. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
<xs:sequence> | ||||
<xs:element name="stream" maxOccurs="unbounded"/> | ||||
</xs:sequence> | ||||
</xs:complexType> | ||||
<!-- ************** Symmetrical Operations ********************--> | <!-- ************** Symmetrical Operations ********************--> | |||
<!-- <create-subscription> operation --> | <!-- <create-subscription> operation --> | |||
<xs:complexType name="createSubscriptionType"> | <xs:complexType name="createSubscriptionType"> | |||
<xs:complexContent> | <xs:complexContent> | |||
<xs:extension base="netconf:rpcOperationType"> | <xs:extension base="netconf:rpcOperationType"> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="streams" | <xs:element name="stream" | |||
type="StreamsList" minOccurs="0"/> | type="xs:string" minOccurs="0"> | |||
<xs:annotation> | ||||
<xs:documentation> | ||||
An optional parameter that indicates which stream | ||||
of events is of interest. If not present, then | ||||
events in the default NETCONF stream will be sent. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
<xs:choice> | ||||
<xs:element name="filter" | <xs:element name="filter" | |||
type="netconf:filterInlineType" minOccurs="0"/> | type="netconf:filterInlineType" minOccurs="0"> | |||
<xs:annotation> | ||||
<xs:documentation> | ||||
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. This is mutually exclusive | ||||
with the named profile parameter. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
<xs:element name="named-profile" | <xs:element name="named-profile" | |||
type="xs:string" minOccurs="0"/> | type="xs:string" minOccurs="0"> | |||
<xs:annotation> | ||||
<xs:documentation> | ||||
An optional parameter that points to a separately | ||||
defined filter profile. 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. This is mutually | ||||
exclusive with the filter parameter | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
</xs:choice> | ||||
<xs:element name="startTime" type="xs:dateTime" | <xs:element name="startTime" type="xs:dateTime" | |||
minOccurs="0" /> | minOccurs="0" > | |||
<xs:annotation> | ||||
<xs:documentation> | ||||
A parameter used to trigger the replay feature | ||||
and indicates that the replay should start at the | ||||
time specified. If start time is not present, this | ||||
is not a replay subscription. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
<xs:element name="stopTime" type="xs:dateTime" | ||||
minOccurs="0" > | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
An optional parameter used with the optional replay | ||||
feature to indicate the newest notifications of | ||||
interest. If stop time is not present, the | ||||
notifications will continue until the subscription | ||||
is terminated. Must be used with 'startTime'. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
</xs:sequence> | </xs:sequence> | |||
</xs:extension> | </xs:extension> | |||
</xs:complexContent> | </xs:complexContent> | |||
</xs:complexType> | </xs:complexType> | |||
<xs:element name="create-subscription" | <xs:element name="create-subscription" | |||
type="createSubscriptionType" | type="createSubscriptionType" | |||
substitutionGroup="netconf:rpcOperation"/> | substitutionGroup="netconf:rpcOperation"> | |||
<xs:annotation> | ||||
<xs:documentation> | ||||
The command to create a notification subscription. It | ||||
takes as argument the name of the notification stream and | ||||
filter or profile information. All of those options limit | ||||
the content of the subscription. In addition, there are | ||||
two time-related parameters startTime and stopTime which | ||||
can be used to select the time interval of interest. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
<!-- ************** One-way Operations ******************--> | <!-- ************** One-way Operations ******************--> | |||
<!-- <Event> operation --> | <!-- <Notification> operation --> | |||
<xs:complexType name="NotificationType"> | <xs:complexType name="NotificationType"> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="data" type="netconf:dataInlineType" /> | <xs:element name="data" type="netconf:dataInlineType" /> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
<xs:element name="notification" type="NotificationType"/> | <xs:element name="notification" type="NotificationType"/> | |||
</xs:schema> | </xs:schema> | |||
5. Mapping to Transport Protocols | 5. Filtering examples | |||
Currently, the NETCONF family of specification allows for running | ||||
NETCONF over a number of transport protocols, some of which support | ||||
multiple configurations. Some of these options will be better suited | ||||
for supporting event notifications then others. | ||||
5.1. SSH | ||||
Session establishment and two-way messages are based on the NETCONF | ||||
over SSH transport mapping [NETCONF SSH] | ||||
One-way event messages are supported as follows: Once the session has | ||||
been established and capabilities have been exchanged, the server may | ||||
send complete XML documents to the NETCONF client containing | ||||
notification elements. No response is expected from the NETCONF | ||||
client. | ||||
As the examples in [NETCONF SSH] illustrate, a special character | ||||
sequence, MUST be sent by both the client and the server after each | ||||
XML document in the NETCONF exchange. This character sequence cannot | ||||
legally appear in an XML document, so it can be unambiguously used to | ||||
identify the end of the current document in the event notification of | ||||
an XML syntax or parsing error, allowing resynchronization of the | ||||
NETCONF exchange. | ||||
The NETCONF over SSH session to receive an event notification might | ||||
look like the following. In the example below the event notification | ||||
contents (delimited by <data> </data> tags) are not defined in this | ||||
document and are provided herein simply for illustration purposes. | ||||
The sample notification shows a configuration change on the running | ||||
configuration as a result of an <edit-config> operation. It has one | ||||
containment node ( <interfaces> ), with one element <interface> and | ||||
two changed attributes (<name> and <mtu>) (Note that this does not | ||||
refer to XML attributes). The same example is used in the BEEP and | ||||
SOAP transport mapping sections. | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<notification | ||||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | ||||
<data xmlns="http://example.com/event/1.0"> | ||||
<severity>notice</severity> | ||||
<eventClasses><configuration/><audit/></eventClasses> | ||||
<sequenceNumber>2</sequenceNumber> | ||||
<dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | ||||
<user>Fred Flinstone</user> | ||||
<operation> | ||||
<edit-config> | ||||
<target> | ||||
<running/> | ||||
</target> | ||||
<edit-config> | ||||
<top xmlns="http://example.com/schema/1.2/config"> | ||||
<interfaces> | ||||
<interface> | ||||
<name>Ethernet0/0</name> | ||||
<mtu>1500</mtu> | ||||
</interface> | ||||
</interfaces> | ||||
</top> | ||||
</config> | ||||
</edit-config> | ||||
</operation> | ||||
</data> | ||||
</event> | ||||
</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 in Beep | ||||
One-way notification messages can be supported either by mapping to | ||||
the existing 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 the One-to-many Construct | ||||
Messages in one-to-many exchanges: "rpc", "notification", "rpc-reply" | ||||
Messages in positive replies: "rpc-reply" | ||||
5.2.1.2. One-way notification messages via the One-to-none Construct | ||||
Note that this construct would need to be added to an extension or | ||||
update to 'The Blocks Extensible Exchange Protocol Core' [RFC3080]. | ||||
MSG/NoANS: the client sends a "MSG" message, the server, sends no | ||||
reply. | ||||
In one-to-none exchanges, no reply to the "MSG" message is expected. | ||||
5.3. SOAP | ||||
Session management and message exchange are based on the NETCONF over | ||||
SOAP transport mapping [NETCONF SOAP] | ||||
Note that the use of "persistent connections" "chunked transfer- | ||||
coding" when using HTTP becomes even more important in the supporting | ||||
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: </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: <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: <interfaces> | ||||
<interface> | ||||
S: <name>Ethernet0/0</name> | ||||
S: <mtu>1500</mtu> | ||||
</interface> | ||||
S: </interfaces> | ||||
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 the various | The following section provides examples to illustrate the various | |||
methods of filtering content on an event notification subscription. | methods of filtering content on an event notification subscription. | |||
6.1. Subtree Filtering | 5.1. Subtree Filtering | |||
XML subtree filtering is not well suited for creating elaborate | XML subtree filtering is not well suited for creating elaborate | |||
filter definitions given that it only supports equality comparisons | filter definitions given that it only supports equality comparisons | |||
and logical OR operations (e.g. in an event subtree give me all event | and logical OR operations (e.g. in an event subtree give me all event | |||
notifications which have severity=critical or severity=major or | notifications which have severity=critical or severity=major or | |||
severity=minor). Nevertheless, it may be used for defining simple | severity=minor). Nevertheless, it may be used for defining simple | |||
event notification forwarding filters as shown below. | event notification forwarding filters as shown below. | |||
In order to illustrate the use of filter expressions it is necessary | In order to illustrate the use of filter expressions it is necessary | |||
to assume some of the event notification content (only for example | to assume some of the event notification content. The examples | |||
purposes). The examples herein assume that the event notification | herein assume that the event notification schema definition has an | |||
schema definition has an <eventClasses> element identifying the event | <eventClasses> element identifying the event category (e.g. fault, | |||
category (e.g. fault, state, config, etc.) and events have a | state, config, etc.) and events have a <severity> element. | |||
<severity> element | ||||
The following example illustrates selecting events which have | The following example illustrates selecting events which have | |||
severities of critical, major, or minor (presumably fault events). | severities of critical, major, or minor (presumably fault events). | |||
The filtering criteria evaluation is as follows: | The filtering criteria evaluation is as follows: | |||
((severity=critical) | (severity=major) | (severity=minor)) | ((severity=critical) | (severity=major) | (severity=minor)) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription | <create-subscription | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<filter type="subtree"> | <netconf:filter type="subtree"> | |||
<event xmlns="http://example.com/event/1.0"> | <event xmlns="http://example.com/event/1.0"> | |||
<severity>critical</severity> | <severity>critical</severity> | |||
</event> | </event> | |||
<event xmlns="http://example.com/event/1.0"> | <event xmlns="http://example.com/event/1.0"> | |||
<severity>major</severity> | <severity>major</severity> | |||
</event> | </event> | |||
<event xmlns="http://example.com/event/1.0"> | <event xmlns="http://example.com/event/1.0"> | |||
<severity>minor</severity> | <severity>minor</severity> | |||
</event> | </event> | |||
</netconf:filter> | </netconf:filter> | |||
skipping to change at page 31, line 14 | skipping to change at page 21, line 13 | |||
The following example illustrates selecting fault, state, config | The following example illustrates selecting fault, state, config | |||
EventClasses or events which are related to card Ethernet0. The | EventClasses or events which are related to card Ethernet0. The | |||
filtering criteria evaluation is as follows: | filtering criteria evaluation is as follows: | |||
(fault | state | config | card=Ethernet0) | (fault | state | config | card=Ethernet0) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<netconf:filter type="subtree"> | <netconf:filter type="subtree"> | |||
<top | ||||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<eventClasses>fault</eventClasses> | <eventClasses>fault</eventClasses> | |||
</event> | </event> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<eventClasses>state</eventClasses> | <eventClasses>state</eventClasses> | |||
</event> | </event> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<eventClasses>config</eventClasses> | <eventClasses>config</eventClasses> | |||
</event> | </event> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<card>Ethernet0</card> | <card>Ethernet0</card> | |||
</event> | </event> | |||
</top> | ||||
</netconf:filter> | </netconf:filter> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
6.2. XPATH filters | 5.2. XPATH filters | |||
The following example illustrates selecting fault EventClass | The following example illustrates selecting fault EventClass | |||
notifications that have severities of critical, major, or minor. The | notifications that have severities of critical, major, or minor. In | |||
filtering criteria evaluation is as follows: | this example, neb represents the namespace for the event definitions | |||
schema. The filtering criteria evaluation is as follows: | ||||
((fault) & ((severity=critical) | (severity=major) | (severity = | ((fault) & ((severity=critical) | (severity=major) | (severity = | |||
minor))) | minor))) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<netconf:filter type="xpath"> | <netconf:filter type="xpath" | |||
(/event[eventClasses/fault] and | select="/neb:event/eventClasses/fault' and | |||
(/event[severity="critical"] or | (/neb:event[severity='critical'] or | |||
/event[severity="major"] or /event[severity="minor"])) | /neb:event[severity='major'] or | |||
</netconf:filter> | /neb:event[severity='minor')))"/> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
The following example illustrates selecting fault, state and config | The following example illustrates selecting fault, state and config | |||
EventClasses which have severities of critical, major, or minor and | EventClasses which have severities of critical, major, or minor and | |||
come from card Ethernet0. The filtering criteria evaluation is as | come from card Ethernet0. The filtering criteria evaluation is as | |||
follows: | follows: | |||
((fault | state | config) & ((fault & severity=critical) | (fault & | ((fault | state | config) & ((fault & severity=critical) | (fault & | |||
severity=major) | (fault & severity = minor) | (card=Ethernet0))) | severity=major) | (fault & severity = minor) | (card=Ethernet0))) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<netconf:filter type="xpath"> | <netconf:filter type="xpath" | |||
((/event[eventClasses/fault] or | select="((/neb:event[eventClasses/fault] or | |||
/event[eventClasses/state] or | /neb:event[eventClasses/state] or | |||
/event[eventClasses/config]) and | /neb:event[eventClasses/config]) and | |||
( (/event[eventClasses/fault] and | ( (/neb:event[eventClasses/fault] and | |||
/event[severity="critical"]) or | /neb:event[severity='critical']) or | |||
(/event[eventClasses/fault] and | (/neb:event[eventClasses/fault] and | |||
/event[severity="major"]) or | /neb:event[severity='major']) or | |||
(/event[eventClasses/fault] and | (/neb:event[eventClasses/fault] and | |||
/event[severity="minor"]) or | /neb:event[severity='minor']) or | |||
/event[card="Ethernet0"])) | /neb:event[card='Ethernet0']))"/> | |||
</netconf:filter> | ||||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
7. Notification Replay Capability | 6. Notification Replay | |||
7.1. Overview | 6.1. Overview | |||
Replay is the ability to create an event subscription that will | Replay is the ability to create an event subscription that will | |||
resend recently sent notifications. These notifications are sent the | resend recently sent notifications. These notifications are sent the | |||
same way as normal notifications. | same way as normal notifications. | |||
A replay of notifications is specified by including an optional | A replay of notifications is specified by including an optional | |||
parameter to the subscription command that indicates the start time | parameter to the subscription command that indicates the start time | |||
of the replay. The end time of the replay is implicitly defined to | of the replay. The end time is specified using the optional stopTime | |||
be the time the replay request was initiated. | parameter. If not present, notifications will continue to be sent | |||
until the subscription is terminated. | ||||
An implementation that supports replay is not expected to have an | A notification stream that supports replay is not expected to have an | |||
unlimited supply of saved notifications available to accommodate any | unlimited supply of saved notifications available to accommodate any | |||
replay request. If a client requests a replay of notifications that | replay request. If a client requests a replay of notifications that | |||
predate the oldest notification available, then the NETCONF server | predate the oldest notification available, then the NETCONF server | |||
must return a warning message in the RPC reply and start replaying | must return a warning message in the RPC reply and start replaying | |||
the notifications it does have available, within the other | the notifications it does have available, within the other | |||
constraints, such as filtering, that the client has provided. The | constraints, such as filtering, that the client has provided. The | |||
warning message enables the NETCONF client to differentiate between | warning message enables the NETCONF client to differentiate between | |||
the case that there were no notifications generated within a given | the case that there were no notifications generated within a given | |||
time period from the case that no notifications are currently in the | time period from the case that no notifications are currently in the | |||
log from that period. | log from that period. | |||
The actual number of stored notifications available for retrieval at | The actual number of stored notifications available for retrieval at | |||
any given time is an NETCONF server implementation specific matter. | any given time is an NETCONF server implementation specific matter. | |||
Control parameters for this aspect of the feature are outside the | Control parameters for this aspect of the feature are outside the | |||
scope of the current work. | scope of the current work. | |||
A given subscription is either a replay subscription or a normal | This feature is dependent on a notification stream supporting some | |||
subscription, which sends event notifications as they happen. A | form of notification logging, although it puts no restrictions on the | |||
replay subscription terminates once the it has completed replaying | size or form of the log, nor where it resides within the device. | |||
past events. | ||||
7.2. Dependencies | ||||
This capability is dependent on the notification capability being | ||||
supported. It also requires that the device supporting the Netconf | ||||
server also support some form of notification logging, although it | ||||
puts no restrictions on the size or form of the log, nor where it | ||||
resides within the device. | ||||
7.3. Capability Identifier | ||||
The Event 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 | 6.2. Creating a Subscription with Replay | |||
This capability adds an optional parameter to the <create- | This feature uses optional parameters to the <create-subscription> | |||
subscription> command called 'startTime'. This identifies the | command called 'startTime' and 'stopTime'. 'startTime' identifies the | |||
earliest date and time of interest for event notifications being | earliest date and time of interest for event notifications being | |||
replayed. Events generated before this time are not matched. | replayed and also indicates that a subscription will be providing | |||
replay of notifications. Events generated before this time are not | ||||
matched. 'stopTime' specifies the latest date and time of interest | ||||
for event notifications being replayed. If it is not present, then | ||||
notifications will continue to be sent until the subscription is | ||||
terminated. | ||||
Note that while a notification has three potential times associated | Note that while a notification has three potential times associated | |||
it - the time it was generated, the time it was logged and the time | it - the time it was generated, the time it was logged and the time | |||
it was sent out by the NETCONF server - the startTime parameter is | it was sent out by the NETCONF server - the startTime and stopTime | |||
related to generation time. | parameters are related to generation time. | |||
Negative Response: | Negative Response: | |||
An <rpc-error> element is included in the <rpc-reply> if the | An <rpc-error> element is included in the <rpc-reply> if the | |||
startTime in replay request predates the oldest notification | startTime in replay request predates the oldest notification | |||
available to be replayed. | available to be replayed or if the stopTime is earlier then the | |||
startTime. | ||||
Error-tag: start-time-value | Error-tag: start-time-too-early | |||
Error-type: protocol | Error-type: protocol | |||
Error-severity: warning | Error-severity: warning | |||
Error-info: none | Error-info: none | |||
Error-message: Start time predates oldest available | Error-message: Start time predates oldest available | |||
notification to be replayed | notification to be replayed | |||
7.5.2. Interactions with Other Capabilities | Error-tag: start-stop-time-mismatch | |||
[Edtitor's Note: If this capability does not interact with other | Error-type: protocol | |||
capabilities, this section may be omitted.] | ||||
7.6. Replay Complete Notification | Error-severity: warning | |||
Error-info: none | ||||
Error-message: stopTime predates startTime. | ||||
6.3. Replay Complete Notification | ||||
The following notification is the last notification sent over a | The following notification is the last notification sent over a | |||
replay subscription. It indicates that replay is complete. | replay subscription. It indicates that replay is complete. This | |||
notification will only be sent if a 'stopTime' was specified when the | ||||
replay subscription was created. | ||||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | |||
xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0" | |||
targetNamespace= | targetNamespace= | |||
"urn:ietf:params:xml:ns:netconf:replayNotification:1.0"> | "urn:ietf:params:xml:ns:netconf:replayNotification:1.0"> | |||
<xs:element name="replayCompleteNotification" > | <xs:element name="replayCompleteNotification" > | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
skipping to change at page 36, line 5 | skipping to change at page 26, line 5 | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="timeGenerated" type="xs:dateTime"/> | <xs:element name="timeGenerated" type="xs:dateTime"/> | |||
<xs:element name="numberEventsReplayed" type="xs:integer"/> | <xs:element name="numberEventsReplayed" type="xs:integer"/> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
</xs:schema> | </xs:schema> | |||
8. Security Considerations | 7. Security Considerations | |||
The security considerations from the base [NETCONF] document apply | ||||
also to the Notification capability. | ||||
The access control framework and the choice of transport will have a | The access control framework and the choice of transport will have a | |||
major impact on the security of the solution. | major impact on the security of the solution. | |||
Note that the <notification> elements are never sent before the | Note that the <notification> elements are never sent before the | |||
transport layer and the netconf layer (capabilities exchange) have | transport layer and the netconf layer (capabilities exchange) have | |||
been established, and the manager has been identified and | been established, and the manager has been identified and | |||
authenticated. | authenticated. | |||
It is recommended that care be taken to ensure the secure operation | It is recommended that care be taken to ensure the secure operation | |||
skipping to change at page 37, line 5 | skipping to change at page 27, line 5 | |||
o notification content | o notification content | |||
One issue related to the notifications draft is the transport of data | One issue related to the notifications draft is the transport of data | |||
from non-netconf streams, such as syslog and SNMP. Note that this | from non-netconf streams, such as syslog and SNMP. Note that this | |||
data may be more vulnerable (or is not more vulnerable) when being | data may be more vulnerable (or is not more vulnerable) when being | |||
transported over netconf than when being transported using the | transported over netconf than when being transported using the | |||
protocol normally used for transporting it, depending on the security | protocol normally used for transporting it, depending on the security | |||
credentials of the two subsystems. | credentials of the two subsystems. | |||
9. Acknowledgements | 8. Acknowledgements | |||
Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing | Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing | |||
their input into the early work on this document. In addition, the | their input into the early work on this document. In addition, the | |||
editors would like to acknowledge input at the Vancouver editing | editors would like to acknowledge input at the Vancouver editing | |||
session from the following people: Orly Nicklass, James Balestriere, | session from the following people: Orly Nicklass, James Balestriere, | |||
Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, | Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, | |||
Dave Partain, Ray Atarashi and Dave Perkins and the following | Dave Partain, Ray Atarashi and Dave Perkins and the following | |||
additional people from the Montreal editing session: Balazs Lengyel, | additional people from the Montreal editing session: Balazs Lengyel, | |||
Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, | Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, | |||
Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, | Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, | |||
Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William | Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William | |||
Chow | Chow | |||
10. Normative References | 9. Normative References | |||
[NETCONF] Enns, R., "NETCONF Configuration Protocol", | [NETCONF] Enns, R., "NETCONF Configuration Protocol", | |||
ID draft-ietf-netconf-prot-12, February 2006. | 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) Over the Simple Object Access Protocol (SOAP)", | ||||
ID draft-ietf-netconf-soap-08, March 2006. | ||||
[NETCONF SSH] | ||||
Wasserman, M. and T. Goddard, "Using the NETCONF | ||||
Configuration Protocol over Secure Shell (SSH)", | ||||
ID draft-ietf-netconf-ssh-06.txt, March 2006. | ||||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
3", RFC 2026, BCP 9, October 1996. | 3", RFC 2026, BCP 9, October 1996. | |||
[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements | [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements | |||
Levels", RFC 2119, March 1997. | Levels", RFC 2119, March 1997. | |||
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", | [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", | |||
RFC 2223, October 1997. | RFC 2223, October 1997. | |||
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", | ||||
RFC 3080, March 2001. | ||||
[XML] World Wide Web Consortium, "Extensible Markup Language | [XML] World Wide Web Consortium, "Extensible Markup Language | |||
(XML) 1.0", W3C XML, February 1998, | (XML) 1.0", W3C XML, February 1998, | |||
<http://www.w3.org/TR/1998/REC-xml-19980210>. | <http://www.w3.org/TR/1998/REC-xml-19980210>. | |||
[XML Schema] | [XML Schema] | |||
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer | Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer | |||
Second Edition", W3C XML Schema, October 2004. | Second Edition", W3C XML Schema, October 2004. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 87 change blocks. | ||||
665 lines changed or deleted | 253 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |