draft-ietf-netconf-notification-01.txt | draft-ietf-netconf-notification-02.txt | |||
---|---|---|---|---|
Network Working Group S. Chisholm | Network Working Group S. Chisholm | |||
Internet-Draft K. Curran | Internet-Draft K. Curran | |||
Expires: October 30, 2006 Nortel | Expires: December 23, 2006 Nortel | |||
H. Trevino | H. Trevino | |||
Cisco | Cisco | |||
April 28, 2006 | June 21, 2006 | |||
NETCONF Event Notifications | NETCONF Event Notifications | |||
draft-ietf-netconf-notification-01.txt | draft-ietf-netconf-notification-02.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 36 | skipping to change at page 1, line 36 | |||
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 October 30, 2006. | This Internet-Draft will expire on December 23, 2006. | |||
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 memo defines a framework for sending asynchronous messages, or | |||
event notifications in NETCONF. It defines both the operations | event notifications in NETCONF. It defines both the operations | |||
necessary to support this concept, and also discusses implications | necessary to support this concept, and also discusses implications | |||
for the mapping to application protocols. | for the mapping to transport protocols. | |||
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 | |||
2. Event-Related Operations . . . . . . . . . . . . . . . . . . . 6 | 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1 Subscribing to receive Events . . . . . . . . . . . . . . 6 | 1.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1.1 create-subscription . . . . . . . . . . . . . . . . . 6 | 1.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2 Sending Event Notifications . . . . . . . . . . . . . . . 7 | 2. Event-Related Operations . . . . . . . . . . . . . . . . . . . 8 | |||
2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 7 | 2.1 Subscribing to receive Events . . . . . . . . . . . . . . 8 | |||
2.3 Changing the Subscription . . . . . . . . . . . . . . . . 8 | 2.1.1 create-subscription . . . . . . . . . . . . . . . . . 8 | |||
2.3.1 modify-subscription . . . . . . . . . . . . . . . . . 9 | 2.2 Sending Event Notifications . . . . . . . . . . . . . . . 9 | |||
2.4 Terminating the Subscription . . . . . . . . . . . . . . . 10 | 2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 9 | |||
2.4.1 cancel-subscription . . . . . . . . . . . . . . . . . 10 | 2.3 Changing the Subscription . . . . . . . . . . . . . . . . 10 | |||
3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 11 | 2.3.1 modify-subscription . . . . . . . . . . . . . . . . . 10 | |||
3.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . 11 | 2.4 Terminating the Subscription . . . . . . . . . . . . . . . 11 | |||
3.2 Querying Subscription Properties . . . . . . . . . . . . . 11 | 2.4.1 cancel-subscription . . . . . . . . . . . . . . . . . 12 | |||
3.3 One-way Notification Messages . . . . . . . . . . . . . . 16 | 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 13 | |||
3.4 Filter Dependencies . . . . . . . . . . . . . . . . . . . 16 | 3.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . 13 | |||
3.4.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 17 | 3.2 Subscriptions and Datastores . . . . . . . . . . . . . . . 13 | |||
3.4.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 17 | 3.3 Querying Subscription Properties . . . . . . . . . . . . . 13 | |||
3.5 Event Classes . . . . . . . . . . . . . . . . . . . . . . 17 | 3.4 One-way Notification Messages . . . . . . . . . . . . . . 18 | |||
3.6 Defining Event Notifications . . . . . . . . . . . . . . . 18 | 3.5 Filter Dependencies . . . . . . . . . . . . . . . . . . . 19 | |||
3.7 Interleaving Messages . . . . . . . . . . . . . . . . . . 18 | 3.5.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 19 | |||
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 20 | 3.5.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5. Mapping to Application Protocols . . . . . . . . . . . . . . . 24 | 3.6 Event Classes . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 3.6.1 Initial Set of Event Classes . . . . . . . . . . . . . 20 | |||
5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 3.7 Defining Event Notifications . . . . . . . . . . . . . . . 21 | |||
5.2.1 One-way Notification Messages in Beep . . . . . . . . 25 | 3.8 Interleaving Messages . . . . . . . . . . . . . . . . . . 21 | |||
5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 23 | |||
5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 26 | 5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 27 | |||
6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 29 | 5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6.1 Event Classes . . . . . . . . . . . . . . . . . . . . . . 29 | 5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.2 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 29 | 5.2.1 One-way Notification Messages in Beep . . . . . . . . 28 | |||
6.3 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 31 | 5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
7. Additional Capabilities . . . . . . . . . . . . . . . . . . . 33 | 5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 29 | |||
7.1 Call-Home Notifications . . . . . . . . . . . . . . . . . 33 | 6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 33 | 6.1 Event Classes . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . 34 | 6.2 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 32 | |||
7.1.3 Capability Identifier . . . . . . . . . . . . . . . . 34 | 6.3 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 34 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | 7. Additional Capabilities . . . . . . . . . . . . . . . . . . . 36 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 7.1 Call-Home Notifications . . . . . . . . . . . . . . . . . 36 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 | 7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 7.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . 37 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40 | 7.1.3 Capability Identifier . . . . . . . . . . . . . . . . 37 | |||
A. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 41 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 | |||
A.1 Suspend And Resume . . . . . . . . . . . . . . . . . . . . 41 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | |||
A.2 Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 41 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 | |||
B. Event Notifications and Syslog . . . . . . . . . . . . . . . . 42 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
B.1 Leveraging Syslog Field Definitions . . . . . . . . . . . 42 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 | |||
B.1.1 Field Mapping . . . . . . . . . . . . . . . . . . . . 43 | A. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 45 | |||
B.1.2 Severity Mapping . . . . . . . . . . . . . . . . . . . 44 | A.1 Suspend And Resume . . . . . . . . . . . . . . . . . . . . 45 | |||
B.2 Syslog within NETCONF Events . . . . . . . . . . . . . . . 44 | A.2 Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
B.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 44 | B. Event Notifications and Syslog . . . . . . . . . . . . . . . . 46 | |||
B.2.2 Embedding syslog messages in a NETCONF Event . . . . . 44 | B.1 Leveraging Syslog Field Definitions . . . . . . . . . . . 46 | |||
B.2.3 Supported Forwarding Options . . . . . . . . . . . . . 45 | B.1.1 Field Mapping . . . . . . . . . . . . . . . . . . . . 47 | |||
C. Example Configuration Notifications . . . . . . . . . . . . . 47 | B.1.2 Severity Mapping . . . . . . . . . . . . . . . . . . . 48 | |||
C.1 Types of Configuration Events . . . . . . . . . . . . . . 47 | B.2 Syslog within NETCONF Events . . . . . . . . . . . . . . . 48 | |||
C.2 Config Event Notification Structure . . . . . . . . . . . 48 | B.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 48 | |||
C.3 Configuration Event Content . . . . . . . . . . . . . . . 50 | B.2.2 Embedding syslog messages in a NETCONF Event . . . . . 48 | |||
C.3.1 Target Datastore . . . . . . . . . . . . . . . . . . . 50 | B.2.3 Supported Forwarding Options . . . . . . . . . . . . . 49 | |||
C.3.2 User Info . . . . . . . . . . . . . . . . . . . . . . 50 | C. Example Configuration Notifications . . . . . . . . . . . . . 51 | |||
C.3.3 Data Source . . . . . . . . . . . . . . . . . . . . . 50 | C.1 Types of Configuration Events . . . . . . . . . . . . . . 51 | |||
C.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . 50 | C.2 Config Event Notification Structure . . . . . . . . . . . 52 | |||
C.3.5 Context . . . . . . . . . . . . . . . . . . . . . . . 50 | C.3 Configuration Event Content . . . . . . . . . . . . . . . 54 | |||
C.3.6 Entered Command . . . . . . . . . . . . . . . . . . . 51 | C.3.1 Target Datastore . . . . . . . . . . . . . . . . . . . 54 | |||
C.3.7 New Config . . . . . . . . . . . . . . . . . . . . . . 51 | C.3.2 User Info . . . . . . . . . . . . . . . . . . . . . . 54 | |||
C.3.8 Old Config . . . . . . . . . . . . . . . . . . . . . . 51 | C.3.3 Data Source . . . . . . . . . . . . . . . . . . . . . 54 | |||
C.3.9 Non-netconf commands in configuration notifications . 51 | C.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . 54 | |||
Intellectual Property and Copyright Statements . . . . . . . . 52 | C.3.5 Context . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
C.3.6 Entered Command . . . . . . . . . . . . . . . . . . . 55 | ||||
C.3.7 New Config . . . . . . . . . . . . . . . . . . . . . . 55 | ||||
C.3.8 Old Config . . . . . . . . . . . . . . . . . . . . . . 55 | ||||
C.3.9 Non-netconf commands in configuration notifications . 55 | ||||
D. IP Address Schema . . . . . . . . . . . . . . . . . . . . . . 56 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 58 | ||||
1. Introduction | 1. Introduction | |||
NETCONF [NETCONF-PROTO] can be conceptually partitioned into four | NETCONF [NETCONF-PROTO] can be conceptually partitioned into four | |||
layers: | layers: | |||
Layer Example | Layer Example | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
| Content | | Configuration data | | | Content | | Configuration data | | |||
+-------------+ +----------------------------------------+ | +-------------+ +----------------------------------------+ | |||
skipping to change at page 4, line 31 | skipping to change at page 4, line 31 | |||
+-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | | |||
| | | | | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
| Application | | BEEP, SSH, SSL, console | | | Application | | BEEP, SSH, SSL, console | | |||
| Protocol | | | | | Protocol | | | | |||
+-------------+ +------------------------------------------+ | +-------------+ +------------------------------------------+ | |||
This document defines a framework for sending asynchronous messages, | This document defines a framework for sending asynchronous messages, | |||
or event notifications in NETCONF. It defines both the operations | or event notifications in NETCONF. It defines both the operations | |||
necessary to support this concept, and also discusses implications | necessary to support this concept, and also discusses implications | |||
for the mapping to application protocols. | for the mapping to transport protocols. | |||
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 RFC 2119 [3]. | |||
Element: An XML Element[XML]. | Element: An XML Element[XML]. | |||
Managed Entity: A node, which supports NETCONF[NETCONF] and has | Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has | |||
access to management instrumentation. This is also known as the | access to management instrumentation. This is also known as the | |||
NETCONF server. | 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. | |||
1.2 Event Notifications in NETCONF | 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 | |||
skipping to change at page 6, line 5 | skipping to change at page 5, line 28 | |||
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 an explicit command to | either the NETCONF session is terminated or an explicit command to | |||
cancel the subscription is sent. The event notification subscription | cancel the subscription is sent. The event notification subscription | |||
allows a number of options to enable the NETCONF client to specify | allows a number of options to enable the NETCONF client to specify | |||
which events are of interest. These are specified when the | which events are of interest. These are specified when the | |||
subscription is created, but can be modified later using a modify | subscription is created, but can be modified later using a modify | |||
subscription command. | subscription command. | |||
1.3 Motivation | ||||
The motivation for this work is to enable the sending of asynchronous | ||||
messages that are consistent with the data model (content) and | ||||
security model used within a Netconf implementation. | ||||
1.4 Requirements | ||||
The requirements for this solution are as follows: | ||||
o Initial release should ensure it supports notification in support | ||||
of configuration operations | ||||
o Data content must be use the same data model as used in | ||||
configuration | ||||
o solution should support structured hierarchical data | ||||
o solution should be able to carry configuration fragments | ||||
o solution should support a reasonable message size limit (syslog | ||||
and SNMP are rather constrained in terms of message sizes) | ||||
o solution should provide reliable delivery of notifications | ||||
o solution should support preconfigured notification destinations | ||||
o solution should support agent initiated connections | ||||
o solution should provide a subscription mechanism | ||||
o solution should support multiple subscriptions | ||||
o solution should provide a filtering mechanism | ||||
o solution should support notification names | ||||
o solution should support notification timestamps | ||||
o solution should support notification classes | ||||
o solution should support notification info | ||||
o solution should provide the ability to specify the content of | ||||
notifications to ensure predictability | ||||
o solution should send sufficient information in a notification so | ||||
that it can be analyzed independent of the transport mechanism | ||||
o solution should allow notifications to refer to prior | ||||
configuration change RPCs | ||||
o solution should not bind subscriptions to a connection | ||||
o channels for configuration change notifications should share fate | ||||
with a session that includes a configuration channel | ||||
o solution should support replay of locally logged notifications | ||||
o solution should support message chunking capability in cases | ||||
channels carry mixed RPCs | ||||
o solution should scale to 30.000-100.000 nodes which may emit | ||||
notifications | ||||
o solution should scale to order 30.000-100.000 nodes to send | ||||
notifications [BL] | ||||
See also the external website tracking requirements at | ||||
http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications | ||||
1.5 Architecture | ||||
[Editor's Note: add pointers to the various architecture discussions | ||||
in the document and identify what people view to be gaps in | ||||
architecture discussion. The following may not be what people were | ||||
looking for in this section, but should at least give people | ||||
something to discuss] | ||||
The following figure illustrates that the netconf implementation | ||||
leverages protocol-neutral event management software within the box | ||||
rather then re-invent everything in Netconf specific methods. The | ||||
netconf client understands which notifications are of interest to it | ||||
and creates a subscription that meets its requirements. The network | ||||
elements accepts the subscription requests and creates a temporary | ||||
subscription to meet those needs. | ||||
---------------------------------------------- | ||||
| Network Element | | ||||
| ------------ | | ||||
| | Alarm | | | ||||
| | Management | -------------- | -------------- | ||||
| ------------ |--->|Netconf Stack |<---------->| Netconf | | ||||
| | | | | | | | | ||||
| | | -------------- | --->| Client | | ||||
| V | | | -------------- | ||||
| ------------ | | | | ||||
| | Event |--->| ------------------ | | | ||||
| | Management | | |Other Protocols | | | | ||||
| ------------ |--->| | | | | ||||
| ------------------ | | | ||||
|--------------------------------------------- | | ||||
| | ||||
---------------------------------------------- | | ||||
| Network Element | | | ||||
| ------------ | | | ||||
| | Alarm | | | | ||||
| | Management | -------------- | | | ||||
| ------------ |--->|Netconf Stack |<-------| | ||||
| | | | | | | ||||
| | | -------------- | | ||||
| V | | | ||||
| ------------ | | | ||||
| | Event |--->| ------------------ | | ||||
| | Management | | |Other Protocols | | | ||||
| ------------ |--->| | | | ||||
| ------------------ | | ||||
|-------------------------------------------- | ||||
2. Event-Related Operations | 2. Event-Related Operations | |||
2.1 Subscribing to receive Events | 2.1 Subscribing to receive Events | |||
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. | |||
It is possible to create more than one event notification | It is possible to create more than one event notification | |||
skipping to change at page 6, line 28 | skipping to change at page 8, line 28 | |||
Content for an event notification subscription can be selected by | Content for an event notification subscription can be selected by | |||
specifying which event classes are of interest and /or by applying | specifying which event classes are of interest and /or by applying | |||
user-specified filters. | user-specified filters. | |||
2.1.1 create-subscription | 2.1.1 create-subscription | |||
<create-subscription> | <create-subscription> | |||
Description: | Description: | |||
This command 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 <cancel-subscription > command is sent. | command until the <cancel-subscription > command is sent. | |||
Parameters: | Parameters: | |||
Event Classes: | Event Classes: | |||
An optional parameter that indicates which event classes are of | An optional parameter that indicates which event classes are of | |||
interest. If not present, events of all classes will be sent. | interest. If not present, events of all classes will be sent. | |||
skipping to change at page 7, line 7 | skipping to change at page 9, line 7 | |||
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. These filter parameters can | by other parameters will be sent. These filter parameters can | |||
only be modified using the modify-subscription command. | only be modified using the modify-subscription command. | |||
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. If the separate definition of these | filtering will be applied. Note that changes to the profile | |||
filters is updated, then these changes will be reflected in the | after the subscription has been created will have no effect | |||
filtered events on this subscription. | unless a modify subscription command is issued. | |||
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 | <rpc-reply> element containing a <data> element containing the | |||
subscription ID. | 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. | request cannot be completed for any reason. Subscription requests | |||
will fail if a filter with invalid syntax is provided or if the | ||||
name of a non-existent profile is provided. | ||||
2.2 Sending Event Notifications | 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. | |||
Notifications are tagged with event classes, subscription ID, | Notifications are tagged with event classes, subscription ID, | |||
sequence number, and date and time. | sequence number, and date and time. | |||
2.2.1 Event Notification | 2.2.1 Event Notification | |||
skipping to change at page 8, line 20 | skipping to change at page 10, line 20 | |||
A sequentially increasing number to uniquely identify event | A sequentially increasing number to uniquely identify event | |||
notifications for this subscription. It starts at 0, always | notifications for this subscription. It starts at 0, always | |||
increases by just one and rolls back to 0 after its maximum | increases by just one and rolls back to 0 after its maximum | |||
value is reached. | value is reached. | |||
Date and Time: | Date and Time: | |||
The date and time that the event notification was sent by the | The date and time that the event notification was sent by the | |||
NETCONF server. | NETCONF server. | |||
Data: | ||||
Contains event class and notification-specific tagged content. | ||||
Positive Response: | Positive Response: | |||
No response. | No response. | |||
Negative Response: | Negative Response: | |||
No response. | No response. | |||
2.2.1.1 Event Notification | ||||
The NETCONF Event notification structure is shown in the following | ||||
figure. | ||||
___________________________________________________________________ | ||||
|| Notification Header || Data | | ||||
||__________________________________________________________||______| | ||||
|| subscriptionId| eventClasses| sequenceNumber| dateAndTime|| | | ||||
||_______________|_____________|_______________|____________||______| | ||||
2.3 Changing the Subscription | 2.3 Changing the Subscription | |||
After an event notification subscription has been established, the | After an event notification subscription has been established, the | |||
NETCONF client can initiate a request to change properties of the | NETCONF client can initiate a request to change properties of the | |||
event notification subscription. This prevents loss of event | event notification subscription. This prevents loss of event | |||
notifications that might otherwise occur during a cancelling and | notifications that might otherwise occur during a cancelling and | |||
recreation of the event notification subscription. This command is | recreation of the event notification subscription. This operation is | |||
responded to by the NETCONF server | responded to by the NETCONF server | |||
2.3.1 modify-subscription | 2.3.1 modify-subscription | |||
<modify-subscription> | <modify-subscription> | |||
Description: | Description: | |||
Change properties of the event notification subscription. | Change properties of the event notification subscription. | |||
skipping to change at page 9, line 38 | skipping to change at page 11, line 32 | |||
filter used for other NETCONF commands. If not present, all | filter used for other NETCONF commands. If not present, all | |||
events not precluded by other parameters will be sent. These | events not precluded by other parameters will be sent. These | |||
filter parameters can only be modified using the modify- | filter parameters can only be modified using the modify- | |||
subscription command. | subscription command. | |||
Named Profile: | Named Profile: | |||
An optional parameter that points to separately defined filter | An optional parameter that points to separately defined filter | |||
profile. The contents of the profile are specified in provided | profile. The contents of the profile are specified in provided | |||
XML Schema. If not present, no additional filtering will be | XML Schema. If not present, no additional filtering will be | |||
applied. If the separate definition of these filters is | applied. Note that changes to the profile after the | |||
updated, then these changes will be reflected in the events | subscription has been created will have no effect unless a | |||
seen on this subscription. | modify subscription command is issued. | |||
Positive Response: | Positive Response: | |||
If the NETCONF server was able to satisfy the request, an <rpc- | If the NETCONF server was able to satisfy the request, an <rpc- | |||
reply> is sent that includes an <ok> element. | reply> is sent that includes an <ok> element. | |||
Negative Response: | Negative Response: | |||
An <rpc-error> element is included within the <rpc-reply> if the | An <rpc-error> element is included within the <rpc-reply> if the | |||
request cannot be completed for any reason. | request cannot be completed for any reason. Subscription requests | |||
will fail if a filter with invalid syntax is provided or if the | ||||
name of a non-existent profile is provided. | ||||
2.4 Terminating the Subscription | 2.4 Terminating the Subscription | |||
Closing of the event notification subscription is initiated by the | Closing of the event notification subscription is initiated by the | |||
NETCONF client. The specific subscription to be closed is specified | NETCONF client. The specific subscription to be closed is specified | |||
using a subscription ID. The NETCONF server responds. Note that the | using a subscription ID. The NETCONF server responds. Note that the | |||
NETCONF session may also be torn down for other reasons and this will | NETCONF session may also be torn down for other reasons and this will | |||
also result in the subscription being cancelled, but is not subjected | also result in the subscription being cancelled, but is not subjected | |||
to the behaviour of this command. | to the behaviour of this operation. | |||
2.4.1 cancel-subscription | 2.4.1 cancel-subscription | |||
<cancel-subscription> | <cancel-subscription> | |||
Description: | Description: | |||
Stop and delete the event notification subscription. | Stop and delete the event notification subscription. | |||
Parameters: | Parameters: | |||
skipping to change at page 11, line 31 | skipping to change at page 13, line 31 | |||
<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:notification:1.0 | |||
</capability> | </capability> | |||
</capabilities> | </capabilities> | |||
<session-id>4</session-id> | <session-id>4</session-id> | |||
</hello> | </hello> | |||
3.2 Querying Subscription Properties | 3.2 Subscriptions and Datastores | |||
Subscriptions are like Netconf sessions in that they don't exist | ||||
Netconf datastores. The two exceptions to this are named profiles | ||||
and the optional call-home notification feature. | ||||
3.3 Querying Subscription Properties | ||||
The following Schema can be used to retrieve information about active | 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" | |||
xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" | xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" | |||
elementFormDefault="qualified" attributeFormDefault="unqualified" | elementFormDefault="qualified" attributeFormDefault="unqualified" | |||
xml:lang="en"> | xml:lang="en"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
Schema for reporting on Event Subscriptions | Schema for reporting on Event Subscriptions | |||
</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>NetConfStateSchema</nm:Name> | <nm:Name>NetconfNotificationSchema</nm:Name> | |||
<nm:LastUpdated>2006-04-30T09:30:47-05:00 | <nm:LastUpdated>2006-04-30T09: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> | |||
skipping to change at page 16, line 31 | skipping to change at page 18, line 36 | |||
<xs:element name="namedProfiles"> | <xs:element name="namedProfiles"> | |||
<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.3 One-way Notification Messages | 3.4 One-way Notification Messages | |||
In order to support the concept that each individual event | In order to support the concept that each individual event | |||
notification is a well-defined XML-document that can be processed | notification is a well-defined XML-document that can be processed | |||
without waiting for all events to come in, it makes sense to define | 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 | events, not as an endless reply to a subscription command, but as | |||
independent messages that originate from the NETCONF server. In | independent messages that originate from the NETCONF server. In | |||
order to support this model, this memo introduces the concept of | order to support this model, this memo introduces the concept of | |||
notifications, which are one-way messages. | notifications, which are one-way messages. | |||
A one-way message is similar to the two-way RPC message, except that | 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 | no response is expected to the command. In the case of event | |||
notification, this message will originate from the NETCONF server, | notification, this message will originate from the NETCONF server, | |||
and not the NETCONF client. | and not the NETCONF client. | |||
3.4 Filter Dependencies | 3.5 Filter Dependencies | |||
Note that when multiple filters are specified (Event Class, in-line | Note that when multiple filters are specified (Event Class, in-line | |||
Filter, Named Profiles), they are applied collectively, so event | Filter, Named Profiles), they are applied collectively, so event | |||
notifications needs to pass all specified filters in order to be sent | notifications needs to pass all specified filters in order to be sent | |||
to the subscriber. If a filter is specified to look for data of a | to the subscriber. If a filter is specified to look for data of a | |||
particular value, and the data item is not present within a | particular value, and the data item is not present within a | |||
particular event notification for its value to be checked against, | particular event notification for its value to be checked against, | |||
it will be filtered out. For example, if one were to check for | it will be filtered out. For example, if one were to check for | |||
'severity=critical' in a configuration event notification where this | 'severity=critical' in a configuration event notification where this | |||
field was not supported, then the notification would be filtered out. | field was not supported, then the notification would be filtered out. | |||
3.4.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 or | at the time an event notification subscription is created or | |||
modified. Note that changes to the profile after the subscription | modified. Note that changes to the profile after the subscription | |||
has been created will have no effect unless a modify subscription | has been created will have no effect unless a modify subscription | |||
command is issued. Since named profiles exist outside of the | command is issued. Since named profiles exist outside of the | |||
subscription, they persist after the subscription has been cancelled. | subscription, they persist after the subscription has been cancelled. | |||
3.4.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. These filters can only be | notification subscription is created. These filters can only be | |||
changed using the modify subscription command. This is specified via | changed using the modify subscription command. This is specified via | |||
the Filter parameter. Filters only exist as parameters to the | the Filter parameter. Filters only exist as parameters to the | |||
subscription. | subscription. | |||
3.5 Event Classes | 3.6 Event Classes | |||
Events can be broadly classified into one more event classes. Each | Events can be classified into one more event classes. Each event | |||
event class identifies a set of event notifications which share | class identifies a set of event notifications which | |||
important characteristics, such being generated from similar events | ||||
or sharing much of the same content. | ||||
The initial set of event classes is fault, configuration, state, | share similar content | |||
are generated from similar events | ||||
The initial set of event classes is configuration, fault, state, | ||||
audit, data, maintenance, metrics, security, information, heartbeat | audit, data, maintenance, metrics, security, information, heartbeat | |||
and syslog. | and syslogTunnel. See the IANA Considerations section for | |||
information on defining new event classes. | ||||
All events shall carry the following data: list of event class, | ||||
timestamp and sequence number of the notification. They may also | ||||
carry additional data. | ||||
___________________________________________________________________ | ||||
|| Notification Header || Data | | ||||
||__________________________________________________________||______| | ||||
|| subscriptionId| eventClasses| sequenceNumber| dateAndTime|| | | ||||
||_______________|_____________|_______________|____________||______| | ||||
3.6.1 Initial Set of Event Classes | ||||
A configuration event, alternatively known as an inventory event, is | ||||
used to indicate that hardware, software, or a service has been | ||||
added, changed or removed. In keeping aligned with NETCONF protocol | ||||
operations, configuration events may included copy configuration | ||||
event, delete configuration event, or the edit configuration event | ||||
(create, delete, merge, replace). As configuration notifications | ||||
could potentially carry huge amounts of data in order to properly | ||||
support functions such as security audit logs, so it is expected that | ||||
netconf clients will engineer their subscriptions to meet their needs | ||||
and to not overwhelm their capacity to process and store event | ||||
notifications. Examples include hardware board removed, software | ||||
module loaded or DNS server reconfigured. Changes are reported to | ||||
all subscribed clients, not just to those clients whose actions | ||||
triggered the changes. | ||||
A fault event notification is generated when a fault condition (error | A fault event notification is generated when a fault condition (error | |||
or warning) occurs. A fault event may result in an alarm. Examples | or warning) occurs. A fault event may result in an alarm. Examples | |||
of fault events could be a communications alarm, environmental alarm, | of fault events could be a communications alarm, environmental alarm, | |||
equipment alarm, processing error alarm, quality of service alarm, or | equipment alarm, processing error alarm, quality of service alarm, or | |||
a threshold crossing event. See RFC3877 and RFC2819 for more | a threshold crossing event. See RFC3877 and RFC2819 for more | |||
information. The fault notification should carry the following data: | ||||
severity, event source, probable cause, specific problem, additional | ||||
information. | information. | |||
A configuration event, alternatively known as an inventory event, is | ||||
used to notify that hardware, software, or a service has been added/ | ||||
changed/removed. In keeping aligned with NETCONF protocol | ||||
operations, configuration events may included copy configuration | ||||
event, delete configuration event, or the edit configuration event | ||||
(create, delete, merge, replace). | ||||
A state event indicates a change from one state to another, where a | A state event indicates a change from one state to another, where a | |||
state is a condition or stage in the existence of a managed entity. | state is a condition or stage in the existence of a managed entity. | |||
State change events are seen in many specifications. For Entity | State change events are seen in many specifications. For Entity | |||
state changes, see [Entity-State-MIB] for more information. | state changes, see [Entity-State-MIB] for more information. The | |||
notification shall identify the object who's state changed and the | ||||
new state. Internal states of a node are important for supervision | ||||
purposes and also effect how a node can be configured. | ||||
Audit events provide event of very specific actions within a managed | Audit events provide event of very specific actions within a managed | |||
device. In isolation an audit events provides very limited data. A | device. In isolation an audit events provides very limited data. A | |||
collection of audit information forms an audit trail. | collection of audit information forms an audit trail. | |||
A data dump event is an asynchronous event containing information | A data dump event is an asynchronous event containing information | |||
about a system, its configuration, state, etc. | about a system, its configuration, state, etc. | |||
A maintenance event signals the beginning, process or end of an | A maintenance event signals the beginning, process or end of an | |||
action either generated by a manual or automated maintenance action. | action either generated by a manual or automated maintenance action. | |||
If the maintenance event is a direct result of a configuration | ||||
management operation on this Netconf session then an rpc-reply | ||||
notification should be used. This event class is intended instead | ||||
for reporting on scheduled maintenance activities. Expected data | ||||
includes a description of the maintenance process, the stage the | ||||
process has reached, the manual action, automatic process that | ||||
triggered the notification. Examples include automatic backup | ||||
completed. | ||||
A metrics event contains a metric or a collection of metrics. This | A metrics event contains a metric or a collection of metrics. This | |||
includes performance metrics. | includes performance metrics. | |||
A heart beat event is sent periodically to enable testing that the | A heart beat event is sent periodically to enable testing that the | |||
communications channel is still functional. It behaves much like the | communications channel is still functional. It behaves much like the | |||
other event classes, with the exception that implementations may not | other event classes, with the exception that implementations may not | |||
want to include an event log, if supported. Although widely used | want to include an event log, if supported. Although widely used | |||
throughout the industry, no current corresponding work within the | throughout the industry, no current corresponding work within the | |||
IETF. However, other standards bodies such as the TeleManagement | IETF. However, other standards bodies such as the TeleManagement | |||
Forum have similar definitions. | Forum have similar definitions. | |||
An Information event is something that happens of interest which is | An Information event is something that happens of interest which is | |||
within the expected operational behaviour and not otherwise covered | within the expected operational behaviour and not otherwise covered | |||
by another class. | by another class. | |||
The syslog event class is used to indicate tunneled syslog content. | syslogTunnel event is when syslog content is sent, unmodified, within | |||
The content and format of the message will be compliant to syslog | a Netconf event Notification. See appendix X.X for more | |||
standards. | information.. | |||
3.6 Defining Event Notifications | 3.7 Defining Event Notifications | |||
Event Notifications are defined ahead of time by defining an XML | Event Notifications are defined ahead of time by defining an XML | |||
element and assigning it to particular event classes. This will be | element and assigning it to particular event classes. This will be | |||
done using an "eventClasses" attribute. | done using an "eventClasses" attribute. | |||
3.7 Interleaving Messages | 3.8 Interleaving Messages | |||
While each NETCONF message must be a complete XML document, the | While each NETCONF message must be a complete XML document, the | |||
design of the event system allows for the interleaving of complete | design of the event system allows for the interleaving of complete | |||
asynchronous event notifications with complete synchronous messages. | asynchronous event notifications with complete synchronous messages. | |||
It is possible to still send command-response type messages such as | It is possible to still send command-response type messages such as | |||
<modify-subscription> while events are being generated. The only | <modify-subscription> while events are being generated. The only | |||
restriction is that each message must be complete | restriction is that each message must be complete | |||
The following sequence diagram demonstrates an example NETCONF | The following sequence diagram demonstrates an example NETCONF | |||
session where after basic session establishment and capability | session where after basic session establishment and capability | |||
exchange, NETCONF client (C), subscribes to receive event | exchange, NETCONF client (C), subscribes to receive event | |||
notifications. The NETCONF server (S), starts sending event | notifications. The NETCONF server (S), starts sending event | |||
notifications as events of interest happen within the system. The | notifications as events of interest happen within the system. The | |||
NETCONF client decides to change the characteristics of their event | NETCONF client decides to change the characteristics of their event | |||
skipping to change at page 23, line 25 | skipping to change at page 26, line 25 | |||
<xs:element name="cancel-subscription" | <xs:element name="cancel-subscription" | |||
type="cancelSubscriptionType" | type="cancelSubscriptionType" | |||
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:complexContent> | ||||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="subscription-id" | <xs:element name="subscriptionId" type="SubscriptionID" /> | |||
type="SubscriptionID"/> | <xs:element name="eventClasses" type="EventClasses" /> | |||
<xs:element name="event-classes" type="EventClasses"/> | <xs:element name="sequenceNumber" type="SequenceNumber" /> | |||
<xs:element name="sequence-number" | <xs:element name="dateAndTime" type="xs:dateTime"> | |||
type="SequenceNumber"/> | ||||
<xs:element name="date-time" type="xs:dateTime"> | ||||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
The date and time that the event notification was | The date and time that the notification was sent | |||
sent by the netconf server. | by the netconf server. | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
</xs:element> | </xs:element> | |||
</xs:sequence> | </xs:sequence> | |||
</xs:extension> | ||||
</xs:complexContent> | ||||
</xs:complexType> | </xs:complexType> | |||
<xs:element name="notification" type="NotificationType"/> | <xs:element name="notification" type="NotificationType"/> | |||
</xs:schema> | </xs:schema> | |||
5. Mapping to Application 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 application 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 | One-way event messages are supported as follows: Once the session | |||
has been established and capabilities have been exchanged, the server | has been established and capabilities have been exchanged, the server | |||
skipping to change at page 25, line 9 | skipping to change at page 28, line 9 | |||
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. Note the event notification contents | |||
(delimited by <data> </data> tags) are not defined in this document | (delimited by <data> </data> tags) are not defined in this document | |||
and are provided herein simply for illustration purposes: | and are provided herein simply for illustration purposes: | |||
<?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> | <subscription-id>123456</subscription-id> | |||
<event-class><configuration/><audit/></event-classes> | <eventClasses><configuration/><audit/></eventClasses> | |||
<sequence-number>2</sequence-number> | <sequenceNumber>2</sequenceNumber> | |||
<date-time>2000-01-12T12:13:14Z</date-time> | <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> | |||
<data> | <data> | |||
<user>Fred Flinstone</user> | <user>Fred Flinstone</user> | |||
<operation> | <operation> | |||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<running/> | <running/> | |||
</target> | </target> | |||
<config> | <config> | |||
<top xmlns="http://example.com/schema/1.2/config"> | <top xmlns="http://example.com/schema/1.2/config"> | |||
<interface> | <interface> | |||
skipping to change at page 27, line 34 | skipping to change at page 30, line 34 | |||
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: <subscriptionID>123456</subscriptionID> | |||
S: <eventClass><configuration/><audit/></eventClass> | 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: <data> | S: <data> | |||
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> | |||
skipping to change at page 29, line 16 | skipping to change at page 32, line 16 | |||
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 Event Classes | 6.1 Event Classes | |||
The following example illustrates selecting all event notifications | The following example illustrates selecting all event notifications | |||
for EventClasses fault, state or config | for EventClasses fault, state or config | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:event:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<eventClasses> | <eventClasses> | |||
<fault/> | <fault/> | |||
<state/> | <state/> | |||
<config/> | <config/> | |||
</eventClasses> | </eventClasses> | |||
</create-subscription> | </create-subscription> | |||
</rpc> | </rpc> | |||
6.2 Subtree Filtering | 6.2 Subtree Filtering | |||
skipping to change at page 30, line 5 | skipping to change at page 33, line 5 | |||
Nevertheless, it may be used for defining simple notification | Nevertheless, it may be used for defining simple notification | |||
forwarding filters as shown below. | forwarding filters as shown below. | |||
The following example illustrates selecting fault EventClass which | The following example illustrates selecting fault EventClass which | |||
have severities of critical, major, or minor. The filtering criteria | have severities of critical, major, or minor. The filtering criteria | |||
evaluation is as follows: | 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:event:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<eventClasses> | <eventClasses> | |||
<fault/> | <fault/> | |||
</eventClasses> | </eventClasses> | |||
<netconf:filter type="subtree"> | <netconf:filter type="subtree"> | |||
<neb xmlns="urn:ietf:params:xml:ns:netconf:event:1.0"> | <neb | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | ||||
<event> | <event> | |||
<severity>critical</severity> | <severity>critical</severity> | |||
</event> | </event> | |||
<event> | <event> | |||
<severity>major</severity> | <severity>major</severity> | |||
</event> | </event> | |||
<event> | <event> | |||
<severity>minor</severity> | <severity>minor</severity> | |||
</event> | </event> | |||
</neb> | </neb> | |||
skipping to change at page 31, line 5 | skipping to change at page 34, line 5 | |||
</rpc> | </rpc> | |||
The following example illustrates selecting fault, state, config | The following example illustrates selecting fault, state, config | |||
EventClasses which have severities of critical, major, or minor and | EventClasses which have severities of critical, major, or minor and | |||
come from card Ethernet0. The filtering criteria evaluation is as | come from card Ethernet0. The filtering criteria evaluation is as | |||
follows: | follows: | |||
((fault | state | config) & ((fault & severity=critical) | (fault & | ((fault | state | config) & ((fault & severity=critical) | (fault & | |||
severity=major) | (fault & severity = minor) | (card=Ethernet0))) | severity=major) | (fault & severity = minor) | (card=Ethernet0))) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:event:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<eventClasses> | <eventClasses> | |||
<fault/> | <fault/> | |||
<state/> | <state/> | |||
<config/> | <config/> | |||
</eventClasses> | </eventClasses> | |||
<netconf:filter type="subtree"> | <netconf:filter type="subtree"> | |||
<neb xmlns="urn:ietf:params:xml:ns:netconf:event:1.0"> | <neb | |||
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | ||||
<event> | <event> | |||
<eventClasses>fault</eventClasses> | <eventClasses>fault</eventClasses> | |||
<severity>critical</severity> | <severity>critical</severity> | |||
</event> | </event> | |||
<event> | <event> | |||
<eventClasses>fault</eventClasses> | <eventClasses>fault</eventClasses> | |||
<severity>major</severity> | <severity>major</severity> | |||
</event> | </event> | |||
<event> | <event> | |||
<eventClasses>fault</eventClasses> | <eventClasses>fault</eventClasses> | |||
skipping to change at page 32, line 5 | skipping to change at page 35, line 5 | |||
6.3 XPATH filters | 6.3 XPATH filters | |||
The following example illustrates selecting fault EventClass which | The following example illustrates selecting fault EventClass which | |||
have severities of critical, major, or minor. The filtering criteria | have severities of critical, major, or minor. The filtering criteria | |||
evaluation is as follows: | 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:event:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<eventClasses> | <eventClasses> | |||
<fault/> | <fault/> | |||
</eventClasses> | </eventClasses> | |||
<netconf:filter type="xpath"> | <netconf:filter type="xpath"> | |||
(/event[eventClasses/fault] and | (/event[eventClasses/fault] and | |||
(/event[severity="critical"] or | (/event[severity="critical"] or | |||
/event[severity="major"] or /event[severity="minor"])) | /event[severity="major"] or /event[severity="minor"])) | |||
</netconf:filter> | </netconf:filter> | |||
</create-subscription> | </create-subscription> | |||
skipping to change at page 32, line 27 | skipping to change at page 35, line 27 | |||
The following example illustrates selecting fault, state, config | The following example illustrates selecting fault, state, config | |||
EventClasses which have severities of critical, major, or minor and | EventClasses which have severities of critical, major, or minor and | |||
come from card Ethernet0. The filtering criteria evaluation is as | come from card Ethernet0. The filtering criteria evaluation is as | |||
follows: | follows: | |||
((fault | state | config) & ((fault & severity=critical) | (fault & | ((fault | state | config) & ((fault & severity=critical) | (fault & | |||
severity=major) | (fault & severity = minor) | (card=Ethernet0))) | severity=major) | (fault & severity = minor) | (card=Ethernet0))) | |||
<rpc message-id="101" | <rpc message-id="101" | |||
xmlns="urn:ietf:params:xml:ns:netconf:event:1.0"> | xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> | |||
<create-subscription> | <create-subscription> | |||
<eventClasses> | <eventClasses> | |||
<fault/> | <fault/> | |||
<state/> | <state/> | |||
<config/> | <config/> | |||
</eventClasses> | </eventClasses> | |||
<netconf:filter type="xpath"> | <netconf:filter type="xpath"> | |||
((/event[eventClasses/fault] or | ((/event[eventClasses/fault] or | |||
/event[eventClasses/state] or | /event[eventClasses/state] or | |||
/event[eventClasses/config]) and | /event[eventClasses/config]) and | |||
skipping to change at page 33, line 33 | skipping to change at page 36, line 33 | |||
association with a Netconf client. Unlike normal subscriptions, | association with a Netconf client. Unlike normal subscriptions, | |||
which only exist when they are active, these subscriptions live while | which only exist when they are active, these subscriptions live while | |||
both dormant and active. When an event of interest happens on the | both dormant and active. When an event of interest happens on the | |||
managed resource, the Netconf server checks the list of dormant | managed resource, the Netconf server checks the list of dormant | |||
subscriptions and if the filtering parameters in the subscription | subscriptions and if the filtering parameters in the subscription | |||
indicate interest in the Notification resulting from the event, then | indicate interest in the Notification resulting from the event, then | |||
the Netconf server initiates the connection to the specific Netconf | the Netconf server initiates the connection to the specific Netconf | |||
client and sends the Notification. When the Notification has been | client and sends the Notification. When the Notification has been | |||
sent, the connection is terminated. | sent, the connection is terminated. | |||
A subscription is active when it is currently session between the | ||||
Netconf client and server related to this subscription on which | ||||
Notifications can be sent. A subscription is dormant when there is | ||||
currently no session set up between the Netconf client and server | ||||
related to this notification subscription. | ||||
7.1.1.1 Session Lifecycle | 7.1.1.1 Session Lifecycle | |||
In order to avoid situations in which a sessions is continuously | In order to avoid situations in which a sessions is continuously | |||
setup and torn down, an inactivity timer is configured on the server. | setup and torn down, an inactivity timer is configured on the server. | |||
The timeout interval value is the same for all sessions (i.e. system | The timeout interval value is the same for all sessions (i.e. system | |||
wide) and each session has its own timer. Upon expiration of the | wide) and each session has its own timer. Upon expiration of the | |||
inactivity timer, the connection is terminated, otherwise if activity | inactivity timer, the connection is terminated, otherwise if activity | |||
is detected, the timer is reset. | is detected, the timer is reset. | |||
[Editor's note: alternatives here were to either create and tear down | [Editor's note: alternatives here were to either create and tear down | |||
skipping to change at page 33, line 47 | skipping to change at page 37, line 4 | |||
The timeout interval value is the same for all sessions (i.e. system | The timeout interval value is the same for all sessions (i.e. system | |||
wide) and each session has its own timer. Upon expiration of the | wide) and each session has its own timer. Upon expiration of the | |||
inactivity timer, the connection is terminated, otherwise if activity | inactivity timer, the connection is terminated, otherwise if activity | |||
is detected, the timer is reset. | is detected, the timer is reset. | |||
[Editor's note: alternatives here were to either create and tear down | [Editor's note: alternatives here were to either create and tear down | |||
the session for each notification received or to have the server | the session for each notification received or to have the server | |||
somehow figure out that there are more notifications coming soon | somehow figure out that there are more notifications coming soon | |||
after it has sent a notification and therefore keeps the connection | after it has sent a notification and therefore keeps the connection | |||
up.] | up.] | |||
The session establishment procedure is as follows: | The session establishment procedure is as follows: | |||
1) The NETCONF server initiates a session using a recognized | 1) The NETCONF server checks to ensure there isn't already a suitable | |||
application protocol (SSH, Beep, SOAP, etc). In order to "activate" | notification session open. | |||
this reverse behaviour a new SSH subsystem may need to be defined. | ||||
2) The NETCONF server initiates a session using a recognized | ||||
transport protocol (SSH, Beep, SOAP, etc). In order to "activate" | ||||
this reverse behavior a new SSH subsystem may need to be defined. | ||||
This is for further study. In addition, the NE hosting the NETCONF | This is for further study. In addition, the NE hosting the NETCONF | |||
server must support both client and server modes in the case of SSH. | server must support both client and server modes in the case of SSH. | |||
2) Client and server are authenticated according to the underlying | 3) Client and server are authenticated according to the underlying | |||
application protocol (e.g. SSH, BEEP) | transport protocol (e.g. SSH, BEEP) | |||
3) If using BEEP, as described in [NETCONF-BEEP] either party may | 4) If using BEEP, as described in [NETCONF-BEEP] either party may | |||
initiate the BEEP session. Once this occurs, the assumption is that | initiate the BEEP session. Once this occurs, the assumption is that | |||
both parties know their roles. At this point, the NETCONF client, | both parties know their roles. At this point, the NETCONF client, | |||
initiates NETCONF session establishment whether running SSH or BEEP. | initiates NETCONF session establishment whether running SSH or BEEP. | |||
7.1.2 Dependencies | 7.1.2 Dependencies | |||
This feature is dependant on the named profiles concept from the | This feature is dependant on the named profiles concept from the | |||
normal subscription method as well as the definition of | normal subscription method as well as the definition of | |||
<notification>. | <notification>. | |||
skipping to change at page 34, line 38 | skipping to change at page 37, line 45 | |||
7.1.3.1 New Operations | 7.1.3.1 New Operations | |||
7.1.3.1.1 New Data Model | 7.1.3.1.1 New Data Model | |||
<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= | targetNamespace= | |||
"urn:ietf:params:xml:ns:netconf:callHomeSubscription:1.0" | "urn:ietf:params:xml:ns:netconf:callHomeSubscription: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:event:1.0" | xmlns:ncEvent= "urn:ietf:params:xml:ns:netconf:notification:1.0" | |||
xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" | xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0" | |||
elementFormDefault="qualified" | elementFormDefault="qualified" | |||
attributeFormDefault="unqualified" xml:lang="en"> | attributeFormDefault="unqualified" xml:lang="en"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
Schema for reporting on dormant Call-Home Notification | Schema for reporting on dormant Call-Home Notification | |||
Subscriptions | Subscriptions | |||
</xs:documentation> | </xs:documentation> | |||
<xs:appinfo> | <xs:appinfo> | |||
<nm:identity | <nm:identity | |||
skipping to change at page 35, line 27 | skipping to change at page 38, line 35 | |||
<xs:element name="callHomeSubscription"> | <xs:element name="callHomeSubscription"> | |||
<xs:annotation> | <xs:annotation> | |||
<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:complexType> | <xs:complexType> | |||
<xs:sequence> | <xs:sequence> | |||
<xs:element name="subscriber" type="xs:string"> | <xs:element name="subscriber" > | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation> | <xs:documentation> | |||
This needs to be replaced with a more | The Netconf client that is subscribed to | |||
prescriptive data type | receive these notifications as part of | |||
the call-home subscription. | ||||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
<xs:complexType> | ||||
<xs:sequence> | ||||
<xs:element type="ip:IPAddressOrSysname" | ||||
name="iPAddressOrSysname"/> | ||||
<xs:element type="xs:integer" name="port"/> | ||||
</xs:sequence> | ||||
</xs:complexType> | ||||
</xs:element> | </xs:element> | |||
<xs:element name="namedProfile" | <xs:element name="namedProfile" | |||
type="xs:string" minOccurs="0"> | type="xs:string" minOccurs="0"> | |||
<xs:annotation> | <xs:annotation> | |||
<xs:documentation xml:lang="en"> | <xs:documentation xml:lang="en"> | |||
The named profile associated with this | The named profile associated with this | |||
subscription. Note that the | subscription. Note that the | |||
contents of the named profile may have | contents of the named profile may have | |||
changed since it was last applied | changed since it was last applied | |||
</xs:documentation> | </xs:documentation> | |||
</xs:annotation> | </xs:annotation> | |||
skipping to change at page 39, line 5 | skipping to change at page 42, line 10 | |||
To be determined once specific aspects of this solution are better | To be determined once specific aspects of this solution are better | |||
understood. In particular, the access control framework and the | understood. In particular, the access control framework and the | |||
choice of transport will have a major impact on the security of the | choice of transport will have a major impact on the security of the | |||
solution | solution | |||
9. IANA Considerations | 9. IANA Considerations | |||
Event Classes will likely be an IANA-managed resource. The initial | Event Classes will likely be an IANA-managed resource. The initial | |||
set of values is defined in this specification. | set of values is defined in this specification. | |||
In order for new event classes to be allocated, the following | ||||
requirements must be met: | ||||
o There must be working group consensus to add the new class | ||||
o A detailed description of its purpose in the netconf protocol must | ||||
be provided | ||||
o A detailed description of all manager and agent implementation | ||||
requirements associated with the event class must be provided | ||||
o The description must make clear to developers how to determine | ||||
when it is appropriate to choose this event classification for a | ||||
new notification type | ||||
list | ||||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Gilbert Gagnon and Greg Wilbur for providing their input | Thanks to Gilbert Gagnon and Greg Wilbur for providing their input | |||
into the early work on this document. In addition, the editors would | into the early work on this document. In addition, the editors would | |||
like to acknowledge input at the Vancouver editing session from the | like to acknowledge input at the Vancouver editing session from the | |||
following people: Orly Nicklass, James Bakstrieve, Yoshifumi | following people: Orly Nicklass, James Bakstrieve, Yoshifumi | |||
Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave | Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave | |||
Partain, Ray Atarashi and Dave Perkins. | Partain, Ray Atarashi and Dave Perkins. In addition, they would like | |||
to thank Balazs Lengyel his contributions to the event class text. | ||||
11. References | 11. 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. | |||
skipping to change at page 52, line 5 | skipping to change at page 56, line 5 | |||
in which it wants the NETCONF server to issue the event notifications | in which it wants the NETCONF server to issue the event notifications | |||
at subscription time by specifying the appropriate namespace under | at subscription time by specifying the appropriate namespace under | |||
the Filter parameter in the <create-subscription> operation. An | the Filter parameter in the <create-subscription> operation. An | |||
example is provided below: | example is provided below: | |||
<netconf:filter> | <netconf:filter> | |||
<data-format:config-format-xml | <data-format:config-format-xml | |||
xmlns="http://www.example.com/xmlnetevents"/> | xmlns="http://www.example.com/xmlnetevents"/> | |||
</netconf:filter> | </netconf:filter> | |||
Appendix D. IP Address Schema | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<!-- IETF Netconf Working Group | ||||
http://www.ietf.org/html.charters/netconf-charter.html | ||||
--> | ||||
<xs:schema elementFormDefault="qualified" | ||||
attributeFormDefault="unqualified" version="0.2" | ||||
xmlns:xs="http://www.w3.org/2001/XMLSchema" | ||||
xmlns="urn:ietf:params:xml:ns:netmod:ipAddress:1.0" | ||||
targetNamespace="urn:ietf:params:xml:ns:netmod:ipAddress:1.0"> | ||||
<xs:simpleType name = "ipV4Addr"> | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
An IP version 4 address in dotted notation decimal. | ||||
Example: 15.13.120.22 | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
<xs:restriction base = "xs:string"> | ||||
<xs:pattern value = | ||||
"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"/> | ||||
</xs:restriction> | ||||
</xs:simpleType> | ||||
<xs:simpleType name = "ipV6Addr"> | ||||
<xs:annotation> | ||||
<xs:documentation> | ||||
An IP version 6 address in colon separated 2 byte | ||||
block hexadecimal notation. | ||||
Example: FEDC:AB19:12FE:0234:98EF:1178:8891:CAFF | ||||
</xs:documentation> | ||||
</xs:annotation> | ||||
<xs:restriction base = "xs:string"> | ||||
<xs:pattern value = | ||||
"[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}: | ||||
[0-9a-fA-F]{4}:[0-9a-fA-F]{4}: | ||||
[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}"/> | ||||
</xs:restriction> | ||||
</xs:simpleType> | ||||
<xs:complexType name="IPAddressOrSysname"> | ||||
<xs:choice> | ||||
<xs:element name="ipv4Address" type="ipV4Addr"/> | ||||
<xs:element name="ipv6Address" type="ipV6Addr"/> | ||||
<xs:element name="sysName" type="xs:string"/> | ||||
</xs:choice> | ||||
</xs:complexType> | ||||
</xs:schema> | ||||
Intellectual Property Statement | Intellectual Property Statement | |||
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. | |||
End of changes. 65 change blocks. | ||||
158 lines changed or deleted | 399 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |