draft-ietf-netconf-rfc5277bis-00.txt   draft-ietf-netconf-rfc5277bis-01.txt 
NETCONF A. Clemm NETCONF A. Clemm
Internet-Draft A. Gonzalez Prieto Internet-Draft Sympotech
Intended status: Standards Track E. Voit Intended status: Standards Track A. Gonzalez Prieto
Expires: March 15, 2017 E. Nilsen-Nygaard Expires: April 30, 2017 E. Voit
E. Nilsen-Nygaard
A. Tripathy A. Tripathy
Cisco Systems Cisco Systems
S. Chisholm S. Chisholm
Ciena Ciena
H. Trevino H. Trevino
Cisco Systems Cisco Systems
September 11, 2016 October 27, 2016
Subscribing to Event Notifications Subscribing to Event Notifications
draft-ietf-netconf-rfc5277bis-00 draft-ietf-netconf-rfc5277bis-01
Abstract Abstract
This document defines capabilities and operations for providing This document defines capabilities and operations for subscribing to
asynchronous message notification delivery for notifications, such as content and providing asynchronous notification message delivery on
those defined using YANG. Notification delivery can occur over a that content. Notification delivery can occur over a variety of
variety of protocols used commonly in conjunction with YANG, such as protocols used commonly in conjunction with YANG, such as NETCONF and
NETCONF and RESTCONF. The capabilities and operations defined in RESTCONF. The capabilities and operations defined in this document
this document along with their mapping onto NETCONF transport are when using in conjunction with draft-ietf-netconf-netconf-event-
intended to replace RFC 5277. notifications are intended to replace RFC 5277.
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 http://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 March 15, 2017. This Internet-Draft will expire on April 30, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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
skipping to change at page 2, line 25 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 1.3. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Event Streams . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Event Streams . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Event Stream Discovery . . . . . . . . . . . . . . . . . 7 2.2. Event Stream Discovery . . . . . . . . . . . . . . . . . 7
2.3. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Subscription State Model at the Event Server . . . . . . 7 2.4. Subscription State Model at the Publisher . . . . . . . . 7
3. Data Model Trees for Event Notifications . . . . . . . . . . 8 3. Data Model Trees for Event Notifications . . . . . . . . . . 8
4. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 12 4. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 12
4.1. Establishing a Subscription . . . . . . . . . . . . . . . 13 4.1. Establishing a Subscription . . . . . . . . . . . . . . . 12
4.2. Modifying a Subscription . . . . . . . . . . . . . . . . 13 4.2. Modifying a Subscription . . . . . . . . . . . . . . . . 13
4.3. Deleting a Subscription . . . . . . . . . . . . . . . . . 14 4.3. Deleting a Subscription . . . . . . . . . . . . . . . . . 13
5. Configured Subscriptions . . . . . . . . . . . . . . . . . . 15 5. Configured Subscriptions . . . . . . . . . . . . . . . . . . 14
5.1. Creating a Configured Subscription . . . . . . . . . . . 15 5.1. Establishing a Configured Subscription . . . . . . . . . 14
5.2. Establishing a Configured Subscription . . . . . . . . . 15 5.2. Modifying a Configured Subscription . . . . . . . . . . . 16
5.3. Modifying a Configured Subscription . . . . . . . . . . . 17 5.3. Deleting a Configured Subscription . . . . . . . . . . . 16
5.4. Deleting a Configured Subscription . . . . . . . . . . . 17 6. Event (Data Plane) Notifications . . . . . . . . . . . . . . 17
6. Event (Data Plane) Notifications . . . . . . . . . . . . . . 18 7. Control Plane Notifications . . . . . . . . . . . . . . . . . 18
7. Control Plane Notifications . . . . . . . . . . . . . . . . . 20 7.1. replayComplete . . . . . . . . . . . . . . . . . . . . . 19
7.1. replayComplete . . . . . . . . . . . . . . . . . . . . . 20 7.2. notificationComplete . . . . . . . . . . . . . . . . . . 19
7.2. notificationComplete . . . . . . . . . . . . . . . . . . 20 7.3. subscription-started . . . . . . . . . . . . . . . . . . 19
7.3. subscription-started . . . . . . . . . . . . . . . . . . 20 7.4. subscription-modified . . . . . . . . . . . . . . . . . . 19
7.4. subscription-modified . . . . . . . . . . . . . . . . . . 21 7.5. subscription-terminated . . . . . . . . . . . . . . . . . 19
7.5. subscription-terminated . . . . . . . . . . . . . . . . . 21 7.6. subscription-suspended . . . . . . . . . . . . . . . . . 20
7.6. subscription-suspended . . . . . . . . . . . . . . . . . 21 7.7. subscription-resumed . . . . . . . . . . . . . . . . . . 20
7.7. subscription-resumed . . . . . . . . . . . . . . . . . . 21 8. Data Model for Event Notifications . . . . . . . . . . . . . 20
8. Data Model for Event Notifications . . . . . . . . . . . . . 21 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 40
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
11. Issues that are currently being worked and resolved . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Unresolved and yet-to-be addressed issues . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Agreement in principal . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . 42
11.3. Resolved Issues . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Issues that are currently being worked and resolved 43
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Unresolved and yet-to-be addressed issues . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. Agreement in principal . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 A.3. Resolved Issues . . . . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix B. Changes between revisions . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This document defines mechanisms that provide an asynchronous message This document defines mechanisms that provide an asynchronous message
notification delivery service in a protocol-agnostic manner. This notification delivery service in a protocol-agnostic manner. This
document defines capabilities and operations for providing document defines capabilities and operations for providing
asynchronous message notification delivery for notifications asynchronous message notification delivery for notifications
including those necessary to establish, monitor, and support including those necessary to establish, monitor, and support
subscriptions to notification delivery. subscriptions to notification delivery.
Notification delivery can occur over a variety of protocols used Notification delivery can occur over a variety of protocols used
commonly in conjunction with YANG, such as NETCONF [RFC6241] (defined commonly in conjunction with YANG, such as NETCONF [RFC6241] (defined
in [I-D.ietf-netconf-netconf-event-notif]) and Restconf in [I-D.ietf-netconf-netconf-event-notif]) and Restconf
[I-D.ietf-netconf-restconf] (defined in [I-D.ietf-netconf-restconf] (defined in
[I-D.ietf-netconf-restconf-notif]). The capabilities and operations [I-D.ietf-netconf-restconf-notif]). The capabilities and operations
defined in this document are intended to replace RFC 5277, along with defined in this document are intended to replace RFC 5277, along with
their mapping onto NETCONF transport. their mapping onto NETCONF transport.
1.1. Motivation 1.1. Motivation
The motivation for this work is to enable the sending of asynchronous The motivation for this work is to enable the sending of transport
notification messages that are consistent with the data model agnostic asynchronous notification messages driven by a YANG
(content) and security model used within a NETCONF implementation. Subscription that are consistent with the data model (content) and
security model. Predating this work was used within a NETCONF
[RFC5277] defines a notification mechanism for NETCONF. However, implementation. [RFC5277] which defined a limited defines a
there are various limitations: notification mechanism for for NETCONF. However, there are various
[RFC5277] has limitations:, many of which have been exposed in
o Each subscription requires a separate NETCONF connection, which is [RFC7923].
wasteful.
o The only mechanism to terminate a subscription is terminating the
underlying NETCONF connection.
o No ability to modify subscriptions once they have been created.
o No ability to notify the receiver of a subscription if the server
is dropping events.
o No mechanism to monitor subscriptions.
o No alternative mechanism to create subscriptions via RPCs. Thus
the lifetime of the subscription is limited by that of the
underlaying NETCONF session.
o Predates YANG and defines RPCs, notifications, and data nodes
outside of the YANG framework.
The scope of the work aims at meeting the following operational The scope of the work aims at meeting the operational needs of
needs: network subscriptions:
o Ability to dynamically or statically subscribe to event o Ability to dynamically or statically subscribe to event
notifications available on an event server. notifications available on a publisher.
o Ability to negotiate acceptable dynamic subscription parameters. o Ability to negotiate acceptable dynamic subscription parameters.
o Ability to filter the subset of notifications to be pushed with o Ability to filter the subset of notifications to be pushed with
stream-specific semantics. stream-specific semantics.
o Ability for the notification payload to be interpreted o Ability for the notification payload to be interpreted
independently of the transport protocol. (In other words, the independently of the transport protocol. (In other words, the
encoded notification fully describes itself.) encoded notification fully describes itself.)
skipping to change at page 4, line 37 skipping to change at page 4, line 23
1.2. Terminology 1.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].
Configured subscription: A subscription installed via a configuration Configured subscription: A subscription installed via a configuration
interface which persists across reboots. interface which persists across reboots.
Dynamic subscription: A subscription agreed between subscriber and Dynamic subscription: A subscription agreed between subscriber and
event server via create, establish, modify, and delete RPC control publisher via create, establish, modify, and delete RPC control plane
plane signaling messages. signaling messages.
Event: Something that happens that may be of interest. (e.g., a Event: An occurrence of something that may be of interest. (e.g., a
configuration change, a fault, a change in status, crossing a configuration change, a fault, a change in status, crossing a
threshold, or an external input to the system.) threshold, or an external input to the system.)
Event notification: A message sent by a server to a receiver Event notification: A set of information intended for a Receiver
indicating that an event (of interest to the subscriber) has indicating that one or more Event(s) have occurred. Details of the
occurred. Events can trigger notifications if an interested party Event(s) may be included within the Notification.
has subscribed to the stream(s) it belongs to.
Event server: The server being subscribed to, which serves an event
subscription.
Filter: Evaluation criteria, which may be applied against a targeted Filter: Evaluation criteria, which may be applied against a targeted
set of objects/events in a subscription. Information traverses the set of objects/events in a subscription. Information traverses the
filter only if specified filter criteria are met. filter only if specified filter criteria are met.
NACM: NETCONF Access Control Model. NACM: NETCONF Access Control Model.
OAM: Operations, Administration, Maintenance. OAM: Operations, Administration, Maintenance.
Publisher: An entity responsible for streaming Event Notifications Publisher: An entity responsible for streaming Event Notifications
per the terms of a Subscriptions per the terms of a Subscriptions
Receiver: A target to which a publisher pushes event notifications.
For dynamic subscriptions, the receiver and subscriber will often be
the same entity.
RPC: Remote Procedure Call. RPC: Remote Procedure Call.
Stream (also referred to as "event stream"): A continuous ordered set Stream (also referred to as "event stream"): A continuous ordered set
of events grouped under an explicit criteria. of events grouped under an explicit criteria.
Subscriber: An entity able to request and negotiate a contract for Subscriber: An entity able to request and negotiate a contract for
the receipt of event notifications from a NETCONF server. the receipt of event notifications from a publisher.
Receiver: A target to which an event server pushes event
notifications. In many deployments, the receiver and subscriber will
be the same entity.
Subscription: A contract between a subscriber and an event server, Subscription: A contract with a publisher, stipulating which
stipulating which information the receiver wishes to have pushed from information receiver(s) wishes to have pushed from the publisher
the server without the need for further solicitation. without the need for further solicitation.
1.3. Solution Overview 1.3. Solution Overview
This document describes mechanisms for subscribing and receiving This document describes mechanisms for subscribing and receiving
event notifications from an event server. This document builds on event notifications from an event server publisher. This document
top of the capabilities defined in [RFC5277], extending them, and builds on top of the capabilities defined in [RFC5277], extending
generalizing them to be protocol-agnostic. them, and generalizing them to be protocol-agnostic.
The enhancements over RFC 5277 include the ability to terminate Some enhancements over RFC 5277 include the ability to have multiple
subscriptions without terminating the client session, to modify subscriptions on a single transport session, to terminate a single
existing subscriptions, and to have multiple subscriptions on a subscriptions without terminating the transport session, and to
NETCONF session. modify existing subscriptions.
These enhancements do not affect existing RFC 5277 clients that do These enhancements do not affect existing RFC 5277 subscribers that
not support these particular subscription requirements. do not support these particular subscription requirements.
The solution supports subscribing to event notifications using two The solution supports subscribing to event notifications using two
mechanisms. mechanisms:
1. Dynamic subscriptions, where a client initiates a subscription 1. Dynamic subscriptions, where a subscriber initiates a
negotiation with an event server via RPC. A client initiates a subscription negotiation with a publisher via RPC. A subscriber
negotiation by issuing a subscription request. If the event initiates a negotiation by issuing a subscription request. If
server wants to serve this request, it will accept it, and then the publisher wants to serve this request, it will accept it, and
start pushing event notifications as negotiated. If the event then start pushing event notifications as negotiated. If the
server does not wish to serve it as requested, it may respond publisher does not wish to serve it as requested, it may respond
with subscription parameters which it would have accepted. with subscription parameters which it would have accepted.
2. Configured subscriptions, which is an optional mechanism that 2. Configured subscriptions, which is an optional mechanism that
enables managing subscriptions via a configuration interface so enables managing subscriptions via a configuration interface so
that an event server sends event notifications to a configured that a publisher can send event notifications to configured
receiver(s). receiver(s).
Some key characteristics of configured and dynamic subscriptions Some key characteristics of configured and dynamic subscriptions
include: include:
o The lifetime of a dynamic subscription is limited by the lifetime o The lifetime of a dynamic subscription is limited by the lifetime
of the subscriber session used to establish it. Typically loss of of the subscriber session used to establish it. Typically loss of
the transport session tears down any dependent dynamic the transport session tears down any dependent dynamic
subscriptions. subscriptions.
skipping to change at page 6, line 38 skipping to change at page 6, line 18
o Subscriptions can be modified or terminated at any point of their o Subscriptions can be modified or terminated at any point of their
lifetime. configured subscriptions can be modified by any lifetime. configured subscriptions can be modified by any
configuration client with write rights on the configuration of the configuration client with write rights on the configuration of the
subscription. subscription.
Note that there is no mixing-and-matching of dynamic and configured Note that there is no mixing-and-matching of dynamic and configured
subscriptions. Specifically, a configured subscription cannot be subscriptions. Specifically, a configured subscription cannot be
modified or deleted using RPC. Similarly, a subscription created via modified or deleted using RPC. Similarly, a subscription created via
RPC cannot be modified through configuration operations. RPC cannot be modified through configuration operations.
The event server may decide to terminate a dynamic subscription at The publisher may decide to terminate a dynamic subscription at any
any time. Similarly, it may decide to temporarily suspend the time. Similarly, it may decide to temporarily suspend the sending of
sending of event notifications for either configured or dynamic event notifications for either configured or dynamic subscriptions.
subscriptions. Such termination or suspension may be driven by the Such termination or suspension may be driven by the publisher running
server running out of resources to serve the subscription, or by out of resources to serve the subscription, or by internal errors on
internal errors on the server. the publisher.
2. Solution 2. Solution
2.1. Event Streams 2.1. Event Streams
An event stream is a set of events available for subscription from a An event stream is a set of events available for subscription from a
server. It is out of the scope of this document to identify a) how publisher. It is out of the scope of this document to identify a)
streams are defined, b) how events are defined/generated, and c) how how streams are defined, b) how events are defined/generated, and c)
events are assigned to streams. how events are assigned to streams.
That said, some event streams will be standardized whereas others may That said, some event streams will be standardized whereas others may
be vendor specific. One standardized event stream is the "NETCONF" be vendor specific. One standardized event stream is the "NETCONF"
notification event stream. The NETCONF event stream contains all notification event stream. The NETCONF event stream contains all
NETCONF XML event notifications supported by the NETCONF server, NETCONF XML event notifications supported by the publisher, except
except for those belonging only to streams that explicitly indicate for those belonging only to streams that explicitly indicate that
that they must be excluded from the NETCONF stream, such as they must be excluded from the NETCONF stream, such as notifications
notifications that serve OAM and signaling purposes. that serve OAM and signaling purposes.
The following is a high-level description of the flow of a The following is a high-level description of the flow of a
notification. Note that it does not mandate and/or preclude an notification. Note that it does not mandate and/or preclude an
implementation. As events are raised, they are assigned to streams. implementation. As events are raised, they are assigned to streams.
An event may be assigned to multiple streams. The event is An event may be assigned to multiple streams. The event is
distributed to subscribers and receivers based on the current distributed to subscribers and receivers based on the current
subscriptions and access control. Access control is needed because subscriptions and access control. Access control is needed because
if any receiver of that subscription does not have permission to if any receiver of that subscription does not have permission to
receive an event, then it never makes it into a notification, and receive an event, then it never makes it into a notification, and
processing of the event is completed for that subscription. processing of the event is completed for that subscription.
2.2. Event Stream Discovery 2.2. Event Stream Discovery
A server maintains a list of available event streams as operational A publisher maintains a list of available event streams as
data. This list contains both standardized and vendor-specific event operational data. This list contains both standardized and vendor-
streams. A client can retrieve this list like any other YANG-defined specific event streams. A client can retrieve this list like any
data, for example using the <get> operation when using NETCONF. other YANG-defined data, for example using the <get> operation when
using NETCONF.
2.3. Filters 2.3. Filters
An event server implementation SHOULD support the ability to perform a publisher implementation SHOULD support the ability to perform
filtering of notification records per RFC 5277. (TODO: since 5277 is filtering of notification records per RFC 5277. (TODO: since 5277 is
to be obsoleted, we should describe the filter here.) to be obsoleted, we should describe the filter here.)
2.4. Subscription State Model at the Event Server 2.4. Subscription State Model at the Publisher
Below is the state machine of a subscription for the event server. Below is the state machine of a subscription for the publisher. It
It is important to note that a subscription doesn't exist at the is important to note that a subscription doesn't exist at the
event server until it is accepted and made active. The mere request publisher until it is accepted and made active. The mere request by
by a subscriber to establish a subscription is insufficient for that a subscriber to establish a subscription is insufficient for that
asserted subscription to be externally visible via this state asserted subscription to be externally visible via this state
machine. machine.
.-------. .-------.
| start | | start |
'-------' '-------'
| |
establish establish
| |
| .----------modify--------------. | .----------modify--------------.
skipping to change at page 8, line 26 skipping to change at page 7, line 49
'--------->| |<----resume----<------| | '--------->| |<----resume----<------| |
'-----------' '-----------' '-----------' '-----------'
| | | |
delete delete delete delete
| | | |
v | v |
.-------. | .-------. |
| end |<-----------------------------' | end |<-----------------------------'
'-------' '-------'
Figure 1: Subscription states at event server Figure 1: Subscription states at publisher
Of interest in this state machine are the following: Of interest in this state machine are the following:
o Successful <establish-subscription> or <modify-subscription> o Successful <establish-subscription> or <modify-subscription>
requests put the subscription into an active state. requests put the subscription into an active state.
o Failed <modify-subscription> requests will leave the subscription o Failed <modify-subscription> requests will leave the subscription
in its previous state, with no visible change to any streaming in its previous state, with no visible change to any streaming
updates. updates.
o A <delete-subscription> request will delete the entire o A <delete-subscription> request will delete the entire
subscription. subscription.
3. Data Model Trees for Event Notifications 3. Data Model Trees for Event Notifications
The YANG data model for event notifications is depicted in this The YANG data model for event notifications is depicted in this
section. section.
module: ietf-event-notifications module: ietf-event-notifications
+--ro streams +--ro streams
| +--ro stream* notif:stream | +--ro stream* stream
+--rw filters +--rw filters
| +--rw filter* [filter-id] | +--rw filter* [filter-id]
| +--rw filter-id filter-id | +--rw filter-id filter-id
| +--rw (filter-type)? | +--rw (filter-type)?
| +--:(rfc5277) | +--:(rfc5277)
| +--rw filter | +--rw filter?
+--rw subscription-config {configured-subscriptions}? +--rw subscription-config {configured-subscriptions}?
| +--rw subscription* [subscription-id] | +--rw subscription* [subscription-id]
| +--rw subscription-id subscription-id | +--rw subscription-id subscription-id
| +--rw stream? stream | +--rw stream? stream
| +--rw (filter-type)? | +--rw encoding? encoding
| | +--:(rfc5277) | +--rw (filter-type)?
| | | +--rw filter | | +--:(rfc5277)
| | +--:(by-reference) | | | +--rw filter?
| | +--rw filter-ref? filter-ref | | +--:(by-reference)
| +--rw startTime? yang:date-and-time | | +--rw filter-ref? filter-ref
| +--rw stopTime? yang:date-and-time | +--rw startTime? yang:date-and-time
| +--rw encoding? encoding | +--rw stopTime? yang:date-and-time
| +--rw receivers | +--rw receivers
| | +--rw receiver* [address] | | +--rw receiver* [address]
| | +--rw address inet:host | | +--rw address inet:host
| | +--rw port inet:port-number | | +--rw port inet:port-number
| | +--rw protocol? transport-protocol | | +--rw protocol? transport-protocol
| +--rw (push-source)? | +--rw (push-source)?
| +--:(interface-originated) | +--:(interface-originated)
| | +--rw source-interface? if:interface-ref | | +--rw source-interface? if:interface-ref
| +--:(address-originated) | +--:(address-originated)
| +--rw source-vrf? uint32 | +--rw source-vrf? uint32
| +--rw source-address inet:ip-address-no-zone | +--rw source-address inet:ip-address-no-zone
+--ro subscriptions +--ro subscriptions
+--ro subscription* [subscription-id] +--ro subscription* [subscription-id]
+--ro subscription-id subscription-id +--ro subscription-id subscription-id
+--ro configured-subscription? empty {configured-subscriptions}? +--ro configured-subscription?
+--ro subscription-status? subscription-status | empty {configured-subscriptions}?
+--ro stream? stream +--ro subscription-status? subscription-status
+--ro (filter-type)? +--ro stream? stream
| +--:(rfc5277) +--ro encoding? encoding
| | +--ro filter +--ro (filter-type)?
| +--:(by-reference) | +--:(rfc5277)
| +--ro filter-ref? filter-ref | | +--ro filter?
+--ro startTime? yang:date-and-time | +--:(by-reference)
+--ro stopTime? yang:date-and-time | +--ro filter-ref? filter-ref
+--ro encoding? encoding +--ro startTime? yang:date-and-time
+--ro receivers +--ro stopTime? yang:date-and-time
| +--ro receiver* [address] +--ro receivers
| +--ro address inet:host | +--ro receiver* [address]
| +--ro port inet:port-number | +--ro address inet:host
| +--ro protocol? transport-protocol | +--ro port inet:port-number
+--ro (push-source)? | +--ro protocol? transport-protocol
+--:(interface-originated) +--ro (push-source)?
| +--ro source-interface? if:interface-ref +--:(interface-originated)
+--:(address-originated) | +--ro source-interface? if:interface-ref
+--ro source-vrf? uint32 +--:(address-originated)
+--ro source-address inet:ip-address-no-zone +--ro source-vrf? uint32
rpcs: +--ro source-address inet:ip-address-no-zone
+---x establish-subscription
| +---w input rpcs:
| | +---w stream? stream +---x establish-subscription
| | +---w (filter-type)? | +---w input
| | | +--:(rfc5277) | | +---w stream? stream
| | | | +---w filter | | +---w encoding? encoding
| | | +--:(by-reference) | | +---w (filter-type)?
| | | +---w filter-ref? filter-ref | | | +--:(rfc5277)
| | +---w startTime? yang:date-and-time | | | | +---w filter?
| | +---w stopTime? yang:date-and-time | | | +--:(by-reference)
| | +---w encoding? encoding | | | +---w filter-ref? filter-ref
| +--ro output | | +---w startTime? yang:date-and-time
| +--ro subscription-result subscription-result | | +---w stopTime? yang:date-and-time
| +--ro (result)? | +--ro output
| +--:(success) | +--ro subscription-result subscription-result
| | +--ro subscription-id subscription-id | +--ro (result)?
| +--:(no-success) | +--:(success)
| +--ro stream? stream | | +--ro subscription-id subscription-id
| +--ro (filter-type)? | +--:(no-success)
| | +--:(rfc5277) | +--ro stream? stream
| | | +--ro filter | +--ro encoding? encoding
| | +--:(by-reference) | +--ro (filter-type)?
| | +--ro filter-ref? filter-ref | | +--:(rfc5277)
| +--ro startTime? yang:date-and-time | | | +--ro filter?
| +--ro stopTime? yang:date-and-time | | +--:(by-reference)
| +--ro encoding? encoding | | +--ro filter-ref? filter-ref
+---x modify-subscription | +--ro startTime? yang:date-and-time
| +---w input | +--ro stopTime? yang:date-and-time
| | +---w subscription-id? subscription-id +---x create-subscription
| | +---w stream? stream | +---w input
| | +---w (filter-type)? | +---w stream? stream
| | | +--:(rfc5277) | +---w encoding? encoding
| | | | +---w filter | +---w (filter-type)?
| | | +--:(by-reference) | | +--:(rfc5277)
| | | +---w filter-ref? filter-ref | | +---w filter?
| | +---w startTime? yang:date-and-time | +---w startTime? yang:date-and-time
| | +---w stopTime? yang:date-and-time | +---w stopTime? yang:date-and-time
| | +---w encoding? encoding +---x modify-subscription
| +--ro output | +---w input
| +--ro subscription-result subscription-result | | +---w subscription-id? subscription-id
| +--ro (result)? | | +---w (filter-type)?
| +--:(success) | | | +--:(rfc5277)
| | +--ro subscription-id subscription-id | | | | +---w filter?
| +--:(no-success) | | | +--:(by-reference)
| +--ro stream? stream | | | +---w filter-ref? filter-ref
| +--ro (filter-type)? | | +---w startTime? yang:date-and-time
| | +--:(rfc5277) | | +---w stopTime? yang:date-and-time
| | | +--ro filter | +--ro output
| | +--:(by-reference) | +--ro subscription-result subscription-result
| | +--ro filter-ref? filter-ref | +--ro (result)?
| +--ro startTime? yang:date-and-time | +--:(success)
| +--ro stopTime? yang:date-and-time | | +--ro subscription-id subscription-id
| +--ro encoding? encoding | +--:(no-success)
+---x delete-subscription | +--ro stream? stream
+---w input | +--ro encoding? encoding
| +---w subscription-id subscription-id | +--ro (filter-type)?
+--ro output | | +--:(rfc5277)
+--ro subscription-result subscription-result | | | +--ro filter?
notifications: | | +--:(by-reference)
+---n replay-complete | | +--ro filter-ref? filter-ref
| +--ro subscription-id subscription-id | +--ro startTime? yang:date-and-time
+---n notification-complete | +--ro stopTime? yang:date-and-time
| +--ro subscription-id subscription-id +---x delete-subscription
+---n subscription-started +---w input
| +--ro subscription-id subscription-id | +---w subscription-id subscription-id
| +--ro stream? stream +--ro output
| +--ro (filter-type)? +--ro subscription-result subscription-result
| | +--:(rfc5277)
| | | +--ro filter notifications:
| | +--:(by-reference) +---n replay-complete
| | +--ro filter-ref? filter-ref | +--ro subscription-id subscription-id
| +--ro startTime? yang:date-and-time +---n notification-complete
| +--ro stopTime? yang:date-and-time | +--ro subscription-id subscription-id
| +--ro encoding? encoding +---n subscription-started
+---n subscription-suspended | +--ro subscription-id subscription-id
| +--ro subscription-id subscription-id | +--ro stream? stream
| +--ro reason? subscription-susp-reason | +--ro encoding? encoding
+---n subscription-resumed | +--ro (filter-type)?
| +--ro subscription-id subscription-id | | +--:(rfc5277)
+---n subscription-modified | | | +--ro filter?
| +--ro subscription-id subscription-id | | +--:(by-reference)
| +--ro stream? stream | | +--ro filter-ref? filter-ref
| +--ro (filter-type)? | +--ro startTime? yang:date-and-time
| | +--:(rfc5277) | +--ro stopTime? yang:date-and-time
| | | +--ro filter +---n subscription-suspended
| | +--:(by-reference) | +--ro subscription-id subscription-id
| | +--ro filter-ref? filter-ref | +--ro reason? subscription-susp-reason
| +--ro startTime? yang:date-and-time +---n subscription-resumed
| +--ro stopTime? yang:date-and-time | +--ro subscription-id subscription-id
| +--ro encoding? encoding +---n subscription-modified
+---n subscription-terminated | +--ro subscription-id subscription-id
| +--ro subscription-id subscription-id | +--ro stream? stream
| +--ro reason? subscription-term-reason | +--ro encoding? encoding
+---n added-to-subscription | +--ro (filter-type)?
| +--ro subscription-id subscription-id | | +--:(rfc5277)
| +--ro stream? stream | | | +--ro filter?
| +--ro (filter-type)? | | +--:(by-reference)
| | +--:(rfc5277) | | +--ro filter-ref? filter-ref
| | | +--ro filter | +--ro startTime? yang:date-and-time
| | +--:(by-reference) | +--ro stopTime? yang:date-and-time
| | +--ro filter-ref? filter-ref +---n subscription-terminated
| +--ro startTime? yang:date-and-time +--ro subscription-id subscription-id
| +--ro stopTime? yang:date-and-time +--ro reason? subscription-term-reason
| +--ro encoding? encoding
+---n removed-from-subscription
+--ro subscription-id subscription-id
The data model is structured as follows: The data model is structured as follows:
o "Streams" contains a list of event streams that are supported by o "Streams" contains a list of event streams that are supported by
the event server and that can be subscribed to. the publisher and that can be subscribed to.
o "Filters" contains a configurable list of filters that can be o "Filters" contains a configurable list of filters that can be
applied to a subscription. This allows users to reference an applied to a subscription. This allows users to reference an
existing filter definition as an alternative to defining a filter existing filter definition as an alternative to defining a filter
inline for each subscription. inline for each subscription.
o "Subscription-config" contains the configuration of configured o "Subscription-config" contains the configuration of configured
subscriptions. The parameters of each configured subscription are subscriptions. The parameters of each configured subscription are
equivalent to the parameters of a dynamic subscription and use the a superset of the parameters of a dynamic subscription and use the
same groupings. In addition, the configured subscriptions specify same groupings. In addition, the configured subscriptions must
intended receivers and the push source from which to send the also specify intended receivers and may specify the push source
stream of notification messages. from which to send the stream of notification messages.
o "Subscriptions" contains a list of all subscriptions on an event o "Subscriptions" contains a list of all subscriptions on a
server, both configured and dynamic. It can be used do retrieve publisher, both configured and dynamic. It can be used to
information about the subscriptions which an event server is retrieve information about the subscriptions which an publisher is
serving. serving.
The data model also contains a number of notifications that allow an The data model also contains a number of notifications that allow a
event server to signal to the client information about a publisher to signal information about a subscription. Finally, the
subscription. Finally, the data model contains a number of RPC data model contains a number of RPC definitions that are used to
definitions that are used to manage dynamic subscriptions. manage dynamic subscriptions.
4. Dynamic Subscriptions 4. Dynamic Subscriptions
Dynamic subscriptions are managed via RPC. Dynamic subscriptions are managed via RPC.
4.1. Establishing a Subscription 4.1. Establishing a Subscription
This operation is an evolution of the "create-subscription" operation This operation includes and extends the "create-subscription"
defined in RFC 5277. It allows a subscriber to request the creation operation defined in RFC 5277. It allows a subscriber to request the
of a subscription both via RPC and configuration operations. When creation of a subscription both via RPC and configuration operations.
invoking the RPC, establish-subscription permits negotiating the When invoking the RPC, establish-subscription permits negotiating the
subscription terms, changing them dynamically. subscription terms, changing them dynamically.
The input parameters of the operation are those of create The input parameters of the operation are those of create
subscription plus: subscription plus:
o filter-ref: filters that have been previously (and separately) o filter-ref: filters that have been previously (and separately)
configured can be referenced by a subscription. This mechanism configured can be referenced by a subscription. This mechanism
enables the reuse of filters. enables the reuse of filters.
o encoding: by default, updates are encoded using XML. Other o encoding: by default, updates are encoded using XML. Other
encodings may be supported, such as JSON. encodings may be supported, such as JSON.
If the event server cannot satisfy the request, it sends a negative If the publisher cannot satisfy the request, it sends a negative
<subscription-result> element. <subscription-result> element.
If the client has no authorization to establish the subscription, the If the subscriber has no authorization to establish the subscription,
<subscription-result> indicates an authorization error. If the the <subscription-result> indicates an authorization error. If the
request is rejected because the server is not able to serve it, the request is rejected because the publisher is not able to serve it,
server SHOULD include in the returned error what subscription the publisher SHOULD include in the returned error what subscription
parameters would have been accepted for the request when it was parameters would have been accepted for the request when it was
processed. However, they is no guarantee that subsequent requests processed. However, they is no guarantee that subsequent requests
with those parameters for this client or others will be accepted. with those parameters for this subscriber or others will be accepted.
For instance, consider a subscription from For instance, consider a subscription from
[I-D.ietf-netconf-yang-push], which augments the establish- [I-D.ietf-netconf-yang-push], which augments the establish-
subscription with some additional parameters, including "period". subscription with some additional parameters, including "period".
Subscription requests will fail if a filter with invalid syntax is Subscription requests will fail if a filter with invalid syntax is
provided or if the name of a non-existent stream is provided. provided or if the name of a non-existent stream is provided.
4.2. Modifying a Subscription 4.2. Modifying a Subscription
This operation permits modifying the terms of a subscription This operation permits modifying the terms of a dynamic subscription
previously established. Subscriptions created by configuration previously established. Subscriptions created by configuration
cannot be modified. Dynamic subscriptions can be modified one or cannot be modified. Dynamic subscriptions can be modified one or
multiple times. If the server accepts the request, it immediately multiple times. If the publisher accepts the request, it immediately
starts sending events based on the new terms, completely ignoring the starts sending events based on the new terms, completely ignoring the
previous ones. If the server rejects the request, the subscription previous ones. If the publisher rejects the request, the
remains as prior to the request. That is, the request has no impact subscription remains as prior to the request. That is, the request
whatsoever. The contents of negative responses to modify- has no impact whatsoever. The contents of negative responses to
subscription requests are the same as in establish subscription modify-subscription requests are the subset of the establish
requests. subscription request parameters which are allowed to be dynamically
modified.
Dynamic subscriptions established via RPC can only be modified (or Dynamic subscriptions established via RPC can only be modified (or
deleted) via RPC using the same session used to establish it. deleted) via RPC using the same transport session used to establish
that subscription.
Configured subscriptions cannot be modified (or deleted) using RPCs. Configured subscriptions cannot be modified (or deleted) using RPCs.
Instead, configured subscriptions are modified (or deleted) as part Instead, configured subscriptions are modified (or deleted) as part
of regular configuration operations. Servers MUST reject any of regular configuration operations. Publishers MUST reject any
attempts to modify (or delete) configured subscriptions via RPC. attempts to modify (or delete) configured subscriptions via RPC.
The parameters to modify-subscription are those of establish-
subscription plus a mandatory subscription-id.
If the event server can satisfy the request, the server sends a
positive subscription-result. This response is like that to an
establish-subscription request without the subscription-id, which
would be redundant.
If the event server cannot satisfy the request, the server sends a
negative subscription-result. Its contents and semantics are
identical to those to an establish-subscription request.
4.3. Deleting a Subscription 4.3. Deleting a Subscription
This operation permits canceling a subscription previously This operation permits canceling a subscription previously
established. Created subscriptions cannot be explicitly deleted. If established. If the publisher accepts the request, it immediately
the server accepts the request, it immediately stops sending events stops sending events for the subscription. If the publisher rejects
for the subscription. If the server rejects the request, all the request, all subscriptions remain as prior to the request. That
subscriptions remain as prior to the request. That is, the request is, the request has no impact whatsoever.
has no impact whatsoever. A request may be rejected because the
provided subscription identifier is incorrect.
Subscriptions created via RPC can only be deleted via RPC using the Subscriptions created via RPC can only be deleted via RPC using the
same session used for establishment. Configured subscriptions cannot same transport session used for subscription establishment.
be deleted using RPCs. Instead, configured subscriptions are deleted Configured subscriptions cannot be deleted using RPCs. Instead,
as part of regular configuration operations. Servers MUST reject any configured subscriptions are deleted as part of regular configuration
RPC attempt to delete configured subscriptions. operations. Publishers MUST reject any RPC attempt to delete
configured subscriptions.
The only parameter to delete-subscription is the identifier of the The only parameter to delete-subscription is the identifier of the
subscription to delete. subscription to delete.
If the event server can satisfy the request, the server sends an OK If the publisher can satisfy the request, it sends an OK element.
element.
If the event server cannot satisfy the request, the server sends an If the publisher cannot satisfy the request, it sends an error-rpc
error-rpc element. element.
5. Configured Subscriptions 5. Configured Subscriptions
A configured subscription is a subscription installed via a A configured subscription is a subscription installed via a
configuration interface. configuration interface.
Configured subscriptions persist across reboots, and persist even Configured subscriptions persist across reboots, and persist even
when transport is unavailable. This also means configured when transport is unavailable. This also means configured
subscriptions do not support negotiation. subscriptions do not support negotiation.
Configured subscriptions can be modified by any configuration client Configured subscriptions can be modified by any configuration client
with write rights on the configuration of the subscription. with write permissions for the configuration of the subscription.
Subscriptions can be modified or terminated at any point of their Subscriptions can be modified or terminated at any point of their
lifetime. lifetime.
Supporting configured subscriptions is optional and advertised using Supporting configured subscriptions is optional and advertised using
the "configured-subscriptions" feature. the "configured-subscriptions" feature.
In addition to subscription parameters that apply to dynamic In addition to subscription parameters that apply to dynamic
subscriptions, the following additional parameters apply to subscriptions, the following additional parameters apply to
configured subscriptions: configured subscriptions:
o One or more receiver IP addresses (and corresponding ports) o One or more receiver IP addresses (and corresponding ports)
intended as the destination for push updates for each intended as the destination for push updates for each
subscription. In addition the transport protocol for each subscription. In addition, the transport protocol for each
destination may be defined. destination may be defined.
o Optional parameters to identify an egress interface or IP address o Optional parameters to identify an egress interface or IP address
/ VRF where a subscription updates should be pushed from the / VRF where a subscription updates should be pushed from the
publisher. publisher.
5.1. Creating a Configured Subscription 5.1. Establishing a Configured Subscription
Configured subscriptions cannot be created via configuration
operations. New clients should use the mechanisms described in
Section 5.2 for establishing configured subscriptions.
5.2. Establishing a Configured Subscription
Subscriptions can be established using configuration operations Configured subscriptions are established using configuration
against the top-level subtree subscription-config. There are two key operations against the top-level subtree subscription-config. There
differences between RPC and configuration operations for subscription are two key differences between RPC and configuration operations for
establishment. Firstly, configuration operations do not support subscription establishment. Firstly, configuration operations do not
negotiation while RPCs do. Secondly, while RPCs mandate that the support negotiation while RPCs do. Secondly, while RPCs mandate that
client establishing the subscription is the only receiver of the the subscriber establishing the subscription is the only receiver of
notifications, configuration operations permit specifying receivers the notifications, configuration operations permit specifying
independent of any tracked subscriber. Immediately after a receivers independent of any tracked subscriber. Immediately after a
subscription is successfully established, the server sends to the subscription is successfully established, the publisher sends to its
receivers a control-plane notification stating the subscription has receivers a control-plane notification stating the subscription has
been established (subscription-started). been established (subscription-started).
Because there is no explicit association with an existing transport Because there is no explicit association with an existing transport
session, configured configuration operations require additional session, configured configuration operations require additional
parameters to indicate the receivers of the notifications and parameters to indicate the receivers of the notifications and
possibly the source of the notifications (i.e., a specific interface possibly the source of the notifications such as a specific egress
or server address). interface.
For example at subscription establishment, a NETCONF client may send: For example at subscription establishment, a 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"> 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:netconf:notification:1.1"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.1">
skipping to change at page 16, line 46 skipping to change at page 15, line 40
1234 1234
</port> </port>
</receiver> </receiver>
</subscription> </subscription>
</subscription-config> </subscription-config>
</edit-config> </edit-config>
</rpc> </rpc>
Figure 2: Establish configured subscription Figure 2: Establish configured subscription
if the request is accepted, the server would reply: if the request is accepted, the publisher 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 3: Response to a successful configured subscription Figure 3: Response to a successful configured subscription
establishment establishment
if the request is not accepted because the server cannot serve it, if the request is not accepted because the publisher cannot serve it,
the server may reply: the publisher 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> <rpc-error>
<error-type>application</error-type> <error-type>application</error-type>
<error-tag>resource-denied</error-tag> <error-tag>resource-denied</error-tag>
<error-severity>error</error-severity> <error-severity>error</error-severity>
<error-message xml:lang="en"> <error-message xml:lang="en">
Temporarily the server cannot serve this Temporarily the publisher cannot serve this
subscription due to the current workload. subscription due to the current workload.
</error-message> </error-message>
</rpc-error> </rpc-error>
</rpc-reply> </rpc-reply>
Figure 4: Response to a failed configured subscription establishment Figure 4: Response to a failed configured subscription establishment
5.3. Modifying a Configured Subscription 5.2. 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.
Immediately after a subscription is successfully modified, the server Immediately after a subscription is successfully modified, the
sends to the existing receivers a control-plane notification stating publisher sends to the existing receivers a control-plane
the subscription has been modified (i.e., subscription-modified). notification stating the subscription has been modified (i.e.,
subscription-modified).
If the modification involved adding and/or removing receivers, those If the modification involved adding and/or removing receivers, those
modified receivers are sent control-plane notifications, indicating modified receivers are sent control-plane notifications, indicating
they have been added (i.e, added-to-subscription, with the same they have been added (i.e, subscription-started to a specific
contents as a modified-subscription) or removed (i.e., removed-from- receiver) or removed (i.e., subscription-terminated to a specific
subscription) receiver.)
5.4. Deleting a Configured Subscription 5.3. 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, in RESTCONF: the top-level subtree subscription-config. For example, in RESTCONF:
DELETE /subscription-config/subscription=1922 HTTP/1.1 DELETE /subscription-config/subscription=1922 HTTP/1.1
Host: example.com Host: example.com
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Sun, 24 Jul 2016 11:23:40 GMT Date: Sun, 24 Jul 2016 11:23:40 GMT
Server: example-server Server: example-server
Figure 5: Deleting a configured subscription Figure 5: Deleting a configured subscription
Immediately after a subscription is successfully deleted, the event Immediately after a subscription is successfully deleted, the
server sends to the receivers a control-plane notification stating publisher sends to all receivers a control-plane notification stating
the subscription has been terminated (subscription-terminated). the subscription has been terminated (subscription-terminated).
6. Event (Data Plane) Notifications 6. Event (Data Plane) Notifications
Once a subscription has been set up, the event server sends Once a subscription has been set up, the publisher streams
(asynchronously) the event notifications from the subscribed stream. (asynchronously) the event notifications per the terms of the
We refer to these as data plane notifications. For dynamic subscription. We refer to these as data plane notifications. For
subscriptions set up via RPC operations, event notifications are sent dynamic subscriptions set up via RPC operations, event notifications
over the session used to create or establish the subscription. For are sent over the session used to create or establish the
configured subscriptions, event notifications are sent over the subscription. For configured subscriptions, event notifications are
specified connections. sent over the specified connections.
An event notification is sent to the receiver(s) when an event of An event notification is sent to the receiver(s) when an event of
interest (i.e., meeting the specified filtering criteria) has interest (i.e., meeting the specified filtering criteria) has
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 a Remote Procedure Call document. Note that <notification> is not a Remote Procedure Call
(RPC) method but rather the top-level element identifying the one-way (RPC) method but rather the top-level element identifying the one-way
message as a notification. Note that event notifications never message as a notification. Note that event notifications never
trigger responses. trigger responses.
The event notification always includes an <eventTime> element. It is The event notification always includes an <eventTime> element. It is
the time the event was generated by the event source. This parameter the time the event was generated by the event source. This parameter
is of type dateTime and compliant to [RFC3339]. Implementations must is of type dateTime and compliant to [RFC3339]. Implementations must
support time zones. support time zones.
The event notification also contains notification-specific tagged The event notifications must also include the subscription-id if the
content, if any. With the exception of <eventTime>, the content of establish-subscription was used in its establishment, or if it was
the notification is beyond the scope of this document. configured via an operational interface.
For the encodings other than XML, notifications include an additional The event notification also contains notification-specific tagged
XML element so that the notification is a well-formed XML. The content, if any.
element is <notification-contents-{encoding}>, E.g., <notification-
contents-json>. That element contains the notification contents in
the desired encoding
The following is an example of an event notification from [RFC6020]: The following is an example of an event notification from [RFC7950]:
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;
skipping to change at page 20, line 7 skipping to change at page 18, line 37
"if-oper-status": "down " "if-oper-status": "down "
} }
} }
</notification-contents-json> </notification-contents-json>
</notification> </notification>
Figure 8: Data plane notification using JSON encoding Figure 8: Data plane notification using JSON encoding
7. Control Plane Notifications 7. Control Plane Notifications
In addition to data plane notifications, a server may send control In addition to data plane notifications, a publisher may send control
plane notifications to indicate to receivers that an event related to plane notifications to indicate to receivers that an event related to
the subscription management has occurred. the subscription management has occurred.
Control plane notifications are unlike other notifications in that Control plane notifications are unlike other notifications in that
they are not general-purpose notifications. They cannot be filtered they are not general-purpose notifications. They cannot be filtered
out, and they are delivered only to the receiver of a subscription. out, and they are delivered only to the receiver of a subscription.
The definition of control plane notifications is distinct from other The definition of control plane notifications is distinct from other
notifications by making use of a YANG extension tagging them as notifications by making use of a YANG extension tagging them as
control plane notification. control plane notification.
Control plane notifications include indications that a replay of Control plane notifications include indications that a replay of
notifications has been completed, that a subscription is done sending notifications has been completed, that a subscription is done sending
notifications because an end time has been reached, and that a notifications because an end time has been reached, and that a
subscription has started, been modified, been terminated, or been subscription has started, been modified, been terminated, or been
suspended. They are described in the following subsections. suspended. They are described in the following subsections.
7.1. replayComplete 7.1. replayComplete
This notification is originally defined in [RFC5277]. It is sent to This notification is originally defined in [RFC5277]. It is sent to
indicate that all of the replay notifications have been sent and must indicate that all of the replay notifications have been sent. This
not be sent for any other reason. notification must not be sent for any other reason.
In the case of a subscription without a stop time, after the In the case of a subscription without a stop time or a stop time
<replayComplete> notification has been sent, it can be expected that which has not been reached, after the <replayComplete> notification
any notifications generated since the start of the subscription has been sent, it can be expected that any notifications generated
creation will be sent, followed by notifications as they arise since the start of the subscription creation will be sent, followed
naturally within the system. by notifications in sequence as they arise naturally within the
system.
7.2. notificationComplete 7.2. notificationComplete
This notification is originally defined in [RFC5277]. It is sent to This notification is originally defined in [RFC5277]. It is sent to
indicate that a subscription, which includes a stop time, has indicate that a subscription, which includes a stop time, has
finished passing events. finished passing events.
7.3. subscription-started 7.3. subscription-started
This notification indicates that a configured subscription has This notification indicates that a configured subscription has
skipping to change at page 21, line 15 skipping to change at page 19, line 42
7.4. subscription-modified 7.4. subscription-modified
This notification indicates that a configured subscription has been This notification indicates that a configured subscription has been
modified successfully. This notification includes the parameters of modified successfully. This notification includes the parameters of
the subscription, except for the receiver(s) addressing information the subscription, except for the receiver(s) addressing information
and push-source information. Note that for RPC-based subscriptions, and push-source information. Note that for RPC-based subscriptions,
no such notifications are sent. no such notifications are sent.
7.5. subscription-terminated 7.5. subscription-terminated
This notification indicates that a subscription has been terminated. This notification indicates that a subscription has been terminated
The notification includes the reason for the termination. A by the publisher. The notification includes the reason for the
subscription may be terminated by a server or by a client. The termination. The publisher may decide to terminate a subscription
server may decide to terminate a subscription when it is running out when it is running out of resources for serving it, an internal error
of resources for serving it, an internal error occurs, etc. Server- occurs, etc. Publisher-driven terminations are notified to all
driven terminations are notified to all receivers. The management receivers. The management plane can also terminate configured
plane can also terminate configured subscriptions using configuration subscriptions using configuration operations.
operations.
Clients can terminate via RPC subscriptions established via RPC. In Subscribers can terminate via RPC subscriptions established via RPC.
such cases, no subscription-terminated notifications are sent. In such cases, no subscription-terminated notifications are sent.
7.6. subscription-suspended 7.6. subscription-suspended
This notification indicates that a server has suspended a This notification indicates that a publisher has suspended a
subscription. The notification includes the reason for the subscription. The notification includes the reason for the
suspension. A possible reason is the lack of resources to serve it. suspension. A possible reason is the lack of resources to serve it.
No further data plane notifications will be sent until the No further data plane notifications will be sent until the
subscription resumes. Suspensions are notified to the subscriber (in subscription resumes. Suspensions are notified to the subscriber (in
the case of dynamic subscriptions) and all receivers (in the case of the case of dynamic subscriptions) and all receivers (in the case of
configured subscriptions). configured subscriptions).
7.7. subscription-resumed 7.7. subscription-resumed
This notification indicates that a previously suspended dubscription This notification indicates that a previously suspended dubscription
has been resumed. Data plane notifications generated in the future has been resumed. Data plane notifications generated in the future
will be sent after the subscription terms. Resumptions are notified will be sent after the subscription terms. Resumptions are notified
to the subscriber (in the case of dynamic subscriptions) and all to the subscriber (in the case of dynamic subscriptions) and all
receivers (in the case of configured subscriptions). receivers (in the case of configured subscriptions).
8. Data Model for Event Notifications 8. Data Model for Event Notifications
<CODE BEGINS> <CODE BEGINS> file "ietf-event-notifications@2016-10-27.yang"
file "ietf-event-notifications@2016-09-11.yang" module ietf-event-notifications {
module ietf-event-notifications { namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-event-notifications";
"urn:ietf:params:xml:ns:yang:ietf-event-notifications";
prefix notif-bis; prefix notif-bis;
import ietf-inet-types { import ietf-yang-types {
prefix inet; prefix yang;
} }
import ietf-5277-netmod { import ietf-inet-types {
prefix netmod-notif; prefix inet;
} }
import ietf-5277-netconf { import ietf-interfaces {
prefix notif; prefix if;
} }
import ietf-interfaces {
prefix if;
}
organization "IETF"; organization "IETF";
contact contact
"WG Web: <http://tools.ietf.org/wg/netconf/> "WG Web: &lt;http://tools.ietf.org/wg/netconf/&gt;
WG List: <mailto:netconf@ietf.org> WG List: &lt;mailto:netconf@ietf.org&gt;
WG Chair: Mahesh Jethanandani WG Chair: Mahesh Jethanandani
<mailto:mjethanandani@gmail.com> &lt;mailto:mjethanandani@gmail.com&gt;
WG Chair: Mehmet Ersue WG Chair: Mehmet Ersue
<mailto:mehmet.ersue@nokia.com> &lt;mailto:mehmet.ersue@nokia.com&gt;
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:ludwig@clemm.org> &lt;mailto:alex@sympotech.com&gt;
Editor: Alberto Gonzalez Prieto Editor: Alberto Gonzalez Prieto
<mailto:albertgo@cisco.com> &lt;mailto:albertgo@cisco.com&gt;
Editor: Eric Voit Editor: Eric Voit
<mailto:evoit@cisco.com> &lt;mailto:evoit@cisco.com&gt;
Editor: Einar Nilsen-Nygaard Editor: Einar Nilsen-Nygaard
<mailto:einarnn@cisco.com> &lt;mailto:einarnn@cisco.com&gt;
Editor: Ambika Prasad Tripathy Editor: Ambika Prasad Tripathy
<mailto:ambtripa@cisco.com> &lt;mailto:ambtripa@cisco.com&gt;
Editor: Sharon Chisholm Editor: Sharon Chisholm
<mailto:schishol@ciena.com> &lt;mailto:schishol@ciena.com&gt;
Editor: Hector Trevino Editor: Hector Trevino
<mailto:htrevino@cisco.com"; &lt;mailto:htrevino@cisco.com";
description description
"This module contains conceptual YANG specifications "This module contains conceptual YANG specifications
for NETCONF Event Notifications."; for NETCONF Event Notifications.";
revision 2016-09-11 { revision 2016-10-27 {
description description
"Initial version. Model for NETCONF Notifications (bis)"; "Tweaks to remove two notifications,
reference RPC for create subscription refined with stream default,
"draft-ietf-netconf-rfc5277bis-00"; new grouping to eliminate some dymanically modifiable
} parameters in modifiy subscription RPC";
reference
"draft-ietf-netconf-rfc5277bis-01";
}
/* /*
* FEATURES * FEATURES
*/ */
feature json { feature json {
description description
"This feature indicates that JSON encoding of notifications "This feature indicates that JSON encoding of notifications
is supported."; is supported.";
} }
feature configured-subscriptions { feature configured-subscriptions {
description description
"This feature indicates that management plane configuration "This feature indicates that management plane configuration
of subscription is supported."; of subscription is supported.";
} }
/* /*
* IDENTITIES * EXTENSIONS
*/ */
/* Identities for subscription results */ extension control-plane-notif {
identity subscription-result { description
description "This statement applies only to notifications.
"Base identity for RPC responses to requests surrounding It indicates that the notification is a control-plane
management (e.g. creation, modification, deletion) of notification (aka OAM notification). Therefore it does
subscriptions."; not participate in a regular event stream and does not
} need to be specifically subscribed to.";
}
identity ok { /*
base subscription-result; * IDENTITIES
description */
"OK - RPC was successful and was performed as requested.";
}
identity error { /* Identities for streams */
base subscription-result; identity stream {
description description
"RPC was not successful. "Base identity to represent a generic stream of event
Base identity for error return codes."; notifications.";
} }
identity error-no-such-subscription { identity NETCONF {
base error; base stream;
description description
"A subscription with the requested subscription ID "Default NETCONF event stream, containing events based on
does not exist."; notifications defined as YANG modules that are supported
} by the system.";
}
identity error-no-such-option { /* Identities for subscription results */
base error; identity subscription-result {
description description
"A requested parameter setting is not supported."; "Base identity for RPC responses to requests surrounding
} management (e.g. creation, modification, deletion) of
subscriptions.";
}
identity error-insufficient-resources { identity ok {
base error; base subscription-result;
description description
"The server has insufficient resources to support the "OK - RPC was successful and was performed as requested.";
subscription as requested.";
}
identity error-configured-subscription { }
base error;
description
"Cannot apply RPC to a configured subscription, i.e.
to a subscription that was not established via RPC.";
}
identity error-other { identity error {
base error; base subscription-result;
description description
"An unspecified error has occurred (catch all)."; "RPC was not successful.
} Base identity for error return codes.";
}
/* Identities for subscription stream status */ identity error-no-such-subscription {
identity subscription-stream-status { base error;
description description
"Base identity for the status of subscriptions and "A subscription with the requested subscription ID
datastreams."; does not exist.";
} }
identity active { identity error-no-such-option {
base subscription-stream-status; base error;
description description
"Status is active and healthy."; "A requested parameter setting is not supported.";
}
} identity error-insufficient-resources {
base error;
description
"The publisher has insufficient resources to support the
subscription as requested.";
}
identity inactive { identity error-configured-subscription {
base subscription-stream-status; base error;
description description
"Status is inactive, for example outside the "Cannot apply RPC to a configured subscription, i.e.
interval between start time and stop time."; to a subscription that was not established via RPC.";
} }
identity suspended { identity error-other {
base subscription-stream-status; base error;
description description
"The status is suspended, meaning that the push server "An unspecified error has occurred (catch all).";
is currently unable to provide the negotiated updates }
for the subscription.";
}
identity in-error { /* Identities for subscription stream status */
base subscription-stream-status; identity subscription-stream-status {
description description
"The status is in error or degraded, meaning that "Base identity for the status of subscriptions and
stream and/or subscription is currently unable to provide datastreams.";
the negotiated notifications."; }
} identity active {
base subscription-stream-status;
description
"Status is active and healthy.";
}
/* Identities for subscription errors */ identity inactive {
identity subscription-errors { base subscription-stream-status;
description description
"Base identity for subscription error status. "Status is inactive, for example outside the
This identity is not to be confused with error return interval between start time and stop time.";
codes for RPCs"; }
}
identity internal-error { identity suspended {
base subscription-errors; base subscription-stream-status;
description description
"Subscription failures caused by server internal error."; "The status is suspended, meaning that the publisher
} is currently unable to provide the negotiated updates
for the subscription.";
}
identity no-resources { identity in-error {
base subscription-errors; base subscription-stream-status;
description description
"Lack of resources, e.g. CPU, memory, bandwidth"; "The status is in error or degraded, meaning that
} stream and/or subscription is currently unable to provide
the negotiated notifications.";
}
identity subscription-deleted { /* Identities for subscription errors */
base subscription-errors; identity subscription-errors {
description description
"The subscription was terminated because the subscription "Base identity for subscription error status.
was deleted."; This identity is not to be confused with error return
} codes for RPCs";
}
identity other { identity internal-error {
base subscription-errors; base subscription-errors;
description description
"Fallback reason - any other reason"; "Subscription failures caused by server internal error.";
} }
/* Identities for encodings */ identity no-resources {
identity encodings { base subscription-errors;
description description
"Base identity to represent data encodings"; "Lack of resources, e.g. CPU, memory, bandwidth";
} }
identity subscription-deleted {
base subscription-errors;
description
"The subscription was terminated because the subscription
was deleted.";
}
identity encode-xml { identity other {
base encodings; base subscription-errors;
description description
"Encode data using XML"; "Fallback reason - any other reason";
} }
identity encode-json { /* Identities for encodings */
base encodings; identity encodings {
description description
"Encode data using JSON"; "Base identity to represent data encodings";
} }
/* Identities for transports */ identity encode-xml {
identity transport { base encodings;
description description
"An identity that represents a transport protocol for event "Encode data using XML";
notifications"; }
}
identity netconf { identity encode-json {
base transport; base encodings;
description description
"Netconf notifications as a transport."; "Encode data using JSON";
} }
/* /* Identities for transports */
* TYPEDEFs identity transport {
*/ description
"An identity that represents a transport protocol for
event notifications";
}
typedef subscription-id { identity netconf {
type uint32; base transport;
description description
"A type for subscription identifiers."; "Netconf notifications as a transport.";
} }
typedef filter-id { /*
type uint32; * TYPEDEFs
description */
"A type to identify filters which can be associated with a
subscription.";
}
typedef subscription-result { typedef subscription-id {
type identityref { type uint32;
base subscription-result; description
} "A type for subscription identifiers.";
description }
"The result of a subscription operation";
}
typedef subscription-term-reason { typedef filter-id {
type identityref { type uint32;
base subscription-errors; description
} "A type to identify filters which can be associated with a
description subscription.";
"Reason for a server to terminate a subscription."; }
}
typedef subscription-susp-reason { typedef subscription-result {
type identityref { type identityref {
base subscription-errors; base subscription-result;
} }
description description
"Reason for a server to suspend a subscription."; "The result of a subscription operation";
} }
typedef encoding { typedef subscription-term-reason {
type identityref { type identityref {
base encodings; base subscription-errors;
} }
description description
"Specifies a data encoding, e.g. for a data subscription."; "Reason for a publisher to terminate a subscription.";
} }
typedef subscription-status { typedef subscription-susp-reason {
type identityref { type identityref {
base subscription-stream-status; base subscription-errors;
} }
description description
"Specifies the status of a subscription or datastream."; "Reason for a publisher to suspend a subscription.";
}
} typedef encoding {
type identityref {
base encodings;
}
description
"Specifies a data encoding, e.g. for a data subscription.";
}
typedef transport-protocol { typedef subscription-status {
type identityref { type identityref {
base transport; base subscription-stream-status;
}
description
"Specifies transport protocol used to send notifications to a
receiver.";
}
typedef push-source { }
type enumeration { description
enum "interface-originated" { "Specifies the status of a subscription or datastream.";
description }
"Notifications will be sent from a specific interface on a
NETCONF server";
}
enum "address-originated" {
description
"Notifications will be sent from a specific address on a
NETCONF server";
}
}
description
"Specifies from where notifications will be sourced when
being sent by the NETCONF server.";
}
typedef filter-ref { typedef transport-protocol {
type leafref { type identityref {
path "/notif-bis:filters/notif-bis:filter/notif-bis:filter-id"; base transport;
} }
description description
"This type is used to reference a filter."; "Specifies transport protocol used to send notifications to a
} receiver.";
}
/* typedef push-source {
* GROUPINGS type enumeration {
*/ enum "interface-originated" {
description
"Notifications will be sent from a specific interface on
a publisher";
}
enum "address-originated" {
description
"Notifications will be sent from a specific address on a
publisher";
}
}
description
"Specifies from where notifications will be sourced when
being sent by the publisher.";
}
grouping subscription-info { typedef stream {
description type identityref {
"This grouping describes basic information concerning a base stream;
subscription."; }
uses notif:subscription-info-5277 { description
augment "filter-type" { "Specifies a system-provided datastream.";
description }
"Post-5277 subscriptions allow references to existing
filters";
case by-reference {
description
"Incorporate a filter that has been configured
separately.";
leaf filter-ref {
type filter-ref;
description
"References filter which is associated with the
subscription.";
}
}
}
}
leaf encoding {
type encoding;
default "encode-xml";
description
"The type of encoding for the subscribed data.
Default is XML";
}
}
grouping push-source-info { typedef filter-ref {
description type leafref {
"Defines the sender source from which notifications path "/notif-bis:filters/notif-bis:filter/notif-bis:filter-id";
for a configured subscription are sent."; }
choice push-source { description
description "This type is used to reference a filter.";
"Identifies the egress interface on the Publisher from }
which notifications will or are being sent."; /*
case interface-originated { * GROUPINGS
description */
"When the push source is out of an interface on the
Publisher established via static configuration.";
leaf source-interface {
type if:interface-ref;
description
"References the interface for notifications.";
}
}
case address-originated {
description
"When the push source is out of an IP address on the
Publisher established via static configuration.";
leaf source-vrf {
type uint32 {
range "16..1048574";
}
description
"Label of the vrf.";
}
leaf source-address {
type inet:ip-address-no-zone;
mandatory true;
description
"The source address for the notifications.";
}
}
}
}
grouping receiver-info { grouping base-filter {
description description
"Defines where and how to deliver notifications for a "This grouping defines the base for filters for
configured subscription. This includes notification events.
specifying the receiver, as well as defining It includes the filter defined in 5277 and
any network and transport aspects when sending of it enables extending filtering to other
notifications occurs outside of Netconf."; types of filters";
container receivers { choice filter-type {
description description
"Set of receivers in a subscription."; "A filter needs to be a single filter of a given type.
list receiver { Mixing and matching of multiple filters does not occur
key "address"; at the level of this grouping.";
min-elements 1; case rfc5277 {
description anyxml filter {
"A single host or multipoint address intended as a target description
for the notifications for a subscription."; "Filter per RFC 5277. Notification filter.
leaf address { If a filter element is specified to look for data of a
type inet:host; particular value, and the data item is not present
mandatory true; within a particular event notification for its value to
description be checked against, the notification will be filtered
"Specifies the address for the traffic to reach a out. For example, if one were to check for
remote host. One of the following must be 'severity=critical' in a configuration event
specified: an ipv4 address, an ipv6 address, notification where this field was not supported, then
or a host name."; the notification would be filtered out. For subtree
} filtering, a non-empty node set means that the filter
leaf port { matches. For XPath filtering, the mechanisms defined
type inet:port-number; in [XPATH] should be used to convert the returned
mandatory true; value to boolean.";
description }
"This leaf specifies the port number to use for messages }
destined for a receiver."; }
} }
leaf protocol {
type transport-protocol;
default "netconf";
description
"This leaf specifies the transport protocol used
to deliver messages destined for the receiver.";
}
}
}
}
grouping subscription-response { grouping subscription-info-basic-non-modifiable {
description description
"Defines the output to the rpc's establish-subscription "This grouping describes the information in a basic
and modify-subscription."; subscription request.";
leaf subscription-result { leaf stream {
type subscription-result; type stream;
mandatory true; description
description "Indicates which stream of events is of interest.
"Indicates whether subscription is operational, If not present, events in the default NETCONF stream
or if a problem was encountered."; will be sent.";
} }
choice result { leaf encoding {
description type encoding;
"Depending on the subscription result, different default "encode-xml";
data is returned."; description
case success { "The type of encoding for the subscribed data.
description Default is XML";
"This case is used when the subscription request }
was successful and a subscription was created/modified }
as a result";
leaf subscription-id {
type subscription-id;
mandatory true;
description
"Identifier used for this subscription.";
}
}
case no-success {
description
"This case applies when a subscription request
was not successful and no subscription was
created (or modified) as a result. In this case,
information MAY be returned that indicates
suggested parameter settings that would have a
high likelihood of succeeding in a subsequent
establish-subscription or modify-subscription
request.";
uses subscription-info;
} grouping subscription-info-basic-modifiable {
} description
} "This grouping describes some objects which may be changed
in a subscription via an RPC.";
uses base-filter;
leaf startTime {
type yang:date-and-time;
description
"Used to trigger the replay feature
and indicate that the replay should start at the time
specified. If <startTime> is not present, this is not a
replay subscription. It is not valid to specify start
times that are later than the current time. If the
<startTime> specified is earlier than the log can support,
the replay will begin with the earliest available
notification. This parameter is of type dateTime and
compliant to [RFC3339]. Implementations must
support time zones.";
}
leaf stopTime {
type yang:date-and-time;
must "current() > ../startTime" {
description
"stopTime must be used with and be later than <startTime>";
}
description
"Used with the optional replay feature to indicate the
newest notifications of interest. If <stopTime> is
not present, the notifications will continue until the
subscription is terminated. Must be used with and be
later than <startTime>. Values of <stopTime> in the
future are valid. This parameter is of type dateTime and
compliant to [RFC3339]. Implementations must support time
zones.";
}
}
/* grouping subscription-info-all-modifiable {
* RPCs description
*/ "This grouping describes all rpc modifiable objects in a
subscription.";
uses subscription-info-basic-modifiable {
augment "filter-type" {
description
"Post-5277 subscriptions allow references to existing
filters";
case by-reference {
description
"Incorporate a filter that has been configured
separately.";
leaf filter-ref {
type filter-ref;
description
"References filter which is associated with the
subscription.";
}
}
}
}
}
rpc establish-subscription { grouping subscription-info {
description description
"This RPC allows a subscriber to create "This grouping describes information concerning a
(and possibly negotiate) a subscription on its own behalf. subscription.";
If successful, the subscription uses subscription-info-basic-non-modifiable;
remains in effect for the duration of the subscriber's uses subscription-info-all-modifiable;
association with the publisher, or until the subscription }
is terminated by virtue of a delete-subscription request.
In case an error (as indicated by subscription-result)
is returned, the subscription is
not created. In that case, the RPC output
MAY include suggested parameter settings
that would have a high likelihood of succeeding in a
subsequent create-subscription request.";
input {
uses subscription-info;
}
output {
uses subscription-response;
}
}
rpc modify-subscription { grouping push-source-info {
description description
"This RPC allows a subscriber to modify a subscription "Defines the sender source from which notifications
that was previously created using create-subscription. for a configured subscription are sent.";
If successful, the subscription choice push-source {
remains in effect for the duration of the subscriber's description
association with the publisher, or until the subscription "Identifies the egress interface on the Publisher from
is terminated by virtue of a delete-subscription request. which notifications will or are being sent.";
In case an error is returned (as indicated by case interface-originated {
subscription-result), the subscription is description
not modified and the original subscription parameters "When the push source is out of an interface on the
remain in effect. In that case, the rpc error response Publisher established via static configuration.";
MAY include suggested parameter settings leaf source-interface {
that would have a high likelihood of succeeding in a type if:interface-ref;
subsequent modify-subscription request."; description
input { "References the interface for notifications.";
leaf subscription-id { }
type subscription-id; }
description case address-originated {
"Identifier to use for this subscription."; description
} "When the push source is out of an IP address on the
uses subscription-info; Publisher established via static configuration.";
} leaf source-vrf {
output { type uint32 {
uses subscription-response; range "16..1048574";
} }
} description
"Label of the vrf.";
}
leaf source-address {
type inet:ip-address-no-zone;
mandatory true;
description
"The source address for the notifications.";
}
}
}
}
rpc delete-subscription { grouping receiver-info {
description description
"This RPC allows a subscriber to delete a subscription that "Defines where and how to deliver notifications for a
was previously created using create-subscription."; configured subscription. This includes
input { specifying the receiver, as well as defining
leaf subscription-id { any network and transport aspects when sending of
type subscription-id; notifications occurs outside of Netconf.";
mandatory true; container receivers {
description description
"Identifier of the subscription that is to be deleted. "Set of receivers in a subscription.";
Only subscriptions that were created using list receiver {
create-subscription can be deleted via this RPC."; key "address";
} min-elements 1;
} description
output { "A single host or multipoint address intended as a target
leaf subscription-result { for the notifications for a subscription.";
type subscription-result; leaf address {
mandatory true; type inet:host;
description mandatory true;
"Indicates whether subscription is operational, description
or if a problem was encountered."; "Specifies the address for the traffic to reach a
} remote host. One of the following must be
} specified: an ipv4 address, an ipv6 address,
} or a host name.";
}
leaf port {
type inet:port-number;
mandatory true;
description
"This leaf specifies the port number to use for
messages destined for a receiver.";
}
leaf protocol {
type transport-protocol;
default "netconf";
description
"This leaf specifies the transport protocol used
to deliver messages destined for the receiver.";
}
}
}
}
/* grouping subscription-response {
* NOTIFICATIONS description
*/ "Defines the output to the rpc's establish-subscription
and modify-subscription.";
leaf subscription-result {
type subscription-result;
mandatory true;
description
"Indicates whether subscription is operational,
or if a problem was encountered.";
}
choice result {
description
"Depending on the subscription result, different
data is returned.";
case success {
description
"This case is used when the subscription request
was successful and a subscription was created/modified
as a result";
leaf subscription-id {
type subscription-id;
mandatory true;
description
"Identifier used for this subscription.";
}
}
case no-success {
description
"This case applies when a subscription request
was not successful and no subscription was
created (or modified) as a result. In this case,
information MAY be returned that indicates
suggested parameter settings that would have a
high likelihood of succeeding in a subsequent
establish-subscription or modify-subscription
request.";
uses subscription-info;
}
}
}
notification replay-complete { /*
netmod-notif:control-plane-notif; * RPCs
description */
"This notification is sent to indicate that all of the
replay notifications have been sent. It must not be
sent for any other reason.";
leaf subscription-id {
type subscription-id;
mandatory true;
description
"This references the affected subscription.";
}
}
notification notification-complete { rpc establish-subscription {
netmod-notif:control-plane-notif; description
description "This RPC allows a subscriber to create
"This notification is sent to indicate that a (and possibly negotiate) a subscription on its own behalf.
subscription, which includes a stop time, has If successful, the subscription
finished passing events."; remains in effect for the duration of the subscriber's
leaf subscription-id { association with the publisher, or until the subscription
type subscription-id; is terminated by virtue of a delete-subscription request.
mandatory true; In case an error (as indicated by subscription-result)
description is returned, the subscription is
"This references the affected subscription."; not created. In that case, the RPC output
} MAY include suggested parameter settings
} that would have a high likelihood of succeeding in a
subsequent establish-subscription request.";
input {
uses subscription-info;
}
output {
uses subscription-response;
}
}
notification subscription-started { rpc create-subscription {
netmod-notif:control-plane-notif; description
description "This operation initiates an event notification subscription
"This notification indicates that a subscription has that will send asynchronous event notifications to the
started and notifications are beginning to be sent. initiator of the command until the association terminates.
This notification shall only be sent to receivers It is not possible to modify or delete a subscription
of a subscription; it does not constitute a general-purpose that was created using this operation. It is included for
notification."; reasons of backward compatibility with RFC 5277
leaf subscription-id { implementations.";
type subscription-id; input {
mandatory true; uses subscription-info-basic-non-modifiable{
description refine "stream" {
"This references the affected subscription."; default "NETCONF";
} }
uses subscription-info; }
} uses subscription-info-basic-modifiable;
}
}
notification subscription-suspended { rpc modify-subscription {
netmod-notif:control-plane-notif; description
description "This RPC allows a subscriber to modify a subscription
"This notification indicates that a suspension of the that was previously created using establish-subscription.
subscription by the server has occurred. No further If successful, the subscription
notifications will be sent until subscription remains in effect for the duration of the subscriber's
resumes. association with the publisher, or until the subscription
This notification shall only be sent to receivers is terminated by virtue of a delete-subscription request.
of a subscription; it does not constitute a general-purpose In case an error is returned (as indicated by
notification."; subscription-result), the subscription is
leaf subscription-id { not modified and the original subscription parameters
type subscription-id; remain in effect. In that case, the rpc error response
mandatory true; MAY include suggested parameter settings
description that would have a high likelihood of succeeding in a
"This references the affected subscription."; subsequent modify-subscription request.";
} input {
leaf reason { leaf subscription-id {
type subscription-susp-reason; type subscription-id;
description description
"Provides a reason for why the subscription was "Identifier to use for this subscription.";
suspended."; }
} uses subscription-info-all-modifiable;
} }
output {
uses subscription-response;
}
}
notification subscription-resumed { rpc delete-subscription {
netmod-notif:control-plane-notif; description
description "This RPC allows a subscriber to delete a subscription that
"This notification indicates that a subscription that had was previously created using establish-subscription.";
previously been suspended has resumed. Notifications input {
will once again be sent."; leaf subscription-id {
leaf subscription-id { type subscription-id;
type subscription-id; mandatory true;
mandatory true; description
description "Identifier of the subscription that is to be deleted.
"This references the affected subscription."; Only subscriptions that were created using
} establish-subscription can be deleted via this RPC.";
} }
notification subscription-modified { }
netmod-notif:control-plane-notif; output {
description leaf subscription-result {
"This notification indicates that a subscription has type subscription-result;
been modified. Notifications sent from this point mandatory true;
on will conform to the modified terms of the description
subscription."; "Indicates whether subscription is operational,
leaf subscription-id { or if a problem was encountered.";
type subscription-id; }
mandatory true; }
description }
"This references the affected subscription.";
}
uses subscription-info;
}
notification subscription-terminated { /*
netmod-notif:control-plane-notif; * NOTIFICATIONS
description */
"This notification indicates that a subscription has been
terminated.";
leaf subscription-id { notification replay-complete {
type subscription-id; notif-bis:control-plane-notif;
mandatory true; description
description "This notification is sent to indicate that all of the
"This references the affected subscription."; replay notifications have been sent. It must not be
} sent for any other reason.";
leaf reason { leaf subscription-id {
type subscription-term-reason; type subscription-id;
description mandatory true;
"Provides a reason for why the subscription was description
terminated."; "This references the affected subscription.";
} }
} }
notification added-to-subscription { notification notification-complete {
netmod-notif:control-plane-notif; notif-bis:control-plane-notif;
description description
"This notification is sent to a receiver when it has been "This notification is sent to indicate that a
added to an existing subscription. subscription, which includes a stop time, has
Note that if the receiver is added when the subscription finished passing events.";
is created, it will receive a subscription-started leaf subscription-id {
notification and no added-to-subscription."; type subscription-id;
leaf subscription-id { mandatory true;
type subscription-id; description
mandatory true; "This references the affected subscription.";
description }
"This references the affected subscription."; }
}
uses subscription-info;
}
notification removed-from-subscription { notification subscription-started {
netmod-notif:control-plane-notif; notif-bis:control-plane-notif;
description description
"This notification is sent to a receiver when it has been "This notification indicates that a subscription has
removed from an existing subscription. started and notifications are beginning to be sent.
Note that if the subscription is terminated, the receiver This notification shall only be sent to receivers
will receive a subscription-terminated notification of a subscription; it does not constitute a general-purpose
and no removed-from-subscription."; notification.";
leaf subscription-id { leaf subscription-id {
type subscription-id; type subscription-id;
mandatory true; mandatory true;
description description
"This references the affected subscription."; "This references the affected subscription.";
} }
} uses subscription-info;
}
/* notification subscription-suspended {
* DATA NODES notif-bis:control-plane-notif;
*/ description
"This notification indicates that a suspension of the
subscription by the publisher has occurred. No further
notifications will be sent until subscription
resumes.
This notification shall only be sent to receivers
of a subscription; it does not constitute a general-purpose
notification.";
leaf subscription-id {
type subscription-id;
mandatory true;
description
"This references the affected subscription.";
}
leaf reason {
type subscription-susp-reason;
description
"Provides a reason for why the subscription was
suspended.";
}
}
container streams { notification subscription-resumed {
config false; notif-bis:control-plane-notif;
description description
"This container contains a leaf list of built-in "This notification indicates that a subscription that had
streams that are provided by the system."; previously been suspended has resumed. Notifications
leaf-list stream { will once again be sent.";
type notif:stream; leaf subscription-id {
description type subscription-id;
"Identifies the built-in streams that are supported by the mandatory true;
system. Built-in streams are associated with their own description
identities, each of which carries a special semantics. "This references the affected subscription.";
In case configurable custom streams are supported, }
as indicated by the custom-stream identity, the configuration }
of those custom streams is provided separately.";
}
}
container filters {
description
"This container contains a list of configurable filters
that can be applied to subscriptions. This facilitates
the reuse of complex filters once defined.";
list filter {
key "filter-id";
description
"A list of configurable filters that can be applied to
subscriptions.";
leaf filter-id {
type filter-id;
description
"An identifier to differentiate between filters.";
}
uses notif:base-filter;
}
}
container subscription-config {
if-feature "configured-subscriptions";
description
"Contains the list of subscriptions that are configured,
as opposed to established via RPC or other means.";
list subscription {
key "subscription-id";
description
"Content of a subscription.";
leaf subscription-id {
type subscription-id;
description
"Identifier to use for this subscription.";
}
uses subscription-info;
uses receiver-info {
if-feature "configured-subscriptions";
}
uses push-source-info {
if-feature "configured-subscriptions";
}
}
}
container subscriptions {
config false;
description
"Contains the list of currently active subscriptions,
i.e. subscriptions that are currently in effect,
used for subscription management and monitoring purposes.
This includes subscriptions that have been setup via RPC
primitives, e.g. create-subscription, delete-subscription,
and modify-subscription, as well as subscriptions that
have been established via configuration.";
list subscription {
key "subscription-id";
config false;
description
"Content of a subscription.
Subscriptions can be created using a control channel
or RPC, or be established through configuration.";
leaf subscription-id {
type subscription-id;
description
"Identifier of this subscription.";
}
leaf configured-subscription { notification subscription-modified {
if-feature "configured-subscriptions"; notif-bis:control-plane-notif;
type empty; description
"This notification indicates that a subscription has
been modified. Notifications sent from this point
on will conform to the modified terms of the
subscription.";
leaf subscription-id {
type subscription-id;
mandatory true;
description description
"The presence of this leaf indicates that the "This references the affected subscription.";
subscription originated from configuration, not }
through a control channel or RPC."; uses subscription-info;
} }
leaf subscription-status { notification subscription-terminated {
type subscription-status; notif-bis:control-plane-notif;
description description
"The status of the subscription."; "This notification indicates that a subscription has been
terminated.";
leaf subscription-id {
type subscription-id;
mandatory true;
description
"This references the affected subscription.";
}
leaf reason {
type subscription-term-reason;
description
"Provides a reason for why the subscription was
terminated.";
}
}
} /*
uses subscription-info; * DATA NODES
uses receiver-info { */
if-feature "configured-subscriptions";
} container streams {
uses push-source-info { config false;
description
"This container contains a leaf list of built-in
streams that are provided by the system.";
leaf-list stream {
type stream;
description
"Identifies the built-in streams that are supported by the
system. Built-in streams are associated with their own
identities, each of which carries a special semantics.
In case configurable custom streams are supported,
as indicated by the custom-stream identity, the
configuration of those custom streams is provided
separately.";
}
}
container filters {
description
"This container contains a list of configurable filters
that can be applied to subscriptions. This facilitates
the reuse of complex filters once defined.";
list filter {
key "filter-id";
description
"A list of configurable filters that can be applied to
subscriptions.";
leaf filter-id {
type filter-id;
description
"An identifier to differentiate between filters.";
}
uses base-filter;
}
}
container subscription-config {
if-feature "configured-subscriptions";
description
"Contains the list of subscriptions that are configured,
as opposed to established via RPC or other means.";
list subscription {
key "subscription-id";
description
"Content of a subscription.";
leaf subscription-id {
type subscription-id;
description
"Identifier to use for this subscription.";
}
uses subscription-info;
uses receiver-info {
if-feature "configured-subscriptions";
}
uses push-source-info {
if-feature "configured-subscriptions";
}
}
}
container subscriptions {
config false;
description
"Contains the list of currently active subscriptions,
i.e. subscriptions that are currently in effect,
used for subscription management and monitoring purposes.
This includes subscriptions that have been setup via RPC
primitives, e.g. create-subscription, establish-
subscription, and modify-subscription, as well as
subscriptions that have been established via
configuration.";
list subscription {
key "subscription-id";
config false;
description
"Content of a subscription.
Subscriptions can be created using a control channel
or RPC, or be established through configuration.";
leaf subscription-id {
type subscription-id;
description
"Identifier of this subscription.";
}
leaf configured-subscription {
if-feature "configured-subscriptions"; if-feature "configured-subscriptions";
} type empty;
} description
} "The presence of this leaf indicates that the
} subscription originated from configuration, not
through a control channel or RPC.";
}
<CODE ENDS> leaf subscription-status {
type subscription-status;
description
"The status of the subscription.";
}
uses subscription-info;
uses receiver-info {
if-feature "configured-subscriptions";
}
uses push-source-info {
if-feature "configured-subscriptions";
}
}
}
}
<CODE ENDS>
9. Backwards Compatibility 9. Backwards Compatibility
Capabilities are advertised in messages sent by each peer during Capabilities are advertised in messages sent by each peer during
session establishment [RFC6241]. Servers supporting the features in session establishment [RFC6241]. Publishers supporting the features
this document must advertise both capabilities in this document must advertise both capabilities
"urn:ietf:params:netconf:capability:notification:1.0" and "urn:ietf:params:netconf:capability:notification:1.0" and
"urn:ietf:params:netconf:capability:notification:1.1". "urn:ietf:params:netconf:capability:notification:1.1".
An example of a hello message by a server during session An example of a hello message by a publisher during session
establishment would be: establishment would be:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities> <capabilities>
<capability> <capability>
urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:base:1.0
</capability> </capability>
<capability> <capability>
urn:ietf:params:netconf:capability:startup:1.0 urn:ietf:params:netconf:capability:startup:1.0
</capability> </capability>
skipping to change at page 39, line 50 skipping to change at page 40, line 43
</capability> </capability>
<capability> <capability>
urn:ietf:params:netconf:capability:notification:1.1 urn:ietf:params:netconf:capability:notification:1.1
</capability> </capability>
</capabilities> </capabilities>
<session-id>4</session-id> <session-id>4</session-id>
</hello> </hello>
Figure 9: Hello message Figure 9: Hello message
Clients that only support [RFC5277] recognize capability Subscribers that only support [RFC5277] recognize capability
"urn:ietf:params:netconf:capability:notification:1.0" and ignore "urn:ietf:params:netconf:capability:notification:1.0" and ignore
capability "urn:ietf:params:netconf:capability:notification:1.1". capability "urn:ietf:params:netconf:capability:notification:1.1".
This allows them interacting with the publisher as per [RFC5277].
This allows them interacting with the server as per [RFC5277]. Subscribers that support the features in this document recognize both
Clients that support the features in this document recognize both capabilities. This allows them interacting with the publisher as per
capabilities. This allows them interacting with the server as per
this document. this document.
Note that to support backwards compatibility, the yang models in this Note that to support backwards compatibility, the yang models in this
document include two types of naming conventions. That used in document include two types of naming conventions. That used in
[RFC5277], e.g., replayComplete; and that commonly used in yang [RFC5277], e.g., replayComplete; and that commonly used in yang
models, e.g., subscription-started. models, e.g., subscription-started.
10. Security Considerations 10. Security Considerations
The security considerations from the base NETCONF document [RFC6241] The <notification> elements are never sent before the transport
also apply to the notification capability. layer, including capabilities exchange, has been established and the
manager has been securely established.
The <notification> elements are never sent before the transport layer
and the NETCONF layer, including capabilities exchange, have been
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 is highly recommended and the publisher must
user has sufficient authorization to perform the function they are ensure that the user has sufficient authorization to perform the
requesting against the specific subset of NETCONF content involved. function they are requesting against the specific subset of content
When a <get> is received that refers to the content defined in this involved. When a <get> is received that refers to the content
memo, clients should only be able to view the content for which they defined in this memo, clients should only be able to view the content
have sufficient privileges. <create-subscriptiont> and <establish- for which they have sufficient privileges. <create-subscription> and
subscriptiont> operations can be considered like deferred <get>, and <establish-subscription> operations can be considered like deferred
the content that different users can access may vary. This different <get>, and the content that different users can access may vary.
access is reflected in the <notificationt> that different users are This different access is reflected in the <notificationt> to which
able to subscribe to. different users are able to subscribe.
The contents of notifications, as well as the names 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 they are viewed only by authorized users. The NETCONF server that they are viewed only by authorized users. The publisher MUST
MUST NOT include any content in a notification that the user is not NOT include any content in a notification that the user is not
authorized to view. authorized to view.
If a malicious or buggy NETCONF client sends a number of <create- If a malicious or buggy subscriber sends a number of <create-
subscription> requests, then these subscriptions accumulate and may subscription> requests, then these subscriptions accumulate and may
use up system resources. In such a situation, subscriptions can be use up system resources. In such a situation, subscriptions can be
terminated by terminating the suspect underlying NETCONF sessions terminated by terminating the suspect underlying NETCONF sessions
using the <kill-session> operation. If the client uses <establish- using the <kill-session> operation. If the subscriber uses
subscription>, the server can also suspend or terminate subscriptions <establish-subscription>, the publisher can also suspend or terminate
with per-subscription granularity. subscriptions with per-subscription granularity.
A subscription could be configured on another receiver's behalf, with A subscription could be configured on another receiver's behalf, with
the goal of flooding that receiver with updates. One or more the goal of flooding that receiver with updates. One or more
publishers could be used to overwhelm a receiver, which doesn't even publishers could be used to overwhelm a receiver, which doesn't even
support subscriptions. Clients that do not want pushed data need support subscriptions. Subscribers that do not want pushed data need
only terminate or refuse any transport sessions from the publisher. only terminate or refuse any transport sessions from the publisher.
In addition, the NETCONF Authorization Control Model [RFC6536] SHOULD In addition, the NETCONF Authorization Control Model [RFC6536] SHOULD
be used to control and restrict authorization of subscription be used to control and restrict authorization of subscription
configuration. This control models permits specifying per-user configuration. This control models permits specifying per-user
permissions to receive specific event notification types. The permissions to receive specific event notification types. The
permissions are specified as a set of access control rules. permissions are specified as a set of access control rules.
Note that streams can define additional authorization requirements. Note that streams can define additional authorization requirements.
For instance, in [I-D.ietf-netconf-yang-push], each of the elements For instance, in [I-D.ietf-netconf-yang-push], each of the elements
in its data plane notifications must also go through access control. in its data plane notifications must also go through access control.
11. Issues that are currently being worked and resolved 11. Acknowledgments
11.1. Unresolved and yet-to-be addressed issues
EN1 - Definition of basic set of Stream types. What streams are
provided and what do they contain (includes default 5277 stream).
EN2 - Clarify interplay between filter definitions and different
streams. Includes information in subtrees of event payloads.
EN3 - Mechanisms for diagnostics, e.g. deal with dropped updates,
monitoring when they occur, etc
EN4 - How to allow for seamless integration with non-standard
encodings and transports (like GPB/GRPC). Specify requirements
encoding and transport must meet, provide examples.
EN7 - Detecting loss of a sequential update notification, and
mechanisms to resend. Implications to transports must be thought
through.
11.2. Agreement in principal
EN6 - Stream discovery. Allow to discover additional stream
properties.
EN9 - Multiple receivers per Configured Subscription is ok.
EN10 - Replay support will be provided for selected stream types
(modify vs. delete)
EN11 - Required layering security requirements/considerations will be
added into the YANG model for Configured Subscriptions. It will be
up to the transport to meet these requirements.
EN12 - Test-only option for a subscription is desired. But it still
needs to be defined.
EN13 - RFC6241 Subtree-filter definition in 5277bis cannot apply to
elements of an event. Must explicitly define how 6241 doesn't apply
filtering within a 5277bis event.
EN14 - Ensure that Configured Subscriptions are fully defined in YANG
model.
11.3. Resolved Issues
EN5 - This draft obsoletes 5277, as opposed to being in parallel with
it
EN8 - No mandatory transport
EN15 - Term for Dynamic and Static Subscriptions (move to
"Configured")
12. Acknowledgments
For their valuable comments, discussions, and feedback, we wish to For their valuable comments, discussions, and feedback, we wish to
acknowledge Andy Bierman, Yang Geng, Peipei Guo, Susan Hares, Tim acknowledge Andy Bierman, Yang Geng, Peipei Guo, Susan Hares, Tim
Jenkins, Balazs Lengyel, Kent Watsen, and Guangying Zheng. Jenkins, Balazs Lengyel, Kent Watsen, Michael Scharf, and Guangying
Zheng.
13. References 12. References
13.1. Normative References 12.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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[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>. <http://www.rfc-editor.org/info/rfc5277>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc6536>.
13.2. Informative References [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016.
12.2. Informative References
[I-D.ietf-netconf-netconf-event-notif] [I-D.ietf-netconf-netconf-event-notif]
Gonzalez Prieto, Alberto., Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., Clemm, Alexander., Voit, Eric.,
Nilsen-Nygaard, E., Tripathy, A., Chisholm, S., and H. Nilsen-Nygaard, E., Tripathy, A., Chisholm, S., and H.
Trevino, "NETCONF support for event notifications", August Trevino, "NETCONF support for event notifications", August
2016, <https://datatracker.ietf.org/doc/draft-ietf- 2016, <https://datatracker.ietf.org/doc/draft-ietf-
netconf-netconf-event-notifications/>. netconf-netconf-event-notifications/>.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", I-D draft-ietf-netconf-restconf-13, April 2016. Protocol", I-D draft-ietf-netconf-restconf-17, September
2016.
[I-D.ietf-netconf-restconf-notif] [I-D.ietf-netconf-restconf-notif]
Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen- Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
HTTP transport for event notifications", August 2016, HTTP transport for event notifications", August 2016,
<https://datatracker.ietf.org/doc/draft-ietf-netconf- <https://datatracker.ietf.org/doc/draft-ietf-netconf-
restconf-notif/>. restconf-notif/>.
[I-D.ietf-netconf-yang-push] [I-D.ietf-netconf-yang-push]
Clemm, Alexander., Gonzalez Prieto, Alberto., Voit, Eric., Clemm, Alexander., Gonzalez Prieto, Alberto., Voit, Eric.,
Tripathy, A., and E. Nilsen-Nygaard, "Subscribing to YANG Tripathy, A., and E. Nilsen-Nygaard, "Subscribing to YANG
datastore push updates", June 2016, datastore push updates", June 2016,
<https://datatracker.ietf.org/doc/draft-ietf-netconf-yang- <https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-
push/>. push/>.
Appendix A. Issues that are currently being worked and resolved
(To be removed by RFC editor prior to publication)
A.1. Unresolved and yet-to-be addressed issues
EN1 - Definition of basic set of Stream types. What streams are
provided and what do they contain (includes default 5277 stream).
EN2 - Clarify interplay between filter definitions and different
streams. Includes information in subtrees of event payloads.
EN3 - Mechanisms for diagnostics, e.g. deal with dropped updates,
monitoring when they occur, etc
A.2. Agreement in principal
EN4 - How to allow for seamless integration with non-standard
encodings and transports (like GPB/GRPC). Specify requirements
encoding and transport must meet, provide examples.
EN7 - Detecting loss of a sequential update notification, and
mechanisms to resend. Implications to transports must be thought
through.
EN6 - Stream discovery. Allow to discover additional stream
properties.
EN12 - Test-only option for a subscription is desired. But it still
needs to be defined.
EN14 - Ensure that Configured Subscriptions are fully defined in YANG
model.
A.3. Resolved Issues
EN5 - This draft obsoletes 5277, as opposed to being in parallel with
it
EN8 - No mandatory transport
EN15 - Term for Dynamic and Static Subscriptions (move to
"Configured")
EN9 - Multiple receivers per Configured Subscription is ok.
EN13 - RFC6241 Subtree-filter definition in 5277bis cannot apply to
elements of an event. Must explicitly define how 6241 doesn't apply
filtering within a 5277bis event.
EN10 - Replay support will be provided for selected stream types
(modify vs. delete)
EN11 - Required layering security requirements/considerations will be
added into the YANG model for Configured Subscriptions. It will be
up to the transport to meet these requirements.
Appendix B. Changes between revisions
(To be removed by RFC editor prior to publication)
v00 - v01
o YANG Model changes. New groupings for subscription info to allow
restriction of what is changable via RPC. Removed notifications
for adding and removing receivers of configured subscriptions.
o Expanded/renamed defintions from event server to publisher, and
client to subscriber as applicable. Updated the definitions to
include and expand on RFC 5277.
o Removal of redundant with other drafts
o Many other clean-ups of wording and terminology
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Cisco Systems Sympotech
Email: alex@sympotech.com
Email: ludwig@clemm.org
Alberto Gonzalez Prieto Alberto Gonzalez Prieto
Cisco Systems Cisco Systems
Email: albertgo@cisco.com Email: albertgo@cisco.com
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
 End of changes. 178 change blocks. 
1275 lines changed or deleted 1359 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/