draft-ietf-netconf-netconf-event-notifications-04.txt   draft-ietf-netconf-netconf-event-notifications-05.txt 
NETCONF A. Gonzalez Prieto NETCONF A. Gonzalez Prieto
Internet-Draft VMware Internet-Draft VMware
Intended status: Standards Track A. Clemm Intended status: Standards Track A. Clemm
Expires: January 4, 2018 Huawei Expires: April 5, 2018 Huawei
E. Voit E. Voit
E. Nilsen-Nygaard E. Nilsen-Nygaard
A. Tripathy A. Tripathy
Cisco Systems Cisco Systems
July 3, 2017 October 2, 2017
NETCONF Support for Event Notifications NETCONF Support for Event Notifications
draft-ietf-netconf-netconf-event-notifications-04 draft-ietf-netconf-netconf-event-notifications-05
Abstract Abstract
This document defines how to transport network subscriptions and This document defines how to transport network subscriptions and
event messages on top of the Network Configuration protocol event messages on top of the Network Configuration protocol
(NETCONF). This includes the full set of RPCs, subscription state (NETCONF). This includes the full set of RPCs, subscription state
changes, and message payloads needing asynchronous delivery. The changes, and subscribed content needing asynchronous delivery.
capabilities and operations defined in this document used in
conjunction with [subscribe] are intended to obsolete [RFC5277]. In
addition, the capabilities within those two documents along with
[yang-push] are intended to enable an extract of a YANG datastore on
a remote device.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on April 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 3 3.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 3
3.2. Mandatory NETCONF support . . . . . . . . . . . . . . . . 4 3.2. Mandatory NETCONF support . . . . . . . . . . . . . . . . 4
3.3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 5 3.3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 4
3.4. Configured Subscriptions . . . . . . . . . . . . . . . . 12 3.4. Configured Subscriptions . . . . . . . . . . . . . . . . 11
4. Interleave Capability . . . . . . . . . . . . . . . . . . . . 25 4. Interleave Capability . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Open Items . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Open Items . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Changes between revisions . . . . . . . . . . . . . 28 Appendix B. Changes between revisions . . . . . . . . . . . . . 26
B.1. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 28 B.1. v04 to v05 . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 28 B.2. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 26
B.3. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 28 B.3. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 B.4. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document defines mechanisms that provide an asynchronous message This document defines mechanisms that provide a subscription and
notification delivery service for the NETCONF protocol [RFC6241] asynchronous message notification delivery service for the NETCONF
based on [subscribe]. This is an optional capability built on top of protocol [RFC6241] based on [subscribe]. This is an optional
the base NETCONF definition. capability built on top of the base NETCONF definition.
The document [subscribe] plus this transport specification document
provides a superset of the capabilities previously defined in
[RFC5277]. Newly introduced capabilities include the ability to have
multiple subscriptions on a single NETCONF session, the ability to
terminate subscriptions without terminating the client session, and
the ability to modify existing subscriptions.
In addition, [yang-push] plus the capabilities of this document
provide a mechanism for a NETCONF client to maintain a subset/extract
of an actively changing YANG datastore.
2. Terminology 2. Terminology
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms are defined in [RFC6241]: client, server, The following terms are defined in [RFC6241]: client, server,
operation, RPC. operation, RPC.
The following terms are defined in [subscribe]: event, event The following terms are defined in [subscribe]: event, event
notification, stream, publisher, receiver, subscriber, subscription, notification, stream, publisher, receiver, subscriber, subscription,
configured subscription. configured subscription.
Note that a publisher in [subscribe] corresponds to a server in Note that a publisher in [subscribe] corresponds to a server in
[RFC6241]. Similarly, a subscriber corresponds to a client. A [RFC6241]. Similarly, a subscriber corresponds to a client. A
receiver is also a client. In the remainder of this document, we receiver is also a client. In the remainder of this document, we
will use the terminology in [RFC6241] to simplify [subscribe]'s will use the terminology in [RFC6241].
mental mappings to embedded NETCONF terminology.
3. Solution 3. Solution
In this section, we describe and exemplify how [subscribe] is to be In this section, we describe and exemplify how [subscribe] is to be
supported over NETCONF. supported over NETCONF.
3.1. Event Stream Discovery 3.1. Event Stream Discovery
In the context of [subscribe] an event stream exposes a continuous In the context of [subscribe] an event stream exposes a continuous
set of events available for subscription. A NETCONF client can set of events available for subscription. A NETCONF client can
retrieve the list of available event streams from a NETCONF server retrieve the list of available event streams from a NETCONF server
using the "get" operation against the top-level container "/streams" using the "get" operation against the top-level container "/streams"
defined in [subscribe]. The reply includes the stream identities defined in [subscribe]. The reply includes the list of streams
supported on the NETCONF server. supported on the NETCONF server.
The following example illustrates the retrieval of the list of The following example illustrates the retrieval of the list of
available event streams using the <get> operation. available event streams using the <get> operation.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get> <get>
<filter type="subtree"> <filter type="subtree">
<streams <streams
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"/> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"/>
</filter> </filter>
</get> </get>
</rpc> </rpc>
Figure 1: Get streams request Figure 1: Get streams request
The NETCONF server returns a list of event streams available. In The NETCONF server returns a list of event streams available. In
this example, the list contains the NETCONF, SNMP, and SYSLOG this example, the list contains the NETCONF, SNMP, and SYSLOG
streams. streams.
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<streams <streams
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<stream>NETCONF</stream> <stream>
<stream>SNMP</stream> <stream>NETCONF</stream>
<stream>SYSLOG</stream> <description>The NETCONF mandatory event stream</description>
</streams> </stream>
</data> <stream>
</rpc-reply> <stream>SNMP</stream>
<description>The SNMP event stream</description>
</stream>
<stream>
<stream>SYSLOG</stream>
<description>The SYSLOG event stream</description>
<replay-support/>
<replay-log-creation-time>
2015-03-09T19:14:55.233Z</replay-log-creation-time>
</stream>
</streams>
</data>
</rpc-reply>
Figure 2: Get streams response Figure 2: Get streams response
For [yang-push], a similar get is needed to retrieve available For [yang-push], a similar get is needed to retrieve available
datastore names. datastore names.
3.2. Mandatory NETCONF support 3.2. Mandatory NETCONF support
A NETCONF server implementation supporting [subscribe] must support A NETCONF server implementation supporting [subscribe] must support
dynamic subscriptions and the "NETCONF" notification event stream. dynamic subscriptions and the "NETCONF" notification event stream.
The NETCONF event stream contains all NETCONF XML event information The NETCONF event stream contains all NETCONF XML event information
supported by the server, except for where it has been explicitly supported by the server.
indicated that this the event must be excluded from the NETCONF
stream.
A NETCONF server implementation supporting [yang-push] must support A NETCONF server implementation supporting [yang-push] must support
the "running" datastore. the "running" datastore.
3.3. Dynamic Subscriptions 3.3. Dynamic Subscriptions
3.3.1. Establishing Dynamic Subscriptions 3.3.1. Establishing Dynamic Subscriptions
The dynamic subscription RFC and interactions operation is defined in The dynamic subscription RFC and interactions operation is defined in
[subscribe]. [subscribe].
3.3.1.1. Usage Example 3.3.1.1. Usage Example
An example of interactions over NETCONF transport for one sample An example of interactions over NETCONF transport for one sample
subscription is below: subscription is below:
<netconf:rpc netconf:message-id="102" <netconf:rpc netconf:message-id="102"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription <establish-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<stream>NETCONF</stream> <stream>NETCONF</stream>
<event-filter-type>xpath</event-filter-type> <event-filter-type>xpath-event-filter</event-filter-type>
<event-filter> xmlns:ex="http://example.com/event/1.0" <event-filter-contents xmlns:ex="http://example.com/event/1.0"
select="/ex:event[ex:eventClass='fault' and select="/ex:event[ex:eventClass='fault' and
(ex:severity='minor' or ex:severity='major' (ex:severity='minor' or ex:severity='major'
or ex:severity='critical')]" or ex:severity='critical')]" />
</event-filter>
</establish-subscription> </establish-subscription>
</netconf:rpc> </netconf:rpc>
Figure 3: establish-subscription over NETCONF Figure 3: establish-subscription over NETCONF
3.3.1.2. Positive Response 3.3.1.2. Positive Response
If the NETCONF server can satisfy the request, the server sends a If the NETCONF server can satisfy the request, the server sends a
positive <subscription-result> element, and the subscription-id of positive <subscription-result> element, and the subscription-id of
the accepted subscription. the accepted subscription.
<rpc-reply message-id="102" <rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-result <subscription-result
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
ok ok
</subscription-result> </subscription-result>
<identifier <identifier
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
52 52
</identifier> </identifier>
</rpc-reply> </rpc-reply>
Figure 4: Successful establish-subscription Figure 4: Successful establish-subscription
3.3.1.3. Negative Response 3.3.1.3. Negative Response
If the NETCONF server cannot satisfy the request, or client has no If the NETCONF server cannot satisfy the request, or the client has
authorization to establish the subscription, the server will send a no authorization to establish the subscription, the server will send
negative <subscription-result> element. For instance: a negative <subscription-result> element. For instance:
<rpc-reply message-id="103" <rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-result <subscription-result
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
stream-unavailable stream-unavailable
</subscription-result> </subscription-result>
</rpc-reply> </rpc-reply>
Figure 5: Unsuccessful establish subscription Figure 5: Unsuccessful establish subscription
3.3.1.4. Subscription Negotiation 3.3.1.4. Subscription Negotiation
If the client requests parameters the NETCONF server cannot serve, If the client request includes parameters the NETCONF server cannot
the negative <subscription-result> may include hints at subscription serve, the negative <subscription-result> may include hints at
parameters which would have been accepted. For instance, consider subscription parameters which would have been accepted. For
the following subscription from [yang-push], which augments the instance, consider the following subscription from [yang-push], which
establish-subscription with some additional parameters, including augments the establish-subscription with some additional parameters,
"period". If the client requests a period which the NETCONF server including "period". If the client requests a period which the
cannot serve, the back-and-forth exchange may be: NETCONF server cannot serve, the back-and-forth exchange may be:
<netconf:rpc message-id="101" <netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription <establish-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<stream>push-update</stream> <datastore>running</datastore>
<event-filter-type>subtree</event-filter-type> <event-filter-type>
<event-filter>xmlns:ex="http://example.com/sample-data/1.0" subtree</event-filter-type>
select="/ex:foo"</event-filter> <event-filter-contents
<period xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"> xmlns:ex="http://example.com/sample-data/1.0">
500 select="/ex:foo" />
</period> <dampening-period>10</dampening-period>
<encoding>encode-xml</encoding> <encoding>encode-xml</encoding>
</establish-subscription> </establish-subscription>
</netconf:rpc> </netconf:rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-result <subscription-result
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
error-insufficient-resources error-insufficient-resources
</subscription-result> </subscription-result>
<period <period-hint
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
2000 2000
</period> </period-hint>
</rpc-reply> </rpc-reply>
Figure 6: Subscription establishment negotiation Figure 6: Subscription establishment negotiation
3.3.1.5. Message Flow Examples 3.3.1.5. Message Flow Examples
+------------+ +-----------+ +------------+ +-----------+
| Client | | Server | | Client | | Server |
+------------+ +-----------+ +------------+ +-----------+
| | | |
| Capability Exchange | | Capability Exchange |
|<---------------------------->| |<---------------------------->|
| | | |
| | | |
| Establish Subscription | | Establish Subscription |
|----------------------------->| |----------------------------->|
skipping to change at page 8, line 39 skipping to change at page 7, line 42
| Notification (id 23) | | Notification (id 23) |
|<-----------------------------| |<-----------------------------|
| | | |
| | | |
Figure 7: Multiple subscription establishments over a single NETCONF Figure 7: Multiple subscription establishments over a single NETCONF
session session
3.3.2. Modifying a Subscription 3.3.2. Modifying a Subscription
This operation is defined in [subscribe] and enhanced in [yang-push]. This operation is defined in [subscribe].
3.3.2.1. Usage Example 3.3.2.1. Usage Example
The following demonstrates modifying a subscription. Consider a The following demonstrates modifying a subscription. Consider a
subscription from [yang-push], which augments the establish- subscription from [yang-push], which augments the establish-
subscription with some additional parameters, including "period". A subscription with some additional parameters, including "period". A
subscription may be established and modified as follows. subscription may be established and modified as follows.
<netconf:rpc message-id="101" <netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription <establish-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">running</datastore> <datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<event-filter-type>subtree</event-filter-type> running</datastore>
<event-filter>xmlns:ex="http://example.com/sample-data/1.0" <event-filter-type>subtree-event-filter</event-filter-type>
select="/ex:foo"</event-filter> <event-filter-contents
<period xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"> xmlns:ex="http://example.com/sample-data/1.0">
1000 select="/ex:foo" />
</period> <period xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
</establish-subscription> 1000
</netconf:rpc> </period>
</establish-subscription>
</netconf:rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-result <subscription-result
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
ok ok
</subscription-result> </subscription-result>
<identifier <identifier
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
1922 1922
</identifier> </identifier>
</rpc-reply> </rpc-reply>
<netconf:rpc message-id="102" <netconf:rpc message-id="102"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<modify-subscription <modify-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<identifier>1922</identifier> <identifier>1922</identifier>
<period>100</period> <period>100</period>
</modify-subscription> </modify-subscription>
</netconf:rpc> </netconf:rpc>
Figure 8: Subscription modification Figure 8: Subscription modification
3.3.2.2. Positive Response 3.3.2.2. Positive Response
If the NETCONF server can satisfy the request, the server sends a If the NETCONF server can satisfy the request, the server sends a
positive <subscription-result> element. This response is like that positive <subscription-result> element. This response is like that
to an establish-subscription request, but without the subscription to an establish-subscription request, but without the subscription
identifier. identifier.
<rpc-reply message-id="102" <rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<subscription-result <subscription-result
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
ok ok
</subscription-result> </subscription-result>
</rpc-reply> </rpc-reply>
Figure 9: Successful modify subscription Figure 9: Successful modify subscription
3.3.2.3. Negative Response 3.3.2.3. Negative Response
If the NETCONF server cannot satisfy the request, the server sends a If the NETCONF server cannot satisfy the request, the server sends a
negative <subscription-result> element. Its contents and semantics negative <subscription-result> element. Its contents and semantics
are identical to those in an establish-subscription request. For are identical to those in an establish-subscription request. For
instance: instance:
skipping to change at page 11, line 12 skipping to change at page 10, line 12
3.3.2.4. Message Flow Example 3.3.2.4. Message Flow Example
+------------+ +-----------+ +------------+ +-----------+
| Client | | Server | | Client | | Server |
+------------+ +-----------+ +------------+ +-----------+
| | | |
| Capability Exchange | | Capability Exchange |
|<---------------------------->| |<---------------------------->|
| | | |
| Establish Subscription | | Establish Subscription |
|<---------------------------->| |----------------------------->|
| RPC Reply: OK, id = 22 |
|<-----------------------------|
| | | |
| Notification (id 22) | | Notification (id 22) |
|<-----------------------------| |<-----------------------------|
| | | |
| Modify Subscription | | Modify Subscription (id 22) |
|----------------------------->| |----------------------------->|
| RPC Reply: OK | | RPC Reply: OK |
|<-----------------------------| |<-----------------------------|
| | | |
| Notification (id 22) | | Notification (id 22) |
|<-----------------------------| |<-----------------------------|
| | | |
Figure 11: Message flow for successful subscription modification Figure 11: Message flow for successful subscription modification
3.3.3. Deleting a Subscription 3.3.3. Deleting a Subscription
This operation is defined in [subscribe] for events, and enhanced in This operation is defined in [subscribe] for events, and enhanced in
[yang-push] for datastores. [yang-push] for datastores.
3.3.3.1. Usage Example 3.3.3.1. Usage Example
The following demonstrates deleting a subscription. The following demonstrates deleting a subscription.
<netconf:rpc message-id="101" <netconf:rpc message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-subscription <delete-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<identifier>1922</identifier> <identifier>1922</identifier>
</delete-subscription> </delete-subscription>
</netconf:rpc> </netconf:rpc>
Figure 12: Delete subscription Figure 12: Delete subscription
3.3.3.2. Positive Response 3.3.3.2. Positive Response
If the NETCONF server can satisfy the request, the server sends an OK If the NETCONF server can satisfy the request, the server sends a
element. For example: positive <subscription-result> element. For example:
<rpc-reply message-id="103" <rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <subscription-result
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
ok
</subscription-result>
</rpc-reply> </rpc-reply>
Figure 13: Successful delete subscription Figure 13: Successful delete subscription
3.3.3.3. Negative Response 3.3.3.3. Negative Response
If the NETCONF server cannot satisfy the request, the server sends an If the NETCONF server cannot satisfy the request, the server sends an
error-rpc element indicating the modification didn't work. For <subscription-result> element indicating the deletion was not
example: performed. For example:
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <subscription-result
<error-type>application</error-type> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<error-tag>invalid-value</error-tag> no-such-subscription
<error-severity>error</error-severity> </subscription-result>
<error-path </rpc-reply>
xmlns:t="urn:ietf:params:xml:ns:netconf:notification:2.0">
/t:identifier
</error-path>
<error-message xml:lang="en">
no-such-subscription
</error-message>
</rpc-error>
</rpc-reply>
Figure 14: Unsuccessful delete subscription Figure 14: Unsuccessful delete subscription
3.4. Configured Subscriptions 3.4. Configured Subscriptions
Configured subscriptions are established, modified, and deleted using Configured subscriptions are established, modified, and deleted using
configuration operations against the top-level subtree of [subscribe] configuration operations against the top-level subtree of [subscribe]
or [yang-push] via configuration interface. In this document, we or [yang-push] via configuration interface. This document covers
focus on NETCONF operations. Any other configuration interface can configured subscriptions where the chosen protocol to send the
be used to establish a configured subscription that uses NETCONF to notifications to the receivers is NETCONF.
push notifications to receivers. Configured susbscriptions are
supported by NETCONF servers using NETCONF Call Home [RFC8071]. Note Configured subscriptions are supported by NETCONF servers using
that this document only covers configured subscriptions where the NETCONF Call Home [RFC8071].
protocol of choice is NETCONF. In this section, we present examples
of how to manage the configuration subscriptions using a NETCONF Any configuration interface can be used to set a configured
client. Key differences from dynamic subscriptions over NETCONF is subscription that uses NETCONF to push notifications to receivers.
that subscription lifetimes are decoupled from NETCONF sessions. Without loss of generality, the examples in this section, use a
NETCONF interface to configure the subscriptions
3.4.1. Establishing a Configured Subscription 3.4.1. Establishing a Configured Subscription
For subscription establishment, a NETCONF client may send: For subscription establishment, a NETCONF client may send:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config>
<edit-config> <target>
<target> <running/>
<running/> </target>
</target> <subscription-config
<subscription-config xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> <subscription>
<subscription> <identifier>
<identifier> 1922
1922 </identifier>
</identifier> <stream>
<stream> foo
foo </stream>
</stream> <receiver>
<receiver> <address>
<address> 1.2.3.4
1.2.3.4 </address>
</address> <port>
<port> 1234
1234 </port>
</port> <protocol>
<protocol> netconf
netconf </protocol>
</protocol> </receiver>
</receiver> </subscription>
</subscription> </subscription-config>
</subscription-config> </edit-config>
</edit-config> </rpc>
</rpc>
Figure 15: Establish configured subscription Figure 15: Establish configured subscription
if the request is accepted, the server would reply: if the request is accepted, the server would reply:
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
Figure 16: Response to a successful configuration subscription Figure 16: Response to a successful configuration subscription
establishment establishment
if the request is not accepted because the server cannot serve it, no if the request is not accepted because the server cannot serve it, no
configuration is changed. Int this case the server may reply: configuration is changed. Int this case the server may reply:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <subscription-result
<error-type>application</error-type> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<error-tag>resource-denied</error-tag> error-insufficient-resources
<error-severity>error&lt;/error-severity> </subscription-result>
<error-message xml:lang="en">
Temporarily the server cannot serve this
subscription due to the current workload.
</error-message>
</rpc-error>
</rpc-reply> </rpc-reply>
Figure 17: Response to a failed configured subscription establishment Figure 17: Response to a failed configured subscription establishment
For every configured receiver, once NETCONF transport session between For every configured receiver, once NETCONF transport session between
the server and the receiver is recognized as active, the server will the server and the receiver is recognized as active, the server will
issue a "subscription-started" notification. After that, the server issue a "subscription-started" notification. After that, the server
will send notifications to the receiver as per the subscription will send notifications to the receiver as per the subscription
notification. The session is only intended for pushing notification. Note that the server assumes that the receiver is
notifications. Client request on that session SHOULD be ignored by ready to accept notifications on the NETCONF session. This may
the server. require coordination between the client that configures the
subscription and the clients for which the notifications are
intended. This coordination is out of the scope of this document.
The session is only intended for pushing notifications. Client
requests on that session SHOULD be ignored by the server.
The contents sent by the server on the Call Home session, once The contents sent by the server on the Call Home session, once
established, are identical to those in a dynamic subscription. established, are identical to those in a dynamic subscription.
Note that the server assumes that the receiver is ready to accept
notifications on the NETCONF session. This may require coordination
between the client that configures the subscription and the clients
for which the notifications are intended. This coordination is out
of the scope of this document.
3.4.2. Call Home for Configured Subscriptions 3.4.2. Call Home for Configured Subscriptions
Once this configuration is active, if NETCONF transport is needed but Once the subscription configuration is active, if NETCONF transport
does not exist to one or more target IP address plus port, the server is needed but does not exist to one or more target IP address plus
initiates a transport session via [RFC8071] to those receiver(s) in port, the server initiates a transport session via [RFC8071] to those
the subscription using the address and port specified. receiver(s) in the subscription using the address and port specified.
3.4.3. Full Establish Message Flow 3.4.3. Full Establish Message Flow
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| Client | | Server | | Rcver A | | Rcver B | | Client | | Server | | Rcver A | | Rcver B |
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| | | | | | | |
| Capability Exchange | | | | Capability Exchange | | |
|<-------------------------->| | | |<-------------------------->| | |
| | | | | | | |
| | | | | | | |
| Edit-config | | | | Edit-config | | |
|--------------------------->| | | |--------------------------->| | |
skipping to change at page 16, line 5 skipping to change at page 15, line 5
Figure 18: Message flow for configured subscription establishment Figure 18: Message flow for configured subscription establishment
3.4.4. Modifying a Configured Subscription 3.4.4. Modifying a Configured Subscription
Configured subscriptions can be modified using configuration Configured subscriptions can be modified using configuration
operations against the top-level subtree subscription-config. operations against the top-level subtree subscription-config.
For example, the subscription established in the previous section For example, the subscription established in the previous section
could be modified as follows, choosing a different receiver: could be modified as follows, choosing a different receiver:
<rpc message-id="102" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config>
<edit-config> <target>
<target> <running/>
<running/> </target>
</target> <subscription-config
<subscription-config xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> <subscription>
<subscription> <identifier>
<identifier> 1922
1922 </identifier>
</identifier> <stream>
<stream> foo
foo </stream>
</stream> <receiver>
<receiver> <address>
<address> 1.2.3.5
1.2.3.5 </address>
</address> <port>
<port> 1234
1234 </port>
</port> </receiver>
</receiver> </subscription>
</subscription> </subscription-config>
</subscription-config> </edit-config>
</edit-config> </rpc>
</rpc>
Figure 19: Modify configured subscription Figure 19: Modify configured subscription
if the request is accepted, the server would reply: if the request is accepted, the server would reply:
<rpc-reply message-id="102" <rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
skipping to change at page 18, line 10 skipping to change at page 17, line 10
| | | | | | | |
Figure 21: Message flow for subscription modification (configured Figure 21: Message flow for subscription modification (configured
subscription) subscription)
3.4.5. Deleting a Configured Subscription 3.4.5. Deleting a Configured Subscription
Subscriptions can be deleted using configuration operations against Subscriptions can be deleted using configuration operations against
the top-level subtree subscription-config. For example: the top-level subtree subscription-config. For example:
<rpc message-id="103" <rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<subscription-config <subscription-config
xmlns:xc="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns:xc="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<subscription xc:operation="delete"> <subscription xc:operation="delete">
<identifier> <identifier>
1922 1922
</identifier> </identifier>
</subscription> </subscription>
</subscription-config> </subscription-config>
</edit-config> </edit-config>
</rpc> </rpc>
<rpc-reply message-id="103" <rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
Figure 22: Deleting a configured subscription Figure 22: Deleting a configured subscription
3.4.5.1. Message Flow Example 3.4.5.1. Message Flow Example
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| Client | | Server | | Rcver A | | Rcver B | | Client | | Server | | Rcver A | | Rcver B |
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| | | | | | | |
| Capability Exchange | | | | Capability Exchange | | |
|<-------------------------->| | | |<-------------------------->| | |
skipping to change at page 20, line 4 skipping to change at page 19, line 5
Figure 23: Message flow for subscription deletion (configured Figure 23: Message flow for subscription deletion (configured
subscription) subscription)
3.4.6. Event (Data Plane) Notifications 3.4.6. Event (Data Plane) Notifications
Once a dynamic or configured subscription has been created, the Once a dynamic or configured subscription has been created, the
NETCONF server sends (asynchronously) event notifications from the NETCONF server sends (asynchronously) event notifications from the
subscribed stream to receiver(s) over NETCONF. We refer to these as subscribed stream to receiver(s) over NETCONF. We refer to these as
data plane notifications. The data model for Event Notifications is data plane notifications. The data model for Event Notifications is
defined in [subscribe]. This document extends that data model for defined in [subscribe].
supporting different encondigs.
The following is an example of an event notification from [RFC6020]: The following is an example of an event notification from [RFC6020]:
notification link-failure { notification link-failure {
description "A link failure has been detected"; description "A link failure has been detected";
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interface/name"; path "/interface/name";
} }
} }
leaf if-admin-status { leaf if-admin-status {
type admin-status; type admin-status;
} }
leaf if-oper-status { leaf if-oper-status {
type oper-status; type oper-status;
} }
} }
Figure 24: Definition of a event notification Figure 24: Definition of an event notification
This notification might result in the following, prior to it being This notification might result in the following, prior to it being
placed into NETCONF. Note that the mandatory eventTime and placed into NETCONF. Note that the mandatory eventTime and
Subscription id have been added. Subscription id have been added.
<notification <notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-id>39</subscription-id>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="http://acme.example.com/system">
<if-name>so-1/2/3.0</if-name> <if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status> <if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status> <if-oper-status>down</if-oper-status>
</link-failure> </link-failure>
</notification> </notification>
Figure 25: Event notification Figure 25: Event notification
In order to support JSON encoding, this document extends the data
model for Event Notifications, adding a new element, i.e.,
notification-contents-json. This element contains the event
notification-specific tagged content in JSON. For the event
notification above, the equivalent using JSON encoding would be
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-id>39</subscription-id>
<notification-contents-json>
{
"acme-system:link-failure": {
"if-name": "so-1/2/3.0",
"if-admin-status": "up",
"if-oper-status": "down"
}
}
</notification-contents-json>
</notification>
Figure 26: Event notification using JSON encoding
3.4.7. Subscription State Notifications 3.4.7. Subscription State Notifications
In addition to data plane notifications, a publisher may send In addition to data plane notifications, a publisher may send
subscription state notifications (defined in [subscribe]) to indicate subscription state notifications (defined in [subscribe]) to indicate
to receivers that an event related to the subscription management has to receivers that an event related to the subscription management has
occurred. Subscription state notifications cannot be filtered out. occurred. Subscription state notifications cannot be filtered out.
Next we exemplify them using both XML, and JSON encodings for the Next we exemplify them:
notification-specific content:
3.4.7.1. subscription-started and subscription-modified 3.4.7.1. subscription-started and subscription-modified
A subscription-started would look like: A subscription-started would look like:
<notification <notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-started <subscription-started
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"/> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"/>
<identifier>39</identifier> <identifier>39</identifier>
<event-filter-type>xpath</event-filter-type> <stream>NETCONF</stream>
<event-filter xmlns:ex="http://example.com/event/1.0"
select="/ex:event[ex:eventClass='fault' and
(ex:severity='minor' or ex:severity='major'
or ex:severity='critical')]"/>
</subscription-started/> </subscription-started/>
</notification> </notification>
Figure 27: subscription-started subscription state notification Figure 26: subscription-started subscription state notification
The equivalent using JSON encoding would be:
<notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0">
<eventTime>2007-09-01T10:00:00Z</eventTime>
<notification-contents-json>
{
"notif-bis:subscription-started": {
"identifier" : 39
}
}
</notification-contents-json>
</notification>
Figure 28: subscription-started subscription state notification
(JSON)
The subscription-modified is identical, with just the word "started" The subscription-modified is identical, with just the word "started"
being replaced by "modified". being replaced by "modified".
3.4.7.2. notification-complete, subscription-resumed, and replay- 3.4.7.2. subscription-completed, subscription-resumed, and replay-
complete complete
A notification-complete would look like: A subscription-completed would look like:
<notification <notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<notification-complete <subscription-completed
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<identifier>39</identifier> <identifier>39</identifier>
</notification-complete> </subscription-completed>
</notification> </notification>
Figure 29: notification-complete notification in XML Figure 27: subscription-completed notification in XML
The equivalent using JSON encoding would be: The equivalent using JSON encoding would be:
<notification <notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<notification-contents-json> <notification-contents-json>
{ {
"netmod-notif:notification-complete": { "sn:subscription-completed": {
"identifier" : 39 "identifier" : 39
} }
</notification-contents-json> </notification-contents-json>
</notification> </notification>
Figure 30: notification-complete notification in JSON Figure 28: subscription-completed notification in JSON
The subscription-resumed and replay-complete are virutally identical, The subscription-resumed and replay-complete are virtually identical,
with "notification-complete" simply being replaced by "subscription- with "subscription-completed" simply being replaced by "subscription-
resumed" and "replay-complete" in both encodings. resumed" and "replay-complete" in both encodings.
3.4.7.3. subscription-terminated and subscription-suspended 3.4.7.3. subscription-terminated and subscription-suspended
A subscription-terminated would look like: A subscription-terminated would look like:
<notification <notification
xmlns=" urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-terminated <subscription-terminated
xmlns="urn:ietf:params:xml:ns:netconf:notification:2.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<identifier>39</identifier> <identifier>39</identifier>
<error-id>no-such-subscription</error-id> <error-id>error-insufficient-resources</error-id>
</subscription-terminated> </subscription-terminated>
</notification> </notification>
Figure 31: subscription-modified subscription state notification Figure 29: subscription-modified subscription state notification
The above, and the subscription-suspended are virutally identical, The above, and the subscription-suspended are virtually identical,
with "subscription-terminated" simply being replaced by with "subscription-terminated" simply being replaced by
"subscription-suspended". "subscription-suspended".
3.4.7.4. Notification Message Flow Examples 3.4.7.4. Notification Message Flow Examples
+------------+ +-----------+ +------------+ +-----------+
| Client | | Server | | Client | | Server |
+------------+ +-----------+ +------------+ +-----------+
| | | |
| Capability Exchange | | Capability Exchange |
|<---------------------------->| |<---------------------------->|
skipping to change at page 24, line 30 skipping to change at page 22, line 30
| | | |
| | | |
| | | |
| Subscription Resumed | | Subscription Resumed |
|<-----------------------------| |<-----------------------------|
| | | |
| Notification | | Notification |
|<-----------------------------| |<-----------------------------|
| | | |
Figure 32: subscription-suspended and resumed notifications Figure 30: subscription-suspended and resumed notifications
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| Client | | Server | | Rcver A | | Rcver B | | Client | | Server | | Rcver A | | Rcver B |
+----------+ +-----------+ +---------+ +---------+ +----------+ +-----------+ +---------+ +---------+
| | | | | | | |
| Capability Exchange | | | | Capability Exchange | | |
|<-------------------------->| | | |<-------------------------->| | |
| | | | | | | |
| Edit-config | | | | Edit-config | | |
|--------------------------->| | | |--------------------------->| | |
skipping to change at page 25, line 41 skipping to change at page 23, line 41
| | | | | | | |
| | Subscription | | | | Subscription | |
| | Resumed | | | | Resumed | |
| |--------------->| | | |--------------->| |
| | | | | | | |
| | Notification | | | | Notification | |
| |--------------->| | | |--------------->| |
| |---------------------------->| | |---------------------------->|
| | | | | | | |
Figure 33: Suspended and resumed notificatiosn for a single Figure 31: Suspended and resumed notifications for a single
configured receiver configured receiver
4. Interleave Capability 4. Interleave Capability
The :interleave capability is originally defined in [RFC5277]. It is The :interleave capability is originally defined in [RFC5277]. It is
incorporated in this document with essentialy the same semantics. incorporated in this document with essentially the same semantics.
That is, the NETCONF server MUST receive, process, and respond to That is, the NETCONF server MUST receive, process, and respond to
NETCONF requests on a session with active notification subscriptions. NETCONF requests on a session with active notification subscriptions.
Note that subscription operations MUST be received, processed, and
responded on a session with active notification subscriptions This The :interleave capability is identified by the following string:
mandatory requirement together with the :inteleave capability permits
a client performing all operations against a server using a single
connection, allowing for better scalability with respect to the
number of NETCONF sessions required to manage an entity. The
:interleave capability is identified by the following string:
urn:ietf:params:netconf:capability:interleave:1.0 urn:ietf:params:netconf:capability:interleave:1.0
Note that subscription operations MUST be received, processed, and
responded on a session with active notification subscriptions That
mandatory requirement together with the :interleave capability
permits a client performing all operations against a server using a
single connection, allowing for better scalability with respect to
the number of NETCONF sessions required to manage an entity.
5. Security Considerations 5. Security Considerations
The <notification> elements are never sent before the transport layer The <notification> elements are never sent before the transport layer
and the NETCONF layer, including capabilities exchange, have been and the NETCONF layer, including capabilities exchange, have been
established and the manager has been identified and authenticated. established and the manager has been identified and authenticated.
A secure transport must be used and the server must ensure that the A secure transport must be used and the server must ensure that the
user has sufficient authorization to perform the function they are user has sufficient authorization to perform the function they are
requesting against the specific subset of content involved. requesting against the specific subset of content involved.
skipping to change at page 27, line 12 skipping to change at page 25, line 12
Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins,
Balazs Lengyel, Kent Watsen, and Guangying Zheng. Balazs Lengyel, Kent Watsen, and Guangying Zheng.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>. <https://www.rfc-editor.org/info/rfc5277>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
RFC 8071, DOI 10.17487/RFC8071, February 2017, RFC 8071, DOI 10.17487/RFC8071, February 2017,
<http://www.rfc-editor.org/info/rfc8071>. <https://www.rfc-editor.org/info/rfc8071>.
7.2. Informative References 7.2. Informative References
[subscribe] [subscribe]
Voit, Eric., Clemm, A., Gonzalez Prieto, A., Nilsen- Voit, Eric., Clemm, A., Gonzalez Prieto, A., Nilsen-
Nygaard, E., and A. Tripathy, "Subscribing to Event Nygaard, E., and A. Tripathy, "Custom Subscription to
Notifications", April 2016, Event Notifications", September 2017,
<https://datatracker.ietf.org/doc/draft-ietf-netconf- <https://datatracker.ietf.org/doc/
subscribed-notifications/>. draft-ietf-netconf-subscribed-notifications/>.
[yang-push] [yang-push]
Clemm, A., Gonzalez Prieto, A., Voit, Eric., Tripathy, A., Clemm, A., Gonzalez Prieto, A., Voit, Eric., Tripathy, A.,
and E. Nilsen-Nygaard, "Subscribing to YANG datastore push Nilsen-Nygaard, E., Bierman, A., and B. Lengyel,
updates", April 2017, <https://datatracker.ietf.org/doc/ "Subscribing to YANG datastore push updates", September
2017, <https://datatracker.ietf.org/doc/
draft-ietf-netconf-yang-push/>. draft-ietf-netconf-yang-push/>.
Appendix A. Open Items Appendix A. Open Items
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
o Formal definition of: notification-contents-json. It depends on o Formal definition of: notification-contents-json, and
the formal definition of the notification element incorporation of the subscription-id in the notifications. It
depends on the formal definition of the notification element
o Specify how to indicate a stream is not part of the NETCONF
stream. It depends on draft-ietf-netconf-subscribed-notifications
Appendix B. Changes between revisions Appendix B. Changes between revisions
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
B.1. v03 to v04 B.1. v04 to v05
o Text presentation modifications throughout
o Modified examples to match the namespace, prefixes, and data node
identifiers in [subscribe] and [yang-push]
o Modified examples to include <subscription-result> in all RPC
responses
o Modified examples to include mandatory fields in [subscribe] and
[yang-push]
B.2. v03 to v04
o Added additional detail to "configured subscriptions" o Added additional detail to "configured subscriptions"
o Added interleave capability o Added interleave capability
o Adjusted terminology to that in draft-ietf-netconf-subscribed- o Adjusted terminology to that in draft-ietf-netconf-subscribed-
notifications notifications
o Corrected namespaces in examples o Corrected namespaces in examples
B.2. v01 to v03 B.3. v01 to v03
o Text simplifications throughout o Text simplifications throughout
o v02 had no meaningful changes o v02 had no meaningful changes
B.3. v00 to v01 B.4. v00 to v01
o Added Call Home in solution for configured subscriptions. o Added Call Home in solution for configured subscriptions.
o Clarified support for multiple subscription on a single session. o Clarified support for multiple subscription on a single session.
No need to support multiple create-subscription. No need to support multiple create-subscription.
o Added mapping between terminology in [yang-push] and [RFC6241] o Added mapping between terminology in [yang-push] and [RFC6241]
(the one followed in this document). (the one followed in this document).
o Editorial improvements. o Editorial improvements.
 End of changes. 90 change blocks. 
391 lines changed or deleted 343 lines changed or added

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