draft-ietf-netconf-notification-03.txt | draft-ietf-netconf-notification-04.txt | |||
---|---|---|---|---|
Network Working Group S. Chisholm | Network Working Group S. Chisholm | |||
Internet-Draft Nortel | Internet-Draft Nortel | |||
Expires: March 18, 2007 H. Trevino | Intended status: Standards Track H. Trevino | |||
Cisco | Expires: April 25, 2007 Cisco | |||
September 14, 2006 | October 22, 2006 | |||
NETCONF Event Notifications | NETCONF Event Notifications | |||
draft-ietf-netconf-notification-03.txt | draft-ietf-netconf-notification-04.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 March 18, 2007. | This Internet-Draft will expire on April 25, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This memo defines a framework for sending asynchronous messages, or | This document defines mechanisms which provide an asynchronous | |||
event notifications in NETCONF. It defines both the operations | message notification delivery service for the NETCONF protocol. This | |||
necessary to support this concept, and also discusses implications | is an optional capability built on top of the base NETCONF | |||
for the mapping to transport protocols. | definition. This document defines the capabilities, operations, | |||
transport mappings, and data models necessary to support this | ||||
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.2 Sending Event Notifications . . . . . . . . . . . . . . . 8 | 2.1.2. Filter Dependencies . . . . . . . . . . . . . . . . . 8 | |||
2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 8 | 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 8 | |||
2.3 Terminating the Subscription . . . . . . . . . . . . . . . 9 | 2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 8 | |||
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.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 . . . . . . . . . . . . . . 17 | 3.2.6. Event Stream Subscription . . . . . . . . . . . . . . 15 | |||
3.3 Subscriptions and Datastores . . . . . . . . . . . . . . . 17 | 3.3. Subscriptions not Configuration Data . . . . . . . . . . . 15 | |||
3.4 Querying Subscription Properties . . . . . . . . . . . . . 18 | 3.4. Querying Subscription Properties . . . . . . . . . . . . . 16 | |||
3.5 One-way Notification Messages . . . . . . . . . . . . . . 22 | 3.5. Filter Dependencies . . . . . . . . . . . . . . . . . . . 20 | |||
3.6 Filter Dependencies . . . . . . . . . . . . . . . . . . . 22 | 3.5.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 21 | |||
3.6.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 23 | 3.5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.6.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 23 | 3.6. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.7 Message Flow . . . . . . . . . . . . . . . . . . . . . . . 23 | 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 23 | |||
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 25 | 5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 25 | |||
5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 27 | 5.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 5.2. BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 5.2.1. One-way Notification Messages in Beep . . . . . . . . 26 | |||
5.2.1 One-way Notification Messages in Beep . . . . . . . . 28 | 5.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 5.3.1. A NETCONF over Soap over HTTP Example . . . . . . . . 27 | |||
5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 29 | 6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 30 | |||
6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 32 | 6.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 30 | |||
6.1 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 32 | 6.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 31 | |||
6.2 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 33 | 7. Notification Replay Capability . . . . . . . . . . . . . . . . 33 | |||
7. Notification Replay Capability . . . . . . . . . . . . . . . . 35 | 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 7.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
7.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . 35 | 7.3. Capability Identifier . . . . . . . . . . . . . . . . . . 33 | |||
7.3 Capability Identifier . . . . . . . . . . . . . . . . . . 35 | 7.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 34 | |||
7.4 New Operations . . . . . . . . . . . . . . . . . . . . . . 35 | 7.5. Modifications to Existing Operations . . . . . . . . . . . 34 | |||
7.5 Modifications to Existing Operations . . . . . . . . . . . 36 | 7.5.1. create-subscription . . . . . . . . . . . . . . . . . 34 | |||
7.5.1 create-subscription . . . . . . . . . . . . . . . . . 36 | 7.5.2. Interactions with Other Capabilities . . . . . . . . . 34 | |||
7.5.2 Interactions with Other Capabilities . . . . . . . . . 36 | 7.6. Replay Complete Notification . . . . . . . . . . . . . . . 34 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 10. Normative References . . . . . . . . . . . . . . . . . . . . . 38 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
Intellectual Property and Copyright Statements . . . . . . . . 40 | Intellectual Property and Copyright Statements . . . . . . . . . . 40 | |||
1. Introduction | 1. Introduction | |||
NETCONF [NETCONF-PROTO] can be conceptually partitioned into four | [NETCONF] can be conceptually partitioned into four layers: | |||
layers: | ||||
Layer Example | Layer Example | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
| Content | | Configuration data | | | Content | | Configuration data | | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
| | | | | | |||
+-------------+ +-------------------------------------------+ | +-------------+ +-------------------------------------------+ | |||
| Operations | | <get-config>, <edit-config> <notification>| | | Operations | | <get-config>, <edit-config> <notification>| | |||
+-------------+ +-------------------------------------------+ | +-------------+ +-------------------------------------------+ | |||
| | | | | | | | |||
+-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | | |||
| RPC | | <rpc>, <rpc-reply> | | | | RPC | | <rpc>, <rpc-reply> | | | |||
+-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | | |||
| | | | | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
| Transport | | BEEP, SSH, SSL, console | | | Transport | | BEEP, SSH, SSL, console | | |||
| Protocol | | | | | Protocol | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
This document defines a framework for sending asynchronous messages, | This document defines mechanisms which provide an asynchronous | |||
or event notifications in NETCONF. It defines both the operations | message notification delivery service for the [NETCONF] protocol. | |||
necessary to support this concept, and also discusses implications | This is an optional capability built on top of the base NETCONF | |||
for the mapping to transport protocols. | definition. This memo defines the capabilities, operations, | |||
transport mappings, and data models necessary to support this | ||||
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 RFC 2119 [3]. | document are to be interpreted as described in [RFC2119]. | |||
Element: An XML Element[XML]. | ||||
Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has | Element: An [XML] Element. | |||
access to management instrumentation. This is also known as the | ||||
NETCONF server. | ||||
Managed Object: A collection of one of more Elements that define an | Managed Object: A collection of one of more Elements that define an | |||
abstract thing of interest. | abstract thing of interest. | |||
Subscription: A concept related to the delivery of notifications (if | Subscription: A concept related to the delivery of notifications (if | |||
any to send) involving destination and selection of notifications. | any to send) involving destination and selection of notifications. | |||
It is bound to the lifetime of a session. | It is bound to the lifetime of a session. | |||
1.2 Event Notifications in NETCONF | Operation: This term is used to refer to NETCONF protocol | |||
operations. Specifically within this document, operation refers | ||||
to NETCONF protocol operations defined in support of NETCONF | ||||
notifications. | ||||
1.2. Event Notifications in NETCONF | ||||
An event is something that happens which may be of interest - a | An event is something that happens which may be of interest - a | |||
configuration change, a fault, a change in status, crossing a | configuration change, a fault, a change in status, crossing a | |||
threshold, or an external input to the system, for example. Often | threshold, or an external input to the system, for example. Often | |||
this results in an asynchronous message, sometimes referred to as a | this results in an asynchronous message, sometimes referred to as a | |||
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 | |||
skipping to change at page 5, line 31 | skipping to change at page 5, line 32 | |||
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 some event, outside the | |||
scope of this specification, causes the subscription to terminate. | scope of this specification, causes the subscription to terminate. | |||
The event notification subscription allows a number of options to | The event notification subscription allows a number of options to | |||
enable the NETCONF client to specify which events are of interest. | enable the NETCONF client to specify which events are of interest. | |||
These are specified when the subscription is created. | These are specified when the subscription is created. | |||
An agent is not required to process RPC requests until the | An NETCONF server is not required to process RPC requests on the | |||
notification stream is done. A capability may be defined to announce | session associated with the subscription until the notification | |||
that a server is able to process RPCs while a notification stream is | stream is done. A capability may be advertised to announce that a | |||
active on a session. | server is able to process RPCs while a notification stream is 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 requirements for this solution are as follows: | 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 support agent initiated connections | o solution should provide a subscription mechanism (A NETCONF server | |||
does not send notifications before asked to do so and the NETCONF | ||||
o solution should provide a subscription mechanism (An agent does | client initiates the flow of notifications) | |||
not send notifications before asked to do so and the manager | ||||
initiates the flow of notifications) | ||||
o solution should provide a filtering mechanism | o solution should provide a filtering mechanism within the Netconf | |||
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 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 replay of locally logged notifications | |||
2. Notification-Related Operations | 2. Notification-Related Operations | |||
2.1 Subscribing to receive Event Notifications | 2.1. Subscribing to receive Event Notifications | |||
The event notification subscription is initiated by the NETCONF | The event notification subscription is initiated by the NETCONF | |||
client and responded to by the NETCONF server. When the event | client and responded to by the NETCONF server. When the event | |||
notification subscription is created, the events of interest are | notification subscription is created, the events of interest are | |||
specified. | specified. | |||
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> | |||
<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 NETCONF session terminates or some event, | |||
outside the scope of this specification, causes the subscription | outside the scope of this specification, causes the subscription | |||
to terminate. | to terminate. | |||
Parameters: | Parameters: | |||
Stream: | Streams: | |||
An optional parameter that indicates which stream(s) of events | An optional parameter that indicates which stream(s) of events | |||
are of interest. If not present, then events in the default | are 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. | |||
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. The contents of the profile are specified in | |||
the provided XML Schema. If not present, no additional | the provided [XML Schema]. If not present, no additional | |||
filtering will be applied. Note that changes to the profile | filtering will be applied. Note that changes to the profile | |||
after the subscription has been created will have no effect. | after the subscription has been created will have no effect. | |||
Start Time: | ||||
A parameter used with the optional replay capability to signals | ||||
that this is a replay subscription and that the replay should | ||||
start at the time specified. If start time is not present, | ||||
this is not a replay subscription. Stop time for replay is | ||||
implicitly defined to be the time the create-subscription | ||||
command was received by the Netconf server. | ||||
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 | |||
<rpc-reply> element containing a <data> element containing the | <ok> element. | |||
subscription ID. | ||||
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.2 Sending Event Notifications | 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 | ||||
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 Event Notification | 2.2.1. <notification> | |||
<notification> | ||||
Description: | Description: | |||
An event notification is sent to the initiator of an <create- | An event notification is sent to the initiator of a <create- | |||
subscription> command asynchronously when an event of interest | subscription> command asynchronously when an event of interest | |||
(i.e. meeting the specified filtering criteria) to them has | (i.e. meeting the specified filtering criteria) to them has | |||
occurred. An event notification is a complete XML document. | occurred. An event notification is a complete XML document. Note | |||
that <notification> is not an RPC method but rather the top level | ||||
element identifying the one way message as a notification. | ||||
Parameters: | Parameters: | |||
Subscription Id: | ||||
A unique identifier for this event subscription | ||||
Data: | Data: | |||
Contains notification-specific tagged content. | Contains notification-specific tagged content. | |||
Positive Response: | Response: | |||
No response. | ||||
Negative Response: | ||||
No response. | 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 is done by terminating | |||
the Netconf session ( <kill-session> )or via some action outside the | the Netconf session ( <kill-session> )or via some action outside the | |||
scope of this specification. | 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:notification:1.0" | "urn:ietf:params:xml:ns:netconf:capability:notification:1.0" | |||
For Example | For 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:xml:ns:netconf:capability:startup:1.0 | |||
</capability> | </capability> | |||
<capability> | <capability> | |||
urn:ietf:params:xml:ns:netconf:notification:1.0 | urn:ietf:params:xml:ns: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. | |||
System components generate event notifications which are passed to a | System components generate event notifications which are passed to a | |||
central component for classification and distribution. The central | central component for classification and distribution. The central | |||
component inspects each event notification and matches the event | component inspects each event notification and matches the event | |||
notification against the set of stream definitions. When a match | notification against the set of stream definitions. When a match | |||
occurs, the event notification is considered to be a member of that | occurs, the event notification is considered to be a member of that | |||
event stream. An event notification may be part of multiple event | event stream. An event notification may be part of multiple event | |||
skipping to change at page 11, line 26 | skipping to change at page 11, line 26 | |||
| cn |---+ | (notification) | | cn |---+ | (notification) | |||
+----+ +-----> ( logging ) | +----+ +-----> ( logging ) | |||
( service ) | ( service ) | |||
(------------) | (------------) | |||
+-------+ +-------+ | +-------+ +-------+ | |||
|netconf|<--->|netconf| | |netconf|<--->|netconf| | |||
-> |server | |client | | -> |server | |client | | |||
+-------+ +-------+ | +-------+ +-------+ | |||
3.2.1 Event Stream Definition | 3.2.1. Event Stream Definition | |||
Event streams are pre-defined on the managed device. The | Event streams are predefined on the managed device. The | |||
configuration of event streams is outside the scope of this document. | configuration of event streams is outside the scope of this document. | |||
However, it is envisioned that event streams are either pre- | However, it is envisioned that event streams are either pre- | |||
established by the vendor (pre-configured) or user configurable (e.g. | established by the vendor (pre-configured) or user configurable (e.g. | |||
part of the device's configuration) or both. Device vendors may | part of the device's configuration) or both. Device vendors may | |||
allow event stream configuration via NETCONF protocol (i.e. edit- | allow event stream configuration via NETCONF protocol (i.e. edit- | |||
config operation) | config operation) | |||
3.2.2 Event Stream Content Format | 3.2.2. Event Stream Content Format | |||
The contents of all event streams made available to a NETCONF client | The contents of all event streams made available to a NETCONF client | |||
(i.e. the notification sent by the NETCONF server) must be encoded in | (i.e. the notification sent by the NETCONF server) must be encoded in | |||
XML. | XML. | |||
3.2.3 Default Event Stream | 3.2.3. Default Event Stream | |||
A NETCONF server implementation supporting the notification | A NETCONF server implementation supporting the notification | |||
capability must support the "NETCONF" notification event stream. | capability must support the "NETCONF" notification event stream. | |||
This stream contains all NETCONF XML event notifications supported by | This stream contains all NETCONF XML event notifications supported by | |||
the NETCONF server. The definition of the event notification and | the NETCONF server. The definition of the event notification and | |||
their contents for this event stream is outside the scope of this | their contents for this event stream is outside the scope of this | |||
document. | document. | |||
3.2.4 Event Stream Sources | 3.2.4. Event Stream Sources | |||
With the exception of the default event stream (NETCONF | With the exception of the default event stream (NETCONF | |||
notifications) specification of additional event stream sources (e.g. | notifications) specification of additional event stream sources (e.g. | |||
SNMP, syslog, etc.) is outside the scope of this document. NETCONF | SNMP, syslog, etc.) is outside the scope of this document. NETCONF | |||
server implementations may leverage any desired event stream source | server implementations may leverage any desired event stream source | |||
in the creation of supported event streams. | in the creation of supported event streams. | |||
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> or <get-config> RPC request. | NETCONF server using the <get> RPC request. | |||
3.2.5.1 Name Retrieval using get, get-config RPC | 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> or <get-config> operation. | <eventStreams> subtree via a <get>operation. Available event streams | |||
Available event streams for the requesting session are returned in | for the requesting session are returned in the reply containing | |||
the reply containing <name> and <description> elements, where | <name> and <description> elements, where <name> element is mandatory | |||
<name> element is mandatory and its value is unique [Editor's Note: | and its value is unique [Editor's Note: should we then define it as a | |||
should we then define it as a key?]. The returned list must only | key?]. The returned list must only include the names of those event | |||
include the names of those event streams for which the NETCONF | streams for which the NETCONF sessions has sufficient privileges. | |||
sessions has sufficient privileges. The NETCONF session privileges | The NETCONF session privileges are determined via access control | |||
are determined via access control mechanisms which are beyond the | mechanisms which are beyond the scope of this document. An empty | |||
scope of this document. An empty reply is returned if there are no | reply is returned if there are no available event streams. | |||
available event streams. | ||||
Retrieving available event stream list using <get-config> operation: | ||||
<get-config> | Retrieving available event stream list using <get> operation: | |||
<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" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> | 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> | <get> | |||
<filter type="subtree"> | <filter type="subtree"> | |||
<top xmlns="http://example.com/schema/1.2/config"> | <top xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"> | |||
<sessionEventStreams> | ||||
<eventStreams/> | <eventStreams/> | |||
</sessionEventStreams> | ||||
</top> | </top> | |||
</filter> | </filter> | |||
</get> | </get> | |||
</rpc> | </rpc> | |||
<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 xmlns="http://example.com/schema/1.2/config"> | <top ="urn:ietf:params:xml:ns:netmod:base:1.0"> | |||
<sessionEventStreams> | ||||
<eventStreams> | <eventStreams> | |||
<stream> | <stream> | |||
<name>NETCONF</name> | <name>NETCONF</name> | |||
<description>Default netconf event stream | <description>Default netconf event stream | |||
</description> | </description> | |||
</stream> | </stream> | |||
<stream> | <stream> | |||
<name>snmp</name> | <name>snmp</name> | |||
<description>SNMP notifications</description> | <description>SNMP notifications</description> | |||
</stream> | </stream> | |||
<stream> | <stream> | |||
<name>syslog-critical</name> | <name>syslog-critical</name> | |||
<description>Critical and higher severity | <description>Critical and higher severity | |||
</description> | </description> | |||
</stream> | </stream> | |||
</eventStreams> | </eventStreams> | |||
</sessionEventStreams> | ||||
</top> | </top> | |||
</data> | </data> | |||
</rpc-reply> | </rpc-reply> | |||
3.2.5.2 Device Supported Event Streams (System) | 3.2.5.2. Device Supported Event Streams (System) | |||
The list of all event streams configured on a device may be retrieved | The list of all event streams configured on a device may be retrieved | |||
over a NETCONF session with sufficient privileges (e.g. | over a NETCONF session with sufficient privileges (e.g. | |||
administrator). The information is retrieved by requesting the | administrator). The information is retrieved by requesting the | |||
<systemEventStreams> subtree via a <get> or <get-config> | <eventStreams> subtree via a <get> operation. | |||
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" | 3.2.5.3. Stream Retrieval Schema | |||
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"?> | <?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> | |||
<xs:appinfo> | <xs:appinfo> | |||
skipping to change at page 16, line 26 | skipping to change at page 14, line 29 | |||
<nm:Name> | <nm:Name> | |||
NetconfNotificationSchema | NetconfNotificationSchema | |||
</nm:Name> | </nm:Name> | |||
<nm:LastUpdated> | <nm:LastUpdated> | |||
2006-09-06T09:30:47-05:00 | 2006-09-06T09:30:47-05:00 | |||
</nm:LastUpdated> | </nm:LastUpdated> | |||
<nm:Organization>IETF | <nm:Organization>IETF | |||
</nm:Organization> | </nm:Organization> | |||
<nm:Description> | <nm:Description> | |||
A schema that can be used to learn about current | A schema that can be used to learn about current | |||
NetConf Event subscriptions and creating named | event streams. | |||
profiles | ||||
</nm:Description> | </nm:Description> | |||
</nm:identity> | </nm:identity> | |||
</xs:appinfo> | </xs:appinfo> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:import namespace="http://www.w3.org/XML/1998/namespace" | <xs:import namespace="http://www.w3.org/XML/1998/namespace" | |||
schemaLocation="http://www.w3.org/2001/xml.xsd"/> | schemaLocation="http://www.w3.org/2001/xml.xsd"/> | |||
<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="./draft-ietf-netconf-prot-12.xsd"/> | schemaLocation="./draft-ietf-netconf-prot-12.xsd"/> | |||
<xs:element name="sessionEventStreams"> | <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 maxOccurs="unbounded"> | |||
<xs:element name="stream"> | <xs:element name="stream"> | |||
skipping to change at page 17, line 20 | skipping to change at page 15, line 22 | |||
<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: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 | |||
A NETCONF client may request from the NETCONF server the list of | A NETCONF client may request from the NETCONF server the list of | |||
available event streams to this session and then issue a <create- | available event streams to this session and then issue a <create- | |||
subscription> request with the desired event stream name. Omitting | subscription> request with the desired event stream name. Omitting | |||
the event stream name from the <create-subscription> request results | the event stream name from the <create-subscription> request results | |||
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 | 3.2.6.2. Subscription to Multiple Event Streams | |||
Multiple event streams may be configured on a device and a NETCONF | Multiple event streams may be configured on a device and a NETCONF | |||
client may subscribe to one or more of the available event streams. | client may subscribe to one or more of the available event streams. | |||
A NETCONF client subscribing to multiple event streams must do so by | ||||
either establishing a new NETCONF session or opening a new channel on | ||||
an existing NETCONF session. | ||||
3.3 Subscriptions and Datastores | 3.3. Subscriptions not Configuration Data | |||
Subscriptions are like NETCONF sessions in that they don't exist in | While it is possible to retrieve information about subscriptions via | |||
NETCONF datastores. The exception to this is the named profiles | a get operation, subscriptions are not stored configuration. They | |||
feature. | are non-persistent state information. In this respect, they are | |||
comparable to NETCONF sessions. | ||||
3.4 Querying Subscription Properties | Named profiles, if used, are considered configuration data. | |||
3.4. Querying Subscription Properties | ||||
The following Schema can be used to retrieve information about active | The following Schema can be used to retrieve information about active | |||
event notification subscriptions | event notification subscriptions | |||
<xs:schema | <xs:schema | |||
xmlns:xs="http://www.w3.org/2001/XMLSchema" | xmlns:xs="http://www.w3.org/2001/XMLSchema" | |||
xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0" | xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0" | |||
targetNamespace="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: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" | |||
skipping to change at page 18, line 34 | skipping to change at page 16, line 32 | |||
</xs:documentation> | </xs:documentation> | |||
<xs:appinfo> | <xs:appinfo> | |||
<nm:identity | <nm:identity | |||
xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"> | xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"> | |||
<nm:Name>NetconfNotificationSchema</nm:Name> | <nm:Name>NetconfNotificationSchema</nm:Name> | |||
<nm:LastUpdated>2006-09-13T09:30:47-05:00 | <nm:LastUpdated>2006-09-13T09:30:47-05:00 | |||
</nm:LastUpdated> | </nm:LastUpdated> | |||
<nm:Organization>IETF</nm:Organization> | <nm:Organization>IETF</nm:Organization> | |||
<nm:Description> | <nm:Description> | |||
A schema that can be used to learn about current | A schema that can be used to learn about current | |||
NetConf Event subscriptions and creating named | NETCONF Event subscriptions and creating named | |||
profiles | profiles | |||
</nm:Description> | </nm:Description> | |||
</nm:identity> | </nm:identity> | |||
</xs:appinfo> | </xs:appinfo> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:import namespace="http://www.w3.org/XML/1998/namespace" | <xs:import namespace="http://www.w3.org/XML/1998/namespace" | |||
schemaLocation="http://www.w3.org/2001/xml.xsd"/> | schemaLocation="http://www.w3.org/2001/xml.xsd"/> | |||
<xs:import | <xs:import | |||
namespace="urn:ietf:params:xml:ns:netconf:notification:1.0" | namespace="urn:ietf:params:xml:ns:netconf:notification:1.0" | |||
schemaLocation= | schemaLocation= | |||
"urn:ietf:params:xml:ns:netconf:notification:1.0"/> | "urn:ietf:params:xml:ns:netconf:notification:1.0"/> | |||
<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"/> | |||
<!-- Associations --> | <!-- Associations --> | |||
<xs:element name="associatedNamedProfile" type="xs:string"/> | ||||
<xs:element name="associatedNamedProfile" type="xs:string"/> | ||||
<xs:element name="relationships"> | <xs:element name="relationships"> | |||
<xs:keyref name="subscriptionToNamedProfile" | <xs:keyref name="subscriptionToNamedProfile" | |||
refer="nsub:namedProfileKey"> | refer="nsub:namedProfileKey"> | |||
<xs:selector xpath=".//netconfSubscription"/> | <xs:selector xpath=".//netconfSubscription"/> | |||
<xs:field xpath="nsub:associatedNamedProfile"/> | <xs:field xpath="nsub:associatedNamedProfile"/> | |||
</xs:keyref> | </xs:keyref> | |||
<!-- Keys --> | <!-- Keys --> | |||
<xs:key name="namedProfileKey"> | <xs:key name="namedProfileKey"> | |||
skipping to change at page 19, line 35 | skipping to change at page 17, line 33 | |||
<nm:maxAccess><read/></nm:maxAccess> | <nm:maxAccess><read/></nm:maxAccess> | |||
</xs:appinfo> | </xs:appinfo> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence > | <xs:sequence > | |||
<xs:element name="session-id" | <xs:element name="session-id" | |||
type="netconf:SessionId" > | type="netconf:SessionId" > | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The session id associated with this subscription. | The session id associated with this | |||
subscription. | ||||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="subscriptionID" | <xs:element name="streams" | |||
type="ncEvent:SubscriptionID" > | type="ncEvent:StreamsList" minOccurs="0"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The subscription id associated with this | A list of event streams associated with this | |||
subscription. | subscription. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="filter" | <xs:element name="filter" | |||
type="netconf:filterInlineType" minOccurs="0"> | type="netconf:filterInlineType" minOccurs="0"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The filters associated with this subscription. | The filters associated with this subscription. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element ref="nsub:associatedNamedProfile" minOccurs="0"> | <xs:element ref="nsub:associatedNamedProfile" | |||
minOccurs="0"> | ||||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The named profile associated with this subscription. | The named profile associated with this | |||
Note that the contents of the named profile may | subscription. Note that the contents of the | |||
have changed since it was last applied. | named profile may have changed since it was | |||
last applied. | ||||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="lastModified" | <xs:element name="lastModified" | |||
type="xs:dateTime" > | type="xs:dateTime" > | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The last time this subscription was modified. If it | The last time this subscription was modified. If | |||
has not been modified since creation, this is the | it has not been modified since creation, this is | |||
time of subscription creation. | the time of subscription creation. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="messagesSent" | <xs:element name="messagesSent" | |||
type="xs:integer" minOccurs="0"> | type="xs:unsignedInt" minOccurs="0"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
A count of event notifications sent along | A count of event notifications sent along | |||
this connection since the subscription was | this connection since the subscription was | |||
created. | created. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="key"> | <xs:element name="key"> | |||
<xs:key name="uniqueSubscription"> | <xs:key name="uniqueSubscription"> | |||
<xs:selector xpath=".//subscription"/> | <xs:selector xpath=".//subscription"/> | |||
<xs:field xpath="session-id"/> | <xs:field xpath="session-id"/> | |||
<xs:field xpath="subscriptionID"/> | ||||
</xs:key> | </xs:key> | |||
</xs:element> | </xs:element> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
<xs:element name="netconfSubscriptions"> | <xs:element name="netconfSubscriptions"> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element ref="nsub:netconfSubscription" | <xs:element ref="nsub:netconfSubscription" | |||
skipping to change at page 21, line 27 | skipping to change at page 19, line 28 | |||
<xs:element name="namedProfile"> | <xs:element name="namedProfile"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:appinfo> | <xs:appinfo> | |||
<nm:minAccess><read/></nm:minAccess> | <nm:minAccess><read/></nm:minAccess> | |||
<nm:maxAccess><read/> <write/> <create/> <delete/> | <nm:maxAccess><read/> <write/> <create/> <delete/> | |||
</nm:maxAccess> | </nm:maxAccess> | |||
</xs:appinfo> | </xs:appinfo> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="name"/> | <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" | <xs:element name="filter" | |||
type="netconf:filterInlineType" minOccurs="0"> | type="netconf:filterInlineType" minOccurs="0"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The filters associated with this named | The filters associated with this named | |||
profile. | profile. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
<xs:element name="lastModified" type="xs:dateTime"> | <xs:element name="lastModified" type="xs:dateTime"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
The timestamp of the last modification to this | The timestamp of the last modification to this | |||
named Profile. Note that modification of the | named Profile. Note that modification of the | |||
profile does not cause an immediate update | profile does not cause an immediate update | |||
to all applicable subscription. Therefore, this | to all applicable subscription. Therefore, | |||
time should be compared with the last | this time should be compared with the last | |||
modified time associated with the subscription. | modified time associated with the | |||
If this time is earlier, then the subscription | subscription. If this time is earlier, then | |||
is using the exact set of parameters associated | the subscription is using the exact set of | |||
with this named profile. If this time is | parameters associated with this named profile. | |||
later, then the subscription is using an earlier | If this time is later, then the subscription | |||
version of this named profile and the exact | is using an earlier version of this named | |||
parameters may not match. | profile and the exact parameters may not | |||
match. | ||||
</xs:documentation> | </xs:documentation> | |||
<xs:appinfo> | <xs:appinfo> | |||
<nm:minAccess><read/></nm:minAccess> | <nm:minAccess><read/></nm:minAccess> | |||
<nm:maxAccess><read/> </nm:maxAccess> | <nm:maxAccess><read/> </nm:maxAccess> | |||
</xs:appinfo> | </xs:appinfo> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
skipping to change at page 22, line 27 | skipping to change at page 20, line 41 | |||
<xs:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element ref="nsub:namedProfile" minOccurs="0" | <xs:element ref="nsub:namedProfile" minOccurs="0" | |||
maxOccurs="unbounded" /> | maxOccurs="unbounded" /> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:complexType> | </xs:complexType> | |||
</xs:element> | </xs:element> | |||
</xs:schema> | </xs:schema> | |||
3.5 One-way Notification Messages | 3.5. Filter Dependencies | |||
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.6 Filter Dependencies | ||||
Note that when multiple filters are specified (in-line Filter, Named | Note that when multiple filters are specified (in-line Filter, Named | |||
Profiles), they are applied collectively, so event notifications need | Profiles), they are applied collectively, so event notifications need | |||
to pass all specified filters in order to be sent to the subscriber. | 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 | 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 | the data item is not present within a particular event notification | |||
for its value to be checked against, it will be filtered out. For | for its value to be checked against, it will be filtered out. For | |||
example, if one were to check for 'severity=critical' in a | example, if one were to check for 'severity=critical' in a | |||
configuration event notification where this field was not supported, | configuration event notification where this field was not supported, | |||
then the notification would be filtered out. | then the 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.6.1 Named Profiles | 3.5.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.6.2 Filtering | 3.5.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.7 Message Flow | 3.6. Message Flow | |||
The following figure depicts message flow between a Netconf client | The following figure depicts message flow between a Netconf client | |||
(C) and Netconf server (S) in order create a subscription and begin | (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 | | |||
|-------------------------->| | |-------------------------->| | |||
|<------------------------->| | |<------------------------->| | |||
| | | | | | |||
skipping to change at page 25, line 15 | skipping to change at page 23, line 15 | |||
4. XML Schema for Event Notifications | 4. XML Schema for Event Notifications | |||
<?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:notification:1.0" | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" | |||
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" | xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" | |||
targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0" | targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0" | |||
elementFormDefault="qualified" | elementFormDefault="qualified" | |||
attributeFormDefault="unqualified" | attributeFormDefault="unqualified" | |||
xml:lang="en"> | xml:lang="en"> | |||
<!-- | ||||
import standard XML definitions | <!-- import standard XML definitions --> | |||
--> | ||||
<xs:import namespace="http://www.w3.org/XML/1998/namespace" | <xs:import namespace="http://www.w3.org/XML/1998/namespace" | |||
schemaLocation="http://www.w3.org/2001/xml.xsd"> | schemaLocation="http://www.w3.org/2001/xml.xsd"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
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 ***********************--> | <!-- ******************** Type definitions ***********************--> | |||
<xs:simpleType name="SubscriptionID"> | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
The unique identifier for this particular subscription within | ||||
the session. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
<xs:restriction base="xs:string"/> | ||||
</xs:simpleType> | ||||
<xs:simpleType name="SequenceNumber"> | <xs:complexType name="StreamsList"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
A monotonically increasing integer. Starts at 0. | A list of event streams. | |||
Always increases by just one. Roll back to 0 after maximum | ||||
value is reached. | ||||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:restriction base="xs:integer"/> | <xs:sequence> | |||
</xs:simpleType> | <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> | <xs:element name="streams" | |||
type="StreamsList" minOccurs="0"/> | ||||
<xs:element name="filter" | <xs:element name="filter" | |||
type="netconf:filterInlineType" minOccurs="0"/> | type="netconf:filterInlineType" minOccurs="0"/> | |||
<xs:element name="named-profile" | <xs:element name="named-profile" | |||
type="xs:string" minOccurs="0"/> | type="xs:string" minOccurs="0"/> | |||
<xs:element name="startTime" type="xs:dateTime" | <xs:element name="startTime" type="xs:dateTime" | |||
minOccurs="0" /> | minOccurs="0" /> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:extension> | </xs:extension> | |||
</xs:complexContent> | </xs:complexContent> | |||
</xs:complexType> | </xs:complexType> | |||
skipping to change at page 26, line 28 | skipping to change at page 24, line 19 | |||
<xs:element name="filter" | <xs:element name="filter" | |||
type="netconf:filterInlineType" minOccurs="0"/> | type="netconf:filterInlineType" minOccurs="0"/> | |||
<xs:element name="named-profile" | <xs:element name="named-profile" | |||
type="xs:string" minOccurs="0"/> | type="xs:string" minOccurs="0"/> | |||
<xs:element name="startTime" type="xs:dateTime" | <xs:element name="startTime" type="xs:dateTime" | |||
minOccurs="0" /> | minOccurs="0" /> | |||
</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"/> | |||
<!-- ************** One-way Operations ******************--> | <!-- ************** One-way Operations ******************--> | |||
<!-- | <!-- <Event> operation --> | |||
<Event> operation | ||||
--> | ||||
<xs:complexType name="NotificationType"> | <xs:complexType name="NotificationType"> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="subscriptionId" type="SubscriptionID" /> | <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. Mapping to Transport Protocols | |||
Currently, the NETCONF family of specification allows for running | Currently, the NETCONF family of specification allows for running | |||
NETCONF over a number of transport protocols, some of which support | NETCONF over a number of transport protocols, some of which support | |||
multiple configurations. Some of these options will be better suited | multiple configurations. Some of these options will be better suited | |||
for supporting event notifications then others. | for supporting event notifications then others. | |||
skipping to change at page 27, line 12 | skipping to change at page 25, line 12 | |||
</xs:schema> | </xs:schema> | |||
5. Mapping to Transport Protocols | 5. Mapping to Transport Protocols | |||
Currently, the NETCONF family of specification allows for running | Currently, the NETCONF family of specification allows for running | |||
NETCONF over a number of transport protocols, some of which support | NETCONF over a number of transport protocols, some of which support | |||
multiple configurations. Some of these options will be better suited | multiple configurations. Some of these options will be better suited | |||
for supporting event notifications then others. | for supporting event notifications then others. | |||
5.1 SSH | 5.1. SSH | |||
Session establishment and two-way messages are based on the NETCONF | Session establishment and two-way messages are based on the NETCONF | |||
over SSH transport mapping [NETCONF-SSH] | over SSH transport mapping [NETCONF SSH] | |||
One-way event messages are supported as follows: Once the session has | One-way event messages are supported as follows: Once the session has | |||
been established and capabilities have been exchanged, the server may | been established and capabilities have been exchanged, the server may | |||
send complete XML documents to the NETCONF client containing | send complete XML documents to the NETCONF client containing | |||
notification elements. No response is expected from the NETCONF | notification elements. No response is expected from the NETCONF | |||
client. | client. | |||
As the examples in [NETCONF-SSH] illustrate, a special character | As the examples in [NETCONF SSH] illustrate, a special character | |||
sequence, MUST be sent by both the client and the server after each | sequence, MUST be sent by both the client and the server after each | |||
XML document in the NETCONF exchange. This character sequence cannot | XML document in the NETCONF exchange. This character sequence cannot | |||
legally appear in an XML document, so it can be unambiguously used to | 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 | identify the end of the current document in the event notification of | |||
an XML syntax or parsing error, allowing resynchronization of the | an XML syntax or parsing error, allowing resynchronization of the | |||
NETCONF exchange. | NETCONF exchange. | |||
The NETCONF over SSH session to receive an event notification might | The NETCONF over SSH session to receive an event notification might | |||
look like the following. Note the event notification contents | look like the following. In the example below the event notification | |||
(delimited by <data> </data> tags) are not defined in this document | contents (delimited by <data> </data> tags) are not defined in this | |||
and are provided herein simply for illustration purposes: | 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"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<notification | <notification | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<subscription-id>123456</subscription-id> | <data xmlns="http://example.com/event/1.0"> | |||
<data> | <severity>notice</severity> | |||
<eventClasses><configuration/><audit/></eventClasses> | <eventClasses><configuration/><audit/></eventClasses> | |||
<sequenceNumber>2</sequenceNumber> | <sequenceNumber>2</sequenceNumber> | |||
<dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | |||
<user>Fred Flinstone</user> | <user>Fred Flinstone</user> | |||
<operation> | <operation> | |||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<running/> | <running/> | |||
</target> | </target> | |||
<config> | <edit-config> | |||
<top xmlns="http://example.com/schema/1.2/config"> | <top xmlns="http://example.com/schema/1.2/config"> | |||
<interfaces> | ||||
<interface> | <interface> | |||
<name>Ethernet0/0</name> | <name>Ethernet0/0</name> | |||
<mtu>1500</mtu> | <mtu>1500</mtu> | |||
</interface> | </interface> | |||
</interfaces> | ||||
</top> | </top> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</operation> | </operation> | |||
</data> | </data> | |||
</event> | ||||
</data> | ||||
</notification> | </notification> | |||
]]> | ]]>]]> | |||
]]> | ||||
5.2 BEEP | 5.2. BEEP | |||
Session establishment and two-way messages are based on the NETCONF | Session establishment and two-way messages are based on the NETCONF | |||
over BEEP transport mapping NETCONF-BEEP | over BEEP transport mapping [NETCONF BEEP] | |||
5.2.1 One-way Notification Messages in Beep | 5.2.1. One-way Notification Messages in Beep | |||
One-way notification messages can be supported either by mapping to | 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- | the existing one-to-many BEEP construct or by creating a new one-to- | |||
none construct. | none construct. | |||
This area is for future study. | This area is for future study. | |||
5.2.1.1 One-way messages via the One-to-many Construct | 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 one-to-many exchanges: "rpc", "notification", "rpc-reply" | |||
Messages in positive replies: "rpc-reply", "rpc-one-way" | Messages in positive replies: "rpc-reply" | |||
5.2.1.2 One-way notification messages via the One-to-none Construct | 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 | Note that this construct would need to be added to an extension or | |||
update to 'The Blocks Extensible Exchange Protocol Core' RFC 3080. | update to 'The Blocks Extensible Exchange Protocol Core' [RFC3080]. | |||
MSG/NoANS: the client sends a "MSG" message, the server, sends no | MSG/NoANS: the client sends a "MSG" message, the server, sends no | |||
reply. | reply. | |||
In one-to-none exchanges, no reply to the "MSG" message is expected. | In one-to-none exchanges, no reply to the "MSG" message is expected. | |||
5.3 SOAP | 5.3. SOAP | |||
Session management and message exchange are based on the NETCONF over | Session management and message exchange are based on the NETCONF over | |||
SOAP transport mapping NETCONF-SOAP | SOAP transport mapping [NETCONF SOAP] | |||
Note that the use of "persistent connections" "chunked transfer- | Note that the use of "persistent connections" "chunked transfer- | |||
coding" when using HTTP becomes even more important in the supporting | coding" when using HTTP becomes even more important in the supporting | |||
of event notifications | of event notifications | |||
5.3.1 A NETCONF over Soap over HTTP Example | 5.3.1. A NETCONF over Soap over HTTP Example | |||
C: POST /netconf HTTP/1.1 | C: POST /netconf HTTP/1.1 | |||
C: Host: netconfdevice | C: Host: netconfdevice | |||
C: Content-Type: text/xml; charset=utf-8 | C: Content-Type: text/xml; charset=utf-8 | |||
C: Accept: application/soap+xml, text/* | C: Accept: application/soap+xml, text/* | |||
C: Cache-Control: no-cache | C: Cache-Control: no-cache | |||
C: Pragma: no-cache | C: Pragma: no-cache | |||
C: Content-Length: 465 | C: Content-Length: 465 | |||
C: | C: | |||
C: <?xml version="1.0" encoding="UTF-8"?> | C: <?xml version="1.0" encoding="UTF-8"?> | |||
skipping to change at page 29, line 46 | skipping to change at page 28, line 4 | |||
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | |||
C: <soapenv:Body> | C: <soapenv:Body> | |||
C: <rpc message-id="101" | C: <rpc message-id="101" | |||
C: xmlns= | C: xmlns= | |||
"xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | "xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
C: <create-subscription> | C: <create-subscription> | |||
C: </create-subscription> | C: </create-subscription> | |||
C: </rpc> | C: </rpc> | |||
C: </soapenv:Body> | C: </soapenv:Body> | |||
C: </soapenv:Envelope> | C: </soapenv:Envelope> | |||
The response: | The response: | |||
S: HTTP/1.1 200 OK | S: HTTP/1.1 200 OK | |||
S: Content-Type: application/soap+xml; charset=utf-8 | S: Content-Type: application/soap+xml; charset=utf-8 | |||
S: Content-Length: 917 | S: Content-Length: 917 | |||
S: | S: | |||
S: <?xml version="1.0" encoding="UTF-8"?> | S: <?xml version="1.0" encoding="UTF-8"?> | |||
S: <soapenv:Envelope | S: <soapenv:Envelope | |||
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | |||
S: <soapenv:Body> | S: <soapenv:Body> | |||
S: <rpc-reply message-id="101" | S: <rpc-reply message-id="101" | |||
S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
S: <data> | S: <data> | |||
S: <top xmlns= | S: <top xmlns= | |||
"http://example.com/schema/1.2/notification"> | "http://example.com/schema/1.2/notification"> | |||
S: <subscriptionId>123456</subscriptionId> | ||||
S: </top> | S: </top> | |||
S: </data> | S: </data> | |||
S: </rpc-reply> | S: </rpc-reply> | |||
S: </soapenv:Body> | S: </soapenv:Body> | |||
S: </soapenv:Envelope> | S: </soapenv:Envelope> | |||
And then some time later | And then some time later | |||
S: HTTP/1.1 200 OK | S: HTTP/1.1 200 OK | |||
S: Content-Type: application/soap+xml; charset=utf-8 | S: Content-Type: application/soap+xml; charset=utf-8 | |||
S: Content-Length: 917 | S: Content-Length: 917 | |||
S: | S: | |||
S: <?xml version="1.0" encoding="UTF-8"?> | S: <?xml version="1.0" encoding="UTF-8"?> | |||
S: <soapenv:Envelope | S: <soapenv:Envelope | |||
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | |||
S: <soapenv:Body> | S: <soapenv:Body> | |||
S: <notification | S: <notification | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
S: <subscriptionID>123456</subscriptionID> | ||||
S: <data> | S: <data> | |||
S: <eventClasses><configuration/><audit/></eventClasses> | S: <eventClasses><configuration/><audit/></eventClasses> | |||
S: <sequenceNumber>2</sequenceNumber> | S: <sequenceNumber>2</sequenceNumber> | |||
S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | |||
S: <user>Fred Flinstone</user> | S: <user>Fred Flinstone</user> | |||
S: <operation> | S: <operation> | |||
S: <edit-config> | S: <edit-config> | |||
S: <target> | S: <target> | |||
S: <running/> | S: <running/> | |||
S: </target> | S: </target> | |||
S: <config> | S: <config> | |||
S: <top xmlns="http://example.com/schema/1.2/config"> | S: <top xmlns="http://example.com/schema/1.2/config"> | |||
S: <interface> | S: <interfaces> | |||
<interface> | ||||
S: <name>Ethernet0/0</name> | S: <name>Ethernet0/0</name> | |||
S: <mtu>1500</mtu> | S: <mtu>1500</mtu> | |||
S: </interface> | </interface> | |||
S: </interfaces> | ||||
S: </top> | S: </top> | |||
S: </config> | S: </config> | |||
S: </edit-config> | S: </edit-config> | |||
S: </operation> | S: </operation> | |||
S: </data> | S: </data> | |||
S: </notification> | S: </notification> | |||
S: </soapenv:Body> | S: </soapenv:Body> | |||
S: </soapenv:Envelope> | S: </soapenv:Envelope> | |||
6. Filtering examples | 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 | 6.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 (only for example | |||
purposes). The examples herein assume that the event notification | purposes). The examples herein assume that the event notification | |||
schema definition has an <eventClasses> element identifying the | schema definition has an <eventClasses> element identifying the event | |||
event category (e.g. fault, state, config, etc.) and events have a | category (e.g. fault, 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 | |||
<netconf:filter type="subtree"> | ||||
<neb | ||||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<event> | <filter type="subtree"> | |||
<event xmlns="http://example.com/event/1.0"> | ||||
<severity>critical</severity> | <severity>critical</severity> | |||
</event> | </event> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<severity>major</severity> | <severity>major</severity> | |||
</event> | </event> | |||
<event> | <event xmlns="http://example.com/event/1.0"> | |||
<severity>minor</severity> | <severity>minor</severity> | |||
</event> | </event> | |||
</neb> | ||||
</netconf:filter> | </netconf:filter> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
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"> | |||
<neb | <top | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<event> | <event> | |||
<eventClasses>fault</eventClasses> | <eventClasses>fault</eventClasses> | |||
</event> | </event> | |||
<event> | <event> | |||
<eventClasses>state</eventClasses> | <eventClasses>state</eventClasses> | |||
</event> | </event> | |||
<event> | <event> | |||
<eventClasses>config</eventClasses> | <eventClasses>config</eventClasses> | |||
</event> | </event> | |||
<event> | <event> | |||
<card>Ethernet0</card> | <card>Ethernet0</card> | |||
</event> | </event> | |||
</neb> | </top> | |||
</netconf:filter> | </netconf:filter> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
6.2 XPATH filters | 6.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. The | |||
filtering criteria evaluation is as follows: | 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> | |||
skipping to change at page 35, line 7 | skipping to change at page 33, line 7 | |||
/event[severity="major"]) or | /event[severity="major"]) or | |||
(/event[eventClasses/fault] and | (/event[eventClasses/fault] and | |||
/event[severity="minor"]) or | /event[severity="minor"]) or | |||
/event[card="Ethernet0"])) | /event[card="Ethernet0"])) | |||
</netconf:filter> | </netconf:filter> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
7. Notification Replay Capability | 7. Notification Replay Capability | |||
7.1 Overview | 7.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 of the replay is implicitly defined to | |||
be the time the replay request was initiated. | be the time the replay request was initiated. | |||
An implementation that supports replay is not expected to have an | An implementation 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 an 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. | constraints, such as filtering, that the client has provided. The | |||
warning message enables the NETCONF client to differentiate between | ||||
the case that there were no notifications generated within a given | ||||
time period from the case that no notifications are currently in the | ||||
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 agent implementation specific matter. Control | any given time is an NETCONF server implementation specific matter. | |||
parameters for this aspect of the feature are outside the scope of | Control parameters for this aspect of the feature are outside the | |||
the current work. | scope of the current work. | |||
A given subscription is either a replay subscription or a normal | A given subscription is either a replay subscription or a normal | |||
subscription, which sends event notifications as they happen. A | subscription, which sends event notifications as they happen. A | |||
replay subscription terminates once the it has completed replaying | replay subscription terminates once the it has completed replaying | |||
past events. | past events. | |||
7.2 Dependencies | 7.2. Dependencies | |||
This capability is dependent on the notification capability being | This capability is dependent on the notification capability being | |||
supported. It also requires that the device support some form of | supported. It also requires that the device supporting the Netconf | |||
notification logging, although it puts no restrictions on the size or | server also support some form of notification logging, although it | |||
form of the log. | puts no restrictions on the size or form of the log, nor where it | |||
resides within the device. | ||||
7.3 Capability Identifier | 7.3. Capability Identifier | |||
The Event Notification Replay capability is identified by following | The Event Notification Replay capability is identified by following | |||
capability string: | capability string: | |||
http://ietf.org/netconf/notificationReplay/1.0 | http://ietf.org/netconf/notificationReplay/1.0 | |||
7.4 New Operations | 7.4. New Operations | |||
None | None | |||
7.5 Modifications to Existing Operations | 7.5. Modifications to Existing Operations | |||
7.5.1 create-subscription | 7.5.1. create-subscription | |||
This capability adds an optional parameter to the <create- | This capability adds an optional parameter to the <create- | |||
subscription> command called 'startTime'. This identifies the | subscription> command called 'startTime'. This 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. Events generated before this time are not matched. | |||
7.5.2 Interactions with Other Capabilities | 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 was sent out by the NETCONF server - the startTime parameter is | ||||
related to generation time. | ||||
Negative Response: | ||||
An <rpc-error> element is included in the <rpc-reply> if the | ||||
startTime in replay request predates the oldest notification | ||||
available to be replayed. | ||||
Error-tag: start-time-value | ||||
Error-type: protocol | ||||
Error-severity: warning | ||||
Error-info: none | ||||
Error-message: Start time predates oldest available | ||||
notification to be replayed | ||||
7.5.2. Interactions with Other Capabilities | ||||
[Edtitor's Note: If this capability does not interact with other | [Edtitor's Note: If this capability does not interact with other | |||
capabilities, this section may be omitted.] | capabilities, this section may be omitted.] | |||
7.6. Replay Complete Notification | ||||
The following notification is the last notification sent over a | ||||
replay subscription. It indicates that replay is complete. | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" | ||||
xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0" | ||||
targetNamespace= | ||||
"urn:ietf:params:xml:ns:netconf:replayNotification:1.0"> | ||||
<xs:element name="replayCompleteNotification" > | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
This notification is sent to signal the end of a replay | ||||
subscription. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
<xs:complexType> | ||||
<xs:sequence> | ||||
<xs:element name="eventClass" default="informational"> | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
The event classification of this notification. | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
</xs:element> | ||||
<xs:element name="timeGenerated" type="xs:dateTime"/> | ||||
<xs:element name="numberEventsReplayed" type="xs:integer"/> | ||||
</xs:sequence> | ||||
</xs:complexType> | ||||
</xs:element> | ||||
</xs:schema> | ||||
8. Security Considerations | 8. Security Considerations | |||
To be determined once specific aspects of this solution are better | The access control framework and the choice of transport will have a | |||
understood. In particular, the access control framework and the | major impact on the security of the solution. | |||
choice of transport will have a major impact on the security of the | ||||
solution | Note that the <notification> elements are never sent before the | |||
transport layer and the netconf layer (capabilities exchange) have | ||||
been established, and the manager has been identified and | ||||
authenticated. | ||||
It is recommended that care be taken to ensure the secure operation | ||||
of the following commands: | ||||
o <create-subscription> invocation | ||||
o use of <kill-session> | ||||
o read-only data models | ||||
o read-write data models | ||||
o notification content | ||||
One issue related to the notifications draft is the transport of data | ||||
from non-netconf streams, such as syslog and SNMP. Note that this | ||||
data may be more vulnerable (or is not more vulnerable) when being | ||||
transported over netconf than when being transported using the | ||||
protocol normally used for transporting it, depending on the security | ||||
credentials of the two subsystems. | ||||
9. Acknowledgements | 9. 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 | Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, | |||
Cridlig, Martin Bjorklund, Olivier Festor, Radu State, Brian | Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William | |||
Trammell, William Chow | Chow | |||
10. References | 10. 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] | [NETCONF BEEP] | |||
Lear, E. and K. Crozier, "Using the NETCONF Protocol over | Lear, E. and K. Crozier, "Using the NETCONF Protocol over | |||
Blocks Extensible Exchange Protocol (BEEP)", | Blocks Extensible Exchange Protocol (BEEP)", | |||
ID draft-ietf-netconf-beep-10, March 2006. | ID draft-ietf-netconf-beep-10, March 2006. | |||
[NETCONF Datamodel] | [NETCONF Datamodel] | |||
skipping to change at page 38, line 44 | skipping to change at page 38, line 30 | |||
[NETCONF SOAP] | [NETCONF SOAP] | |||
Goddard, T., "Using the Network Configuration Protocol | Goddard, T., "Using the Network Configuration Protocol | |||
(NETCONF) Over the Simple Object Access Protocol (SOAP)", | (NETCONF) Over the Simple Object Access Protocol (SOAP)", | |||
ID draft-ietf-netconf-soap-08, March 2006. | ID draft-ietf-netconf-soap-08, March 2006. | |||
[NETCONF SSH] | [NETCONF SSH] | |||
Wasserman, M. and T. Goddard, "Using the NETCONF | Wasserman, M. and T. Goddard, "Using the NETCONF | |||
Configuration Protocol over Secure Shell (SSH)", | Configuration Protocol over Secure Shell (SSH)", | |||
ID draft-ietf-netconf-ssh-06.txt, March 2006. | ID draft-ietf-netconf-ssh-06.txt, March 2006. | |||
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
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. | 3", RFC 2026, BCP 9, October 1996. | |||
[refs.RFC2119] | [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements | |||
Bradner, s., "Key words for RFCs to Indicate Requirements | ||||
Levels", RFC 2119, March 1997. | Levels", RFC 2119, March 1997. | |||
[refs.RFC2223] | [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", | |||
Postel, J. and J. Reynolds, "Instructions to RFC Authors", | ||||
RFC 2223, October 1997. | RFC 2223, October 1997. | |||
[refs.RFC3080] | [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", | |||
Rose, M., "The Blocks Extensible Exchange Protocol Core", | ||||
RFC 3080, March 2001. | RFC 3080, March 2001. | |||
[XML] World Wide Web Consortium, "Extensible Markup Language | ||||
(XML) 1.0", W3C XML, February 1998, | ||||
<http://www.w3.org/TR/1998/REC-xml-19980210>. | ||||
[XML Schema] | ||||
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer | ||||
Second Edition", W3C XML Schema, October 2004. | ||||
Authors' Addresses | Authors' Addresses | |||
Sharon Chisholm | Sharon Chisholm | |||
Nortel | Nortel | |||
3500 Carling Ave | 3500 Carling Ave | |||
Nepean, Ontario K2H 8E9 | Nepean, Ontario K2H 8E9 | |||
Canada | Canada | |||
Email: schishol@nortel.com | Email: schishol@nortel.com | |||
Hector Trevino | Hector Trevino | |||
Cisco | Cisco | |||
Suite 400 | Suite 400 | |||
9155 E. Nichols Ave | 9155 E. Nichols Ave | |||
Englewood, CO 80112 | Englewood, CO 80112 | |||
USA | USA | |||
Email: htrevino@cisco.com | Email: htrevino@cisco.com | |||
Intellectual Property Statement | Full 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. | ||||
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. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 40, line 29 | skipping to change at page 40, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | 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 | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 156 change blocks. | ||||
408 lines changed or deleted | 402 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/ |