draft-ietf-netconf-notification-12.txt   draft-ietf-netconf-notification-13.txt 
Network Working Group S. Chisholm Network Working Group S. Chisholm
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track H. Trevino Intended status: Standards Track H. Trevino
Expires: August 28, 2008 Cisco Expires: November 30, 2008 Cisco
February 25, 2008 May 29, 2008
NETCONF Event Notifications NETCONF Event Notifications
draft-ietf-netconf-notification-12.txt draft-ietf-netconf-notification-13.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 August 28, 2008. This Internet-Draft will expire on November 30, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines mechanisms that provide an asynchronous message This document defines mechanisms that provide an asynchronous message
notification delivery service for the NETCONF protocol. This is an notification delivery service for the NETCONF protocol. This is an
optional capability built on top of the base NETCONF definition. optional capability built on top of the base NETCONF definition.
skipping to change at page 2, line 45 skipping to change at page 2, line 45
3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 16 3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 16
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2. Creating a Subscription with Replay . . . . . . . . . 17 3.3.2. Creating a Subscription with Replay . . . . . . . . . 17
3.4. Notification Management Schema . . . . . . . . . . . . . . 17 3.4. Notification Management Schema . . . . . . . . . . . . . . 17
3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 21 3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 21
3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 21 3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 21
3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 21 3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21 3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 24 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 24
5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 28 5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 32 5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 31
5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 33 5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 32
6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 35 6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 34
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 35 6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 34
6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 35 6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 34
6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 35 6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 34
6.5. Modifications to Existing Operations . . . . . . . . . . . 35 6.5. Modifications to Existing Operations . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
10. Normative References . . . . . . . . . . . . . . . . . . . . . 39 10. Normative References . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40
A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 40
A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 42
A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44 A.4. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44
A.5. Vesrion -12 . . . . . . . . . . . . . . . . . . . . . . . 45 A.5. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 A.6. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
[NETCONF] can be conceptually partitioned into four layers: [NETCONF] can be conceptually partitioned into four layers:
Layer Example Layer Example
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| Content | | Configuration data | | Content | | Configuration data |
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| | | |
skipping to change at page 7, line 52 skipping to change at page 7, line 52
Start Time: Start Time:
A parameter, <startTime>, used to trigger the replay feature A parameter, <startTime>, used to trigger the replay feature
and indicate that the replay should start at the time and indicate that the replay should start at the time
specified. If <startTime> is not present, this is not a replay specified. If <startTime> is not present, this is not a replay
subscription. It is not valid to specify start times that are subscription. It is not valid to specify start times that are
later than the current time. If the <startTime> specified is later than the current time. If the <startTime> specified is
earlier than the log can support, the replay will begin with earlier than the log can support, the replay will begin with
the earliest available notification. This parameter is of type the earliest available notification. This parameter is of type
dateTime. dateTime and compliant to [RFC3339]. Implementations must
support time zones.
Stop Time: Stop Time:
An optional parameter, <stopTime>, used with the optional An optional parameter, <stopTime>, used with the optional
replay feature to indicate the newest notifications of replay feature to indicate the newest notifications of
interest. If stop time is not present, the notifications will interest. If stop time is not present, the notifications will
continue until the subscription is terminated. Must be used continue until the subscription is terminated. Must be used
with and be later than <startTime>. Values of <stopTime> in with and be later than <startTime>. Values of <stopTime> in
the future are valid. This parameter is of type dateTime. the future are valid. This parameter is of type dateTime and
compliant to [RFC3339]. Implementations must support time
zones.
Positive Response: Positive Response:
If the NETCONF server can satisfy the request, the server sends an If the NETCONF server can satisfy the request, the server sends an
<ok> element. <ok> element.
Negative Response: Negative Response:
An <rpc-error> element is included within the <rpc-reply> if the An <rpc-error> element is included within the <rpc-reply> if the
request cannot be completed for any reason. Subscription requests request cannot be completed for any reason. Subscription requests
skipping to change at page 10, line 27 skipping to change at page 10, line 27
occurred. An event notification is a complete and well-formed XML occurred. An event notification is a complete and well-formed XML
document. Note that <notification> is not an RPC method but document. Note that <notification> is not an RPC method but
rather the top level element identifying the one-way message as a rather the top level element identifying the one-way message as a
notification. notification.
Parameters: Parameters:
eventTime eventTime
The time the event was generated by the event source. This The time the event was generated by the event source. This
parameter is of type dateTime. parameter is of type dateTime and compliant to [RFC3339].
Implementations must support time zones.
Also contains notification-specific tagged content, if any. With Also contains notification-specific tagged content, if any. With
the exception of <eventTime>, the content of the notification is the exception of <eventTime>, the content of the notification is
beyond the scope of this document. beyond the scope of this document.
Response: Response:
No response. Not applicable. No response. Not applicable.
2.3. Terminating the Subscription 2.3. Terminating the Subscription
skipping to change at page 11, line 39 skipping to change at page 11, line 39
</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 as a set of event notifications matching An event stream is defined as a set of event notifications matching
some forwarding criteria. some forwarding criteria.
Figure 2 illustrates the notification flow and concepts identified in Figure 2 illustrates the notification flow and concepts identified in
this document. The following is observed from the diagram below: this document. It does not mandate and/or preclude an
implementation. The following is observed from the diagram below:
System components (c1..cn) generate event notifications which are System components (c1..cn) generate event notifications which are
passed to a central component for classification and distribution. passed to a central component for classification and distribution.
The central component inspects each event notification and matches The central component inspects each event notification and matches
the event notification against the set of stream definitions. When a the event notification against the set of stream definitions. When a
match occurs, the event notification is considered to be a member of match occurs, the event notification is considered to be a member of
that event stream (stream 1..stream n). An event notification may be that event stream (stream 1..stream n). An event notification may be
part of multiple event streams. part of multiple event streams.
At some point after the NETCONF server receives the internal event At some point after the NETCONF server receives the internal event
from a stream, it is converted to an appropriate XML encoding by the from a stream, it is converted to an appropriate XML encoding by the
skipping to change at page 16, line 39 skipping to change at page 16, line 39
notifications are sent the same way as normal notifications. notifications are sent the same way as normal notifications.
A replay of notifications is specified by including the optional A replay of notifications is specified by including the optional
<startTime> parameter to the subscription command, which indicates <startTime> parameter to the subscription command, which indicates
the start time of the replay. The end time is specified using the the start time of the replay. The end time is specified using the
optional <stopTime> parameter. If not present, notifications will optional <stopTime> parameter. If not present, notifications will
continue to be sent until the subscription is terminated. continue to be sent until the subscription is terminated.
A notification stream that supports replay is not expected to have an A notification stream that supports replay is not expected to have an
unlimited supply of saved notifications available to accommodate any unlimited supply of saved notifications available to accommodate any
replay request. replay request. Clients can query <replayLogCreationTime> and
<replayLogAgedTime> to learn about the availability of notifications
for replay.
The actual number of stored notifications available for retrieval at The actual number of stored notifications available for retrieval at
any given time is a NETCONF server implementation specific matter. any given time is a NETCONF server implementation specific matter.
Control parameters for this aspect of the feature are outside the Control parameters for this aspect of the feature are outside the
scope of this document. scope of this document.
Replay is dependent on a notification stream supporting some form of Replay is dependent on a notification stream supporting some form of
notification logging, although it puts no restrictions on the size or notification logging, although it puts no restrictions on the size or
form of the log, or where it resides within the device. Whether or form of the log, or where it resides within the device. Whether or
not a stream supports replay can be discovered by doing a <get> not a stream supports replay can be discovered by doing a <get>
skipping to change at page 17, line 22 skipping to change at page 17, line 24
replay of notifications. Events generated before this time are not replay of notifications. Events generated before this time are not
matched. <stopTime> specifies the latest date and time of interest matched. <stopTime> specifies the latest date and time of interest
for event notifications being replayed. If it is not present, then for event notifications being replayed. If it is not present, then
notifications will continue to be sent until the subscription is notifications will continue to be sent until the subscription is
terminated. terminated.
Note that <startTime> and <stopTime> are associated with the time an Note that <startTime> and <stopTime> are associated with the time an
event was generated by the event source. event was generated by the event source.
A <replayComplete> notification is sent to indicate that all of the A <replayComplete> notification is sent to indicate that all of the
replay notifications have been sent. If this subscription has a stop replay notifications have been sent and must not be sent for any
time, then this session becomes a normal NETCONF session again. When other reason. If this subscription has a stop time, then this
a <stopTime> has been specified, <notificationComplete> notification session becomes a normal NETCONF session again. The NETCONF server
is the last notification sent on the subscription before it will then accept <rpc> operations even if the server did not
terminates and the NETCONF session returns to being a normal NETCONF previously accept such operations due to lack of interleave support.
session. The NETCONF server will then accept <rpc> operations. In In the case of a subscription without a stop time, after the
the case of a subscription without a stop time, after the
<replayComplete> notification has been sent, it can be expected that <replayComplete> notification has been sent, it can be expected that
any notifications generated since the start of the subscription any notifications generated since the start of the subscription
creation will be sent, followed by notifications as they arise creation will be sent, followed by notifications as they arise
naturally within the system. naturally within the system.
The <replayComplete> and <notificationComplete> notifications cannot The <replayComplete> and <notificationComplete> notifications cannot
be filtered out. They will always be sent on a replay subscription be filtered out. They will always be sent on a replay subscription
that specified a startTime and stopTime respectively. that specified a startTime and stopTime respectively.
3.4. Notification Management Schema 3.4. Notification Management Schema
skipping to change at page 18, line 19 skipping to change at page 18, line 20
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
A schema that can be used to learn about current A schema that can be used to learn about current
event streams. It also contains the replayComplete event streams. It also contains the replayComplete
and notificationComplete notification. and notificationComplete notification.
</xs:documentation> </xs:documentation>
</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= schemaLocation="netconf.xsd"/>
"http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<xs:import namespace= <xs:import namespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0" "urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation= schemaLocation="notification.xsd"/>
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>
<!-- The above schemaLocation value is a placeholder and the actual <!-- The above schemaLocation value is a placeholder and the actual
value will be assigned by IANA --> value will be assigned by IANA -->
<xs:element name="netconf" type="manageEvent:Netconf"/> <xs:element name="netconf" type="manageEvent:Netconf"/>
<xs:complexType name="Netconf"> <xs:complexType name="Netconf">
<xs:sequence> <xs:sequence>
<xs:element name="streams" > <xs:element name="streams" >
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
skipping to change at page 21, line 20 skipping to change at page 21, line 19
</xs:schema> </xs:schema>
3.5. Subscriptions Data 3.5. Subscriptions Data
Subscriptions are non-persistent state information and their lifetime Subscriptions are non-persistent state information and their lifetime
is defined by their session or by the <stopTime> parameter. is defined by their session or by the <stopTime> parameter.
3.6. Filter Mechanics 3.6. Filter Mechanics
When multiple filter elements are specified, they are applied If a filter element is specified to look for data of a particular
collectively, so event notifications need to pass all specified value, and the data item is not present within a particular event
filter elements in order to be sent to the subscriber. If a filter notification for its value to be checked against, the notification
element is specified to look for data of a particular value, and the will be filtered out. For example, if one were to check for
data item is not present within a particular event notification for 'severity=critical' in a configuration event notification where this
its value to be checked against, the notification will be filtered field was not supported, then the notification would be filtered out.
out. For example, if one were to check for 'severity=critical' in a
configuration event notification where this field was not supported,
then the notification would be filtered out.
For subtree filtering, a non-empty node set means that the filter For subtree filtering, a non-empty node set means that the filter
matches. For XPath filtering, the mechanisms defined in [XPATH] matches. For XPath filtering, the mechanisms defined in [XPATH]
should be used to convert the returned value to boolean. should be used to convert the returned value to boolean.
3.6.1. Filtering 3.6.1. Filtering
Filtering is explicitly stated when the event notification Filtering is explicitly stated when the event notification
subscription is created. This is specified via the 'filter' subscription is created. This is specified via the 'filter'
parameter. A Filter only exist as a parameter to the subscription. parameter. A Filter only exists as a parameter to the subscription.
3.7. Message Flow 3.7. 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 to create a subscription and (C) and NETCONF server (S) in order to create a subscription and
begin the flow of notifications. This subscription specified a begin the flow of notifications. This subscription specified a
<startTime>, so the server starts by replaying logged notifications. <startTime>, so the server starts by replaying logged notifications.
It is possible that many rpc/rpc-reply sequences occur before the It is possible that many rpc/rpc-reply sequences occur before the
subscription is created, but this is not depicted in the figure. subscription is created, but this is not depicted in the figure.
C S C S
skipping to change at page 24, line 33 skipping to change at page 24, line 33
<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= schemaLocation="netconf.xsd"/>
"http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<!-- ************** Symmetrical Operations ********************--> <!-- ************** Symmetrical Operations ********************-->
<!-- <create-subscription> operation --> <!-- <create-subscription> operation -->
<xs:complexType name="createSubscriptionType"> <xs:complexType name="createSubscriptionType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="netconf:rpcOperationType"> <xs:extension base="netconf:rpcOperationType">
<xs:sequence> <xs:sequence>
<xs:element name="stream" <xs:element name="stream"
skipping to change at page 29, line 17 skipping to change at page 29, line 17
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://example.com/event/1.0" <xs:schema targetNamespace="http://example.com/event/1.0"
xmlns="http://example.com/event/1.0" xmlns="http://example.com/event/1.0"
elementFormDefault="qualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0">
<xs:import namespace= <xs:import namespace=
"urn:ietf:params:xml:ns:netconf:notification:1.0" "urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation= schemaLocation="notification.xsd"/>
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>
<xs:complexType name="eventType"> <xs:complexType name="eventType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType"> <xs:extension base="ncEvent:NotificationContentType">
<xs:sequence> <xs:sequence>
<xs:element name="eventClass" /> <xs:element name="eventClass" />
<xs:element name="reportingEntity"> <xs:element name="reportingEntity">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:any namespace="##any" <xs:any namespace="##any"
skipping to change at page 35, line 13 skipping to change at page 34, line 13
</netconf:rpc> </netconf:rpc>
6. Interleave Capability 6. Interleave Capability
6.1. Description 6.1. Description
The Interleave capability indicates that the NETCONF peer supports The Interleave capability indicates that the NETCONF peer supports
the ability to interleave other NETCONF operations within a the ability to interleave other NETCONF operations within a
Notification subscription. This means the NETCONF server MUST Notification subscription. This means the NETCONF server MUST
receive, process and respond to NETCONF requests on a session with an receive, process and respond to NETCONF requests on a session with an
active notification subscription. active notification subscription. This capability helps scalability
by reducing the total number of NETCONF sessions required by a given
operator or management application.
6.2. Dependencies 6.2. Dependencies
This capability is dependant on the notification capability being This capability is dependant on the notification capability being
supported. supported.
6.3. Capability Identifier 6.3. Capability Identifier
The :interleave capability is identified by the following capability The :interleave capability is identified by the following capability
string: string:
skipping to change at page 36, line 25 skipping to change at page 35, line 25
established, and the manager has been identified and authenticated. established, and the manager has been identified and authenticated.
It is recommended that care be taken to secure execution: It is recommended that care be taken to secure execution:
o <create-subscription> invocation o <create-subscription> invocation
o <get> on read-only data models o <get> on read-only data models
o <notification> content o <notification> content
Secure execution means ensuring that a secure transport is used as
well as ensuring that the user has sufficient authorization to
perform the function they are requesting against the specific subset
of NETCONF content involved. When a <get> is received that refers to
the content defined in this memo, clients should only be able to view
the content for which they have sufficient privileges. A create
<create-subscription> operation can be considered like a deferred
<get>, and the content that different users can access may vary.
This different access is reflected in the <notification> that
different users are able to subscribe to.
One potential security issue is the transport of data from non- One potential security issue is the transport of data from non-
NETCONF streams, such as syslog and SNMP. This data may be more NETCONF streams, such as syslog and SNMP. This data may be more
vulnerable (or less vulnerable) when being transported over NETCONF vulnerable (or less vulnerable) when being transported over NETCONF
than when being transported using the protocol normally used for than when being transported using the protocol normally used for
transporting it, depending on the security credentials of the two transporting it, depending on the security credentials of the two
subsystems. The NETCONF server is responsible for applying access subsystems. The NETCONF server is responsible for applying access
control to stream content. control to stream content.
The contents of notifications as well as the name of event streams The contents of notifications as well as the names of event streams
may contain sensitive information and care should be taken to ensure may contain sensitive information and care should be taken to ensure
that it is viewed only by authorized users. If a user does not have that they are viewed only by authorized users. If a user is not
permission to view content via other NETCONF operations, it must not authorized to view all elements in the content of the notification,
have access that content via Notifications. If a user is not the notification is not sent to that user.
permitted to view one element in the content of the notification, the
notification is not sent to that user.
If a subscription is created with a <stopTime>, the NETCONF session If a subscription is created with a <stopTime>, the NETCONF session
will return to being a normal command-response NETCONF session when will return to being a normal command-response NETCONF session when
the replay is completed. It is the responsibility of the NETCONF the replay is completed. It is the responsibility of the NETCONF
client to close this session when it is no longer of use. client to close this session when it is no longer of use.
8. IANA Considerations 8. IANA Considerations
-- Editor note to IANA/RFC-Editor: we request that you make these -- Editor note to IANA/RFC-Editor: we request that you make these
assignments, in which case it is to be documented as below assignments, in which case it is to be documented as below
skipping to change at page 39, line 13 skipping to change at page 39, line 13
well as Suresh Krishnan for his gen-art review of the document. well as Suresh Krishnan for his gen-art review of the document.
10. Normative References 10. Normative References
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January [RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[XML] World Wide Web Consortium, "Extensible Markup Language [XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998, (XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML Schema] [XML Schema]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C http:/ "XML Schema Part 1: Structures Second Edition", W3C http:/
skipping to change at page 45, line 7 skipping to change at page 45, line 7
5. Fixed typos and made minor edits. 5. Fixed typos and made minor edits.
A.4. Version -11 A.4. Version -11
1. Fixed namespaces 1. Fixed namespaces
2. In section 6.5, fixed error message Error-info 2. In section 6.5, fixed error message Error-info
3. In section 6.1 clarify that if the interleave capability is 3. In section 6.1 clarify that if the interleave capability is
supported, then the server must respond to requests. supported, then the server must respond to requests.
A.5. Vesrion -12 A.5. Version -12
1. Add to section 1.3 the clarification "Note that a subscription 1. Add to section 1.3 the clarification "Note that a subscription
cannot be modified once created." cannot be modified once created."
2. In section 2.2.1, in the description of eventTime, added the 2. In section 2.2.1, in the description of eventTime, added the
following text: "This parameter is of type dateTime." following text: "This parameter is of type dateTime."
3. Fixed several typos. 3. Fixed several typos.
4. Added the following text to the IANA considerations section: "-- 4. Added the following text to the IANA considerations section: "--
skipping to change at page 46, line 5 skipping to change at page 45, line 36
6. Add instructions to RFC editor to remove change log before 6. Add instructions to RFC editor to remove change log before
publication publication
7. Added IANA registration item for http://www.iana.org/assignments/ 7. Added IANA registration item for http://www.iana.org/assignments/
xml-registry/schema/notification.xsd xml-registry/schema/notification.xsd
8. Clarified in the IANA considerations section that the capability 8. Clarified in the IANA considerations section that the capability
URIs were complaint to RFC4741 section 10.3 URIs were complaint to RFC4741 section 10.3
A.6. Version -13
1. In section 2.1.1, for both instances and in section 2.2.1,
replaced "This parameter is of type dateTime." With "This
parameter is of type dateTime and compliant to [RFC3339]."
2. In the normative reference section, added the following
reference [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time
on the Internet: Timestamps", RFC 3339, July 2002.
3. In section 2.1.1, for both instances and in section 2.2.1, added
the following after the text \ indicating that the time fields
are dateTime (this covers eventTime, startTime and stopTime).
"Implementations must support time zones."
4. In Section 3.6.1 "parameter. A Filter only exist as a parameter
to the subscription." s/exist/exists/
5. In Section 7: Replaced second last paragraph with "The contents
of notifications as well as the names of event streams may
contain sensitive information and care should be taken to ensure
that they are viewed only by authorized users. If a user is not
authorized to view all elements in the content of the
notification, the notification is not sent to that user."
6. In section 3.3.2, replaced "The NETCONF server will then accept
<rpc> operations." With "The NETCONF server will then accept
<rpc> operations even if the server did not previously accept
such operations due to lack of interleave support."
7. In section 3.3.2, replaced "A <replayComplete> notification is
sent to indicate that all of the replay notifications have been
sent. If this subscription has a stop time, then this session
becomes a normal NETCONF session again. When a <stopTime> has
been specified, <notificationComplete> notification is the last
notification sent on the subscription before it terminates and
the NETCONF session returns to being a normal NETCONF session."
With "A <replayComplete> notification is sent to indicate that
all of the replay notifications have been sent. When a
<stopTime> has been specified, <notificationComplete>
notification is the last notification sent on the subscription
before it terminates and the NETCONF session returns to being a
normal NETCONF session. "
8. In section 3.3.2, replaced, "A <replayComplete> notification is
sent to indicate that all of the replay notifications have been
sent." With "A <replayComplete> notification is sent to
indicate that all of the replay notifications have been sent and
must not be sent for any other reason."
9. In section 3.3.1, replaced "A notification stream that supports
replay is not expected to have an unlimited supply of saved
notifications available to accommodate any replay request."
With "A notification stream that supports replay is not expected
to have an unlimited supply of saved notifications available to
accommodate any replay request. Clients can query
<replayLogCreationTime> and <replayLogAgedTime> to learn about
the availability of notifications for replay."
10. In section 3.2, replaced "Figure 2 illustrates the notification
flow and concepts identified in this document." With "Figure 2
illustrates the notification flow and concepts identified in
this document. It does not mandate and/or preclude an
implementation."
11. In section 6.1, added the following text "This capability helps
scalability by reducing the total number of NETCONF sessions
required by a given operator or management application."
12. In section 3.6, deleted "When multiple filter elements are
specified, they are applied collectively, so event notifications
need to pass all specified filter elements in order to be sent
to the subscriber. "
13. In section 7 (Security Considerations) after the bullets added
the following: Secure execution means ensuring that a secure
transport is used as well as ensuring that the user has
sufficient authorization to perform the function they are
requesting against the specific piece of NETCONF content
involved. When a <get> is received against the content defined
in this memo, clients should only be able to view the content
for which they have sufficient privileges. A create <create-
subscription> operation can be considered like a deferred <get>,
and the content that different users can access may vary. This
different access is reflected in the <notification> that
different users are able to subscribe to.
14. Updated import statements to not used fully qualified URLs.
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
 End of changes. 24 change blocks. 
54 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/