NETCONF                                               A. Gonzalez Prieto
Internet-Draft                                                    VMware
Intended status: Standards Track                                A. Clemm                                 E. Voit
Expires: April 5, May 3, 2018                                       Cisco Systems
                                                                A. Clemm
                                                                  Huawei
                                                       E. Voit
                                                       E. Nilsen-Nygaard
                                                             A. Tripathy
                                                           Cisco Systems
                                                        October 2, 30, 2017

                NETCONF Support for Event Notifications
           draft-ietf-netconf-netconf-event-notifications-05
           draft-ietf-netconf-netconf-event-notifications-06

Abstract

   This document defines how to transport network subscriptions and
   event messages on top of the Network Configuration protocol
   (NETCONF).  This includes the full set of RPCs, provides a NETCONF binding for
   [I-D.draft-ietf-netconf-subscribed-notifications].  Included are:

   o  Transport mappings for subscription RPCs, state
   changes, change
      notifications, and subscribed content needing asynchronous delivery. notification messages

   o  Functionality which must be supported with NETCONF

   o  Examples in appendices

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 5, May 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   3.  Solution  . . . . . .  Interleave Capability . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Event Stream Discovery  . . .
   4.  Mandatory stream and datastore support  . . . . . . . . . . .   3
   5.  Transport connectivity  . . .   3
     3.2.  Mandatory NETCONF support . . . . . . . . . . . . . . . .   4
     3.3.
     5.1.  Dynamic Subscriptions . . . . . . . . . . . . . . . . . .   4
     3.4.
     5.2.  Configured Subscriptions  . . . . . . . . . . . . . . . .  11
   4.  Interleave Capability   4
   6.  Notification Messages . . . . . . . . . . . . . . . . . . . .  23
   5.   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   6.   4
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   7.   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     7.1.   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     7.2.   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  25   6
   Appendix A.  Open Items  Examples . . . . . . . . . . . . . . . . . . . . . .   6
     A.1.  Event Stream Discovery  . . . . . . . . . . . . . . . . .   6
     A.2.  Dynamic Subscriptions . . . . . . . . . . . . . . . . . .   7
     A.3.  Configured Subscriptions  . . . . . . . . . . . . . . . .  12
     A.4.  Subscription State Notifications  . . . . . . . . . . .  26 .  17
   Appendix B.  Changes between revisions  . . . . . . . . . . . . .  26  19
     B.1.  v04 to  v05 to v06  . . . . . . . . . . . . . . . . . . . . . . .  26  19
     B.2.  v03 to v04  . . . . . . . . . . . . . . . . . . . . . . .  26  19
     B.3.  v01 to v03  . . . . . . . . . . . . . . . . . . . . . . .  26  20
     B.4.  v00 to v01  . . . . . . . . . . . . . . . . . . . . . . .  26  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27  20

1.  Introduction

   This document defines mechanisms that provide a subscription and
   asynchronous message binding for notification message delivery service for
   [I-D.draft-ietf-netconf-subscribed-notifications] transported over
   the NETCONF protocol [RFC6241] based on [subscribe].  This [RFC6241].  In addition, as
   [I-D.ietf-netconf-yang-push] is an optional
   capability itself built on top upon

   [I-D.draft-ietf-netconf-subscribed-notifications], this document
   enables a NETCONF client to maintain a subset/extract of the base an actively
   changing YANG datastore located on a NETCONF server.

   This document is broken into two main parts.  The first contains
   normative requirements which are incremental to
   [I-D.draft-ietf-netconf-subscribed-notifications] when NETCONF definition.
   transport is used.  The second are examples and are included as
   appendices.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The following terms are defined in [RFC6241]: client, server,
   operation, RPC.

   The following terms are defined in [subscribe]: event, event
   notification,
   [I-D.draft-ietf-netconf-subscribed-notifications]: notification
   message, stream, publisher, receiver, subscriber, subscription,
   configured subscription.

   Note that

3.  Interleave Capability

   To support multiple subscriptions on a publisher in [subscribe] corresponds to single session, a server NETCONF
   publisher MUST support the :interleave capability as defined in
   [RFC6241].  Similarly, a subscriber corresponds to a client.  A
   receiver is also a client.  In
   [RFC5277].  Such support MUST be indicated by the remainder following
   capability: "urn:ietf:params:netconf:capability:interleave:1.0".
   Advertisement of this document, we capability along with support
   [I-D.draft-ietf-netconf-subscribed-notifications] will use the terminology in [RFC6241].

3.  Solution

   In this section, we describe and exemplify how [subscribe] is to be
   supported over NETCONF.

3.1.  Event Stream Discovery

   In the context of [subscribe] an event stream exposes indicate that
   a continuous
   set of events available for subscription.  A NETCONF client can
   retrieve the list of available event streams from a publisher is able to receive, process, and respond to
   NETCONF server
   using the "get" operation against the top-level container "/streams"
   defined in [subscribe].  The reply includes the list of streams
   supported requests and
   [I-D.draft-ietf-netconf-subscribed-notifications] subscription
   operations on the NETCONF server.

   The following example illustrates the retrieval of the list of
   available event streams using the <get> operation.

      <rpc message-id="101"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
          <filter type="subtree">
            <streams
            xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"/>
            </filter>
        </get>
      </rpc>

                       Figure 1: Get streams request

   The NETCONF server returns a list of event streams available.  In
   this example, the list contains the NETCONF, SNMP, session with active subscriptions.

4.  Mandatory stream and SYSLOG
   streams.

   <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <data>
       <streams
          xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
         <stream>
           <stream>NETCONF</stream>
           <description>The NETCONF mandatory event stream</description>
         </stream>
         <stream>
           <stream>SNMP</stream>
           <description>The SNMP event stream</description>
         </stream>
         <stream>
           <stream>SYSLOG</stream>
           <description>The SYSLOG event stream</description>
           <replay-support/>
           <replay-log-creation-time>
             2015-03-09T19:14:55.233Z</replay-log-creation-time>
         </stream>
       </streams>
     </data>
   </rpc-reply>

                      Figure 2: Get streams response

   For [yang-push], a similar get is needed to retrieve available datastore names.

3.2.  Mandatory NETCONF support

   A NETCONF server implementation publisher supporting [subscribe] must
   [I-D.draft-ietf-netconf-subscribed-notifications] MUST support
   dynamic subscriptions and the
   "NETCONF" notification event stream.
   The NETCONF event stream contains all NETCONF XML event information
   supported by the server. identified in that draft.

   A NETCONF server implementation publisher supporting [yang-push] must [I-D.ietf-netconf-yang-push] MUST
   support the "running" datastore.

3.3.  Dynamic Subscriptions

3.3.1.  Establishing datastore as defined by
   [I.D.draft-ietf-netmod-revised-datastores].

5.  Transport connectivity

5.1.  Dynamic Subscriptions

   The

   For dynamic subscriptions, if the NETCONF session involved with the
   "establish-subscription" terminates, the subscription RFC and interactions operation MUST be
   deleted.

5.2.  Configured Subscriptions

   For a configured subscription, there is defined in
   [subscribe].

3.3.1.1.  Usage Example

   An example of interactions over NETCONF no guarantee a transport for one sample
   subscription
   session is below:

     <netconf:rpc netconf:message-id="102"
            xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
       <establish-subscription
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          <stream>NETCONF</stream>
          <event-filter-type>xpath-event-filter</event-filter-type>
          <event-filter-contents xmlns:ex="http://example.com/event/1.0"
                  select="/ex:event[ex:eventClass='fault' and
                           (ex:severity='minor' or ex:severity='major'
                            or ex:severity='critical')]" />
       </establish-subscription>
     </netconf:rpc>

               Figure 3: establish-subscription over NETCONF

3.3.1.2.  Positive Response

   If currently in place with associated receiver(s).  So where
   a configured subscription has a receiver in the connecting state, but
   no NETCONF server can satisfy the request, transport exists to that receiver, the server sends publisher MUST be
   able to initiate a
   positive <subscription-result> element, NETCONF transport session via NETCONF call home
   [RFC8071], section 4.1 to that receiver.  Until NETCONF connectivity
   is established and the subscription-id a subscription-started state change notification
   is successfully sent, that receiver MUST remain in its status of
   the accepted subscription.

      <rpc-reply message-id="102"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          ok
        </subscription-result>
        <identifier
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          52
        </identifier>
      </rpc-reply>

                Figure 4: Successful establish-subscription

3.3.1.3.  Negative Response a
   "connecting".

   If the NETCONF server cannot satisfy call home fails because the request, or publisher receives receiver
   credentials which are subsequently declined as part [RFC8071],
   Section 4.1, step S5 authentication, then that receiver MUST be
   assigned a "suspended" status.

   If the client has
   no authorization call home fails to establish for any other reason, the subscription,
   publisher MAY leave the server will send receiver in a negative <subscription-result> element.  For instance:

      <rpc-reply message-id="103"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          stream-unavailable
        </subscription-result>
      </rpc-reply>

               Figure 5: Unsuccessful establish subscription

3.3.1.4.  Subscription Negotiation

   If the client request includes parameters the NETCONF server cannot
   serve, "connecting" status, and retry
   the negative <subscription-result> may include hints call home at
   subscription parameters which would have been accepted.  For
   instance, consider the following subscription from [yang-push], which
   augments a future time.  Alternatively, the establish-subscription with some additional parameters,
   including "period".  If publisher MAY
   place the client requests receiver into a period which "suspended" status after a predetermined
   number of call home attempts.

   NETCONF Transport session connectivity SHOULD be verified via
   Section 4.1, step S7.

   Failure of an active NETCONF session MUST reset the restart the call
   home process, and return the receiver to "connecting".

6.  Notification Messages

   Notification messages transported over NETCONF server cannot serve, will be identical in
   format and content to those encoded using one-way operations defined
   within [RFC5277], section 4.

7.  Security Considerations

   Notification messages (including state change notifications) are
   never sent before the back-and-forth NETCONF capabilities exchange has completed.

   If a malicious or buggy NETCONF subscriber sends a number of
   "establish-subscription" requests, then these subscriptions
   accumulate and may be:

      <netconf:rpc message-id="101"
         xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
         <establish-subscription
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
            <datastore>running</datastore>
            <event-filter-type>
              subtree</event-filter-type>
            <event-filter-contents
                  xmlns:ex="http://example.com/sample-data/1.0">
                  select="/ex:foo" />
            <dampening-period>10</dampening-period>
            <encoding>encode-xml</encoding>
         </establish-subscription>
      </netconf:rpc>

      <rpc-reply message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
              xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          error-insufficient-resources
        </subscription-result>
        <period-hint
              xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          2000
        </period-hint>
      </rpc-reply>

             Figure 6: Subscription establishment negotiation

3.3.1.5.  Message Flow Examples

   +------------+                 +-----------+
   |   Client   |                 |   Server  |
   +------------+                 +-----------+
         |                              |
         |    Capability Exchange       |
         |<---------------------------->|
         |                              |
         |                              |
         |    Establish Subscription    |
         |----------------------------->|
         | RPC Reply: OK, id = 22       |
         |<-----------------------------|
         |                              |
         |  Notification (id 22)        |
         |<-----------------------------|
         |                              |
         |                              |
         |    Establish Subscription    |
         |----------------------------->|
         | RPC Reply: OK, id = 23       |
         |<-----------------------------|
         |                              |
         |                              |
         |  Notification (id 22)        |
         |<-----------------------------|
         |  Notification (id 23)        |
         |<-----------------------------|
         |                              |
         |                              |

   Figure 7: Multiple subscription establishments over use up system resources.  In such a single situation,
   subscriptions MAY be terminated by terminating the suspect underlying
   NETCONF
                                  session

3.3.2.  Modifying a Subscription

   This operation is defined in [subscribe].

3.3.2.1.  Usage Example sessions.  The following demonstrates modifying a subscription.  Consider publisher MAY also suspend or terminate a
   subscription from [yang-push], which augments
   subset of the establish-
   subscription with some additional parameters, including "period".  A
   subscription may be established and modified as follows.

    <netconf:rpc message-id="101"
           xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
      <establish-subscription
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
         <datastore xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
            running</datastore>
         <event-filter-type>subtree-event-filter</event-filter-type>
         <event-filter-contents
           xmlns:ex="http://example.com/sample-data/1.0">
           select="/ex:foo" />
         <period xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
             1000
         </period>
      </establish-subscription>
    </netconf:rpc>

    <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <subscription-result
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
        ok
      </subscription-result>
      <identifier
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
        1922
      </identifier>
    </rpc-reply>

    <netconf:rpc message-id="102"
           xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
      <modify-subscription
               xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
        <identifier>1922</identifier>
        <period>100</period>
      </modify-subscription>
    </netconf:rpc>

                    Figure 8: Subscription modification

3.3.2.2.  Positive Response

   If active subscriptions on the NETCONF server can satisfy the request, the server sends a
   positive <subscription-result> element.  This response is like that session.

   The NETCONF Authorization Control Model [RFC6536] SHOULD be used to an establish-subscription request, but without the subscription
   identifier.

      <rpc-reply message-id="102"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          ok
        </subscription-result>
      </rpc-reply>

                 Figure 9: Successful modify
   control and restrict authorization of subscription

3.3.2.3.  Negative Response

   If the NETCONF server cannot satisfy the request, configuration.

8.  Acknowledgments

   We wish to acknowledge the server sends a
   negative <subscription-result> element.  Its contents helpful contributions, comments, and semantics
   are identical to those in an establish-subscription request.  For
   instance:

      <rpc-reply message-id="102"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          period-unsupported
        </subscription-result>
        <period-hint>500</period-hint>
      </rpc-reply>

                Figure 10: Unsuccessful modify subscription

3.3.2.4.  Message Flow Example
   +------------+                 +-----------+
   |   Client   |                 |   Server  |
   +------------+                 +-----------+
         |                              |
         |    Capability Exchange       |
         |<---------------------------->|
         |                              |
         |    Establish Subscription    |
         |----------------------------->|
         | RPC Reply: OK, id = 22       |
         |<-----------------------------|
         |                              |
         |  Notification (id 22)        |
         |<-----------------------------|
         |                              |
         | Modify Subscription (id 22)  |
         |----------------------------->|
         | RPC Reply: OK                |
         |<-----------------------------|
         |                              |
         |  Notification (id 22)        |
         |<-----------------------------|
         |                              |

     Figure 11: Message flow for successful subscription modification

3.3.3.  Deleting a
   suggestions that were received from: Andy Bierman, Yan Gang, Sharon
   Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins,
   Balazs Lengyel, Kent Watsen, and Guangying Zheng.

9.  References

9.1.  Normative References

   [I-D.draft-ietf-netconf-subscribed-notifications]
              Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
              and E. Nilsen-Nygaard, "Custom Subscription

   This operation is defined to Event
              Streams", draft-ietf-netconf-subscribed-notifications-06
              (work in [subscribe] for events, progress), October 2017.

   [I-D.ietf-netconf-yang-push]
              Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
              Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and enhanced in
   [yang-push] for datastores.

3.3.3.1.  Usage Example

   The following demonstrates deleting a subscription.

      <netconf:rpc message-id="101"
             xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
        <delete-subscription
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          <identifier>1922</identifier>
        </delete-subscription>
      </netconf:rpc>

                      Figure 12: Delete subscription

3.3.3.2.  Positive Response

   If the NETCONF server can satisfy the request, the server sends a
   positive <subscription-result> element.  For example:

      <rpc-reply message-id="103"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          ok
        </subscription-result>
      </rpc-reply>

                 Figure 13: Successful delete subscription

3.3.3.3.  Negative Response

   If the NETCONF server cannot satisfy the request, the server sends an
   <subscription-result> element indicating the deletion was not
   performed.  For example:

      <rpc-reply message-id="101"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <subscription-result
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
          no-such-subscription
        </subscription-result>
      </rpc-reply>

                Figure 14: Unsuccessful delete subscription

3.4.  Configured Subscriptions

   Configured subscriptions are established, modified, B.
              Lengyel, "YANG Datastore Subscription", October 2017,
              <https://datatracker.ietf.org/doc/
              draft-ietf-netconf-yang-push/>.

   [I.D.draft-ietf-netmod-revised-datastores]
              Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and deleted using
   configuration operations against the top-level subtree of [subscribe]
   or [yang-push] via configuration interface.  This document covers
   configured subscriptions where the chosen protocol to send the
   notifications R. Wilton, "Network Management Datastore
              Architecture", draft-ietf-netmod-revised-datastores-04
              (work in progress), August 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to the receivers is NETCONF.

   Configured subscriptions are supported by NETCONF servers using
   NETCONF Call Home [RFC8071].

   Any configuration interface can be used to set a configured
   subscription that uses NETCONF to push notifications to receivers.
   Without loss of generality, the examples in this section, use a
   NETCONF interface to configure the subscriptions

3.4.1.  Establishing a Configured Subscription

   For subscription establishment, a NETCONF client may send:

     <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <subscription-config
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
           <subscription>
             <identifier>
               1922
             </identifier>
             <stream>
               foo
             </stream>
             <receiver>
               <address>
                 1.2.3.4
               </address>
               <port>
                 1234
               </port>
               <protocol>
                 netconf
               </protocol>
             </receiver>
           </subscription>
         </subscription-config>
       </edit-config>
     </rpc>

               Figure 15: Establish configured subscription

   if the request is accepted, the server would reply:

      <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <ok/>
      </rpc-reply>

      Figure 16: Response to a successful configuration subscription
                               establishment

   if the request is not accepted because the server cannot serve it, no
   configuration is changed.  Int this case the server may reply:

   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <subscription-result
                xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
       error-insufficient-resources
     </subscription-result>
   </rpc-reply>

   Figure 17: Response to a failed configured subscription establishment

   For every configured receiver, once NETCONF transport session between
   the server Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5277]  Chisholm, S. and the receiver is recognized as active, the server will
   issue a "subscription-started" notification.  After that, the server
   will send notifications to the receiver as per the subscription
   notification.  Note that the server assumes that the receiver is
   ready to accept notifications on the NETCONF session.  This may
   require coordination between the client that configures the
   subscription H. Trevino, "NETCONF Event
              Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
              <https://www.rfc-editor.org/info/rfc5277>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and the clients for which the notifications are
   intended.  This coordination is out of the scope of this document.

   The session is only intended for pushing notifications.  Client
   requests on that session SHOULD be ignored by the server.

   The contents sent by the server on the Call Home session, once
   established, are identical to those in a dynamic subscription.

3.4.2.  Call Home for Configured Subscriptions

   Once the subscription configuration is active, if NETCONF transport
   is needed but does not exist to one or more target IP address plus
   port, the server initiates a transport session via [RFC8071] to those
   receiver(s) in the subscription using the address and port specified.

3.4.3.  Full Establish Message Flow
 +----------+                 +-----------+     +---------+  +---------+
 |  Client  |                 |   Server  |     | Rcver A |  | Rcver B |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
       |    Capability Exchange     |                |            |
       |<-------------------------->|                |            |
       |                            |                |            |
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |   Call Home    |            |
       |                            |<-------------->|            |
       |                            |<--------------------------->|
       |                            |                |            |
       |                            |  Subscription  |            |
       |                            |  Started       |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |                            |  Notification  |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

     Figure 18: Message flow for configured subscription establishment

3.4.4.  Modifying a Configured Subscription

   Configured subscriptions can be modified using configuration
   operations against the top-level subtree subscription-config.

   For example, the subscription established in the previous section
   could be modified as follows, choosing a different receiver:

     <rpc message-id="102"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <subscription-config
                 xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
           <subscription>
             <identifier>
               1922
             </identifier>
             <stream>
               foo
             </stream>
             <receiver>
               <address>
                 1.2.3.5
               </address>
               <port>
                 1234
               </port>
             </receiver>
           </subscription>
         </subscription-config>
       </edit-config>
     </rpc>

                 Figure 19: Modify configured subscription

   if the request is accepted, the server would reply:

      <rpc-reply message-id="102"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <ok/>
      </rpc-reply>

       Figure 20: A successful configured subscription modification

3.4.4.1.  Message Flow Example
 +----------+                 +-----------+     +---------+  +---------+
 |  Client  |                 |   Server  |     | Rcver A |  | Rcver B |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
       |    Capability Exchange     |                |            |
       |<-------------------------->|                |            |
       |                            |                |            |
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |   Call Home    |            |
       |                            |<-------------->|            |
       |                            |<--------------------------->|
       |                            |                |            |
       |                            |  Subscription  |            |
       |                            |  Started       |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |                            |  Notification  |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |  Subscription  |            |
       |                            |  Modified      |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |                            |  Notification  |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

     Figure 21: Message flow for subscription modification (configured
                               subscription)

3.4.5.  Deleting a Configured Subscription

   Subscriptions can be deleted using configuration operations against
   the top-level subtree subscription-config.  For example:

      <rpc message-id="103"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <edit-config>
          <target>
            <running/>
          </target>
          <subscription-config
              xmlns:xc="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
            <subscription xc:operation="delete">
              <identifier>
                1922
              </identifier>
            </subscription>
          </subscription-config>
        </edit-config>
      </rpc>

      <rpc-reply message-id="103"
             xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <ok/>
      </rpc-reply>

               Figure 22: Deleting a configured subscription

3.4.5.1.  Message Flow Example
 +----------+                 +-----------+     +---------+  +---------+
 |  Client  |                 |   Server  |     | Rcver A |  | Rcver B |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
       |    Capability Exchange     |                |            |
       |<-------------------------->|                |            |
       |                            |                |            |
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |   Call Home    |            |
       |                            |<-------------->|            |
       |                            |<--------------------------->|
       |                            |                |            |
       |                            |  Subscription  |            |
       |                            |  Started       |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |                            |                |            |
       |                            |  Notification  |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |  Subscription  |            |
       |                            |  Terminated    |            |
       |                            |  (id 22)       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

       Figure 23: Message flow for subscription deletion (configured
                               subscription)

3.4.6. A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <https://www.rfc-editor.org/info/rfc6536>.

   [RFC8071]  Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              RFC 8071, DOI 10.17487/RFC8071, February 2017,
              <https://www.rfc-editor.org/info/rfc8071>.

9.2.  Informative References

   [I.D.draft-ietf-netconf-notification-messages]
              Voit, Eric., Clemm, Alexander., Bierman, A., and T.
              Jenkins, "YANG Notification Headers and Bundles",
              September 2017, <https://datatracker.ietf.org/doc/
              draft-ietf-netconf-notification-messages>.

Appendix A.  Examples

A.1.  Event (Data Plane) Notifications

   Once Stream Discovery

   As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an
   event stream exposes a dynamic or configured subscription has been created, the continuous set of events available for
   subscription.  A NETCONF server sends (asynchronously) client can retrieve the list of available
   event notifications streams from a NETCONF publisher using the
   subscribed stream to receiver(s) over NETCONF.  We refer to these as
   data plane notifications.  The data model for Event Notifications is "get" operation
   against the top-level container "/streams" defined in [subscribe].
   [I-D.draft-ietf-netconf-subscribed-notifications].  Any reply will
   include the stream identities supported on the NETCONF publisher
   which may be available to that client.

   The following is an example illustrates the retrieval of an the list of
   available event notification from [RFC6020]:

      notification link-failure {
        description "A link failure has been detected";
          leaf if-name {
            type leafref {
              path "/interface/name";
            }
          }
          leaf if-admin-status {
            type admin-status;
          }
          leaf if-oper-status {
            type oper-status;
          }
      } streams using the "get" operation.

<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <streams
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"/>
    </filter>
  </get>
</rpc>

                       Figure 24: Definition 1: Get streams request

   After such a request, the NETCONF publisher returns a list of an event notification

   This notification might result
   streams available.  In the example reply below, the list contains
   just the NETCONF stream.

<rpc-reply message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <streams
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <name>NETCONF</name>
    </streams>
  </data>
</rpc-reply>

                      Figure 2: Get streams response

A.2.  Dynamic Subscriptions

   The dynamic subscription RPCs and interactions operation are defined
   in [I-D.draft-ietf-netconf-subscribed-notifications] and enhanced in
   [I-D.ietf-netconf-yang-push].

A.2.1.  Establishing Dynamic Subscriptions

   An example of establish-subscription interactions over NETCONF
   transport for a sample subscription is described below:

  <rpc netconf:message-id="102"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <establish-subscription
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <stream>
        <name>NETCONF</name>
        <xpath-filter xmlns:ex="http://example.com/events">
             /ex:foo
        </xpath-filter>
      </stream>
    </establish-subscription>
  </rpc>

               Figure 3: establish-subscription over NETCONF

   If the NETCONF publisher can satisfy the following, prior to it being
   placed into NETCONF.  Note that request, the mandatory eventTime publisher sends
   a positive "subscription-result" element, and
   Subscription id have been added.

      <notification
             xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
        <eventTime>2007-09-01T10:00:00Z</eventTime>
        <link-failure xmlns="http://acme.example.com/system">
          <if-name>so-1/2/3.0</if-name>
          <if-admin-status>up</if-admin-status>
          <if-oper-status>down</if-oper-status>
        </link-failure>
      </notification> the subscription-id of
   the accepted subscription.

 <rpc-reply message-id="102"
   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <subscription-result
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      ok
   </subscription-result>
   <identifier
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
     22
   </identifier>
 </rpc-reply>

                Figure 25: Event notification

3.4.7.  Subscription State Notifications

   In addition 4: Successful establish-subscription

   If the NETCONF publisher cannot satisfy the request, or subscriber
   has no authorization to data plane notifications, a establish the subscription, the publisher may
   will send a negative "subscription-result" element.  For instance:

  <rpc-reply message-id="101"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <subscription-result
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      stream-unavailable
    </subscription-result>
  </rpc-reply>

               Figure 5: Unsuccessful establish subscription state notifications (defined in [subscribe]) to indicate
   to receivers that

   To get an event related to idea of the subscription management has
   occurred.  Subscription state notifications cannot be filtered out.
   Next we exemplify them:

3.4.7.1.  subscription-started and subscription-modified

   A subscription-started would look like:

     <notification
         xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <subscription-started
             xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"/>
         <identifier>39</identifier>
         <stream>NETCONF</stream>
       </subscription-started/>
     </notification>

      Figure 26: subscription-started subscription state notification

   The subscription-modified is identical, with just interaction model, the word "started" following figure shows
   two separate establish subscriptions RPC being replaced by "modified".

3.4.7.2.  subscription-completed, subscription-resumed, and replay-
          complete

   A subscription-completed would look like:

     <notification
         xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <subscription-completed
             xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
         <identifier>39</identifier>
       </subscription-completed>
     </notification>

           Figure 27: subscription-completed notification in XML

   The equivalent using JSON encoding would be:

      <notification
             xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
        <eventTime>2007-09-01T10:00:00Z</eventTime>
        <notification-contents-json>
             {
                "sn:subscription-completed": {
                "identifier" : 39
              }
        </notification-contents-json>
      </notification>

          Figure 28: subscription-completed notification in JSON made.  The subscription-resumed and replay-complete are virtually identical,
   with "subscription-completed" simply being replaced by "subscription-
   resumed" and "replay-complete" in both encodings.

3.4.7.3.  subscription-terminated and subscription-suspended

   A subscription-terminated would look like:

     <notification
         xmlns=" urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <subscription-terminated
             xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
         <identifier>39</identifier>
         <error-id>error-insufficient-resources</error-id>
       </subscription-terminated>
     </notification>

     Figure 29: subscription-modified first is
   given subscription state notification

   The above, and the subscription-suspended are virtually identical,
   with "subscription-terminated" simply being replaced by
   "subscription-suspended".

3.4.7.4.  Notification Message Flow Examples
   +------------+                 +-----------+
   |   Client   |                 |   Server  |
   +------------+                 +-----------+
         |                              |
         |    Capability Exchange       |
         |<---------------------------->|
         |                              |
         |    Establish Subscription    |
         |<---------------------------->|
         |                              |
         |        Notification          |
         |<-----------------------------| id 22, the second, id 23.

      +------------+                 +-----------+
      | Subscriber |                 | Publisher |
      +------------+                 +-----------+
            |   Subscription Suspended                              |
         |<-----------------------------|
            |    Capability Exchange       |
            |<---------------------------->|
            |                              |
            |                              |
            |    Establish Subscription Resumed      |
         |<-----------------------------|
         |    |
            |----------------------------->|
            |        Notification RPC Reply: OK, id = 22       |
            |<-----------------------------|
            |                              |

        Figure 30: subscription-suspended and resumed notifications

 +----------+                 +-----------+     +---------+  +---------+
 |  Client  |                 |   Server  |     | Rcver A |  | Rcver B |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
            |    Capability Exchange notification message (for 22)|
            |<-----------------------------|
            |                              |
            |
       |<-------------------------->|                              |
            |    Establish Subscription    |
            |----------------------------->|
            | RPC Reply: OK, id = 23       |
            |<-----------------------------|
            |                              |        Edit-config
            |                              |
            |
       |--------------------------->| notification message (for 22)|
            |<-----------------------------|
            | notification message (for 23)|
            |<-----------------------------|
            |                              |

   Figure 6: Multiple subscription establishments over a single NETCONF
                                  session

   In the example above, it is important to note that the subscription
   ids of 22 and 23 are not included in the notification messages of
   [I-D.draft-ietf-netconf-subscribed-notifications].  However because
   [I-D.ietf-netconf-yang-push] has defined its own notifications,
   subscription identifiers are available within those notification
   messages.  With the availability of
   [I.D.draft-ietf-netconf-notification-messages], all notification
   messages will be able to transport a subscription identifier.

A.2.2.  Modifying Dynamic Subscriptions

   The following demonstrates modifying a dynamic subscription.
   Consider a subscription from [I-D.ietf-netconf-yang-push].  An
   established may have a new filter applied.  The desired modification
   is the application of a new filter.

<rpc message-id="102"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <modify-subscription
       xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
       xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <yp:datastore>
      <yp:xpath-filter xmlns="http://example.com/datastore">
        /interfaces-state/interface/oper-status
      </yp:xpath-filter>
    </yp:datastore>
    <identifier>
      22
    </identifier>
  </modify-subscription>
</rpc>

                    Figure 7: Subscription modification

   If the NETCONF publisher can satisfy the request, the publisher sends
   a positive "subscription-result".  This response is like that to an
   establish-subscription request, but without the subscription
   identifier.

 <rpc-reply message-id="102"
   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <subscription-result
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      ok
   </subscription-result>
 </rpc-reply>

                 Figure 8: Successful modify-subscription

   If the NETCONF publisher cannot satisfy the request, the publisher
   sends a negative "subscription-result" element.  Its contents and
   semantics match those from an establish-subscription request.

   To get an idea of the interaction model, the following figure shows a
   successful RPC Reply: OK        |                | modification request to subscription with an
   identifier of 22.

      +------------+                 +-----------+
      |
       |<---------------------------| Subscriber |                 | Publisher |
      +------------+                 +-----------+
            |  Subscription                              |
            | notification message         |
            |<-----------------------------|
            |  Started                              |
            |     Modify Subscription      |                            |--------------->|
            |----------------------------->|
            | RPC Reply: OK                |                            |---------------------------->|
            |<-----------------------------|
            |                              |
            | notification message         |
            |<-----------------------------|
            |                              |  Notification

   Figure 9: Interaction model for successful subscription modification

A.2.3.  Deleting Dynamic Subscriptions

   The following demonstrates deleting a subscription.

  <rpc message-id="103"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <delete-subscription
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <identifier>22</identifier>
    </delete-subscription>
  </rpc>

                      Figure 10: Delete subscription

   If the NETCONF publisher can satisfy the request, the publisher sends
   an OK element.  For example:

   <rpc-reply message-id="103"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <ok/>
   </rpc-reply>

                 Figure 11: Successful delete subscription

   If the NETCONF publisher cannot satisfy the request, the publisher
   sends an error-rpc element indicating the modification didn't work.
   One way this could happen is if an existing valid subscription
   identifier was given, but that subscription was created on a
   different NETCONF transport session:

<rpc-reply message-id="103"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>invalid-value</error-tag>
    <error-severity>error</error-severity>
    <error-path
   xmlns:sn="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      sn:identifier
    </error-path>
    <error-message xml:lang="en">
        no-such-subscription
    </error-message>
  </rpc-error>
</rpc-reply>

                Figure 12: Unsuccessful delete subscription

A.3.  Configured Subscriptions

   Configured subscriptions may be established, modified, and deleted
   using configuration operations against the top-level subtree of
   [I-D.draft-ietf-netconf-subscribed-notifications] or
   [I-D.ietf-netconf-yang-push].

   In this section, we present examples of how to manage the
   configuration subscriptions using a NETCONF client.  Key differences
   from dynamic subscriptions over NETCONF is that subscription
   lifetimes are decoupled from NETCONF sessions.

A.3.1.  Creating Configured Subscriptions

   For subscription creation, a NETCONF client may send:

<rpc message-id="201"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <subscription-config
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <subscription>
        <identifier>22</identifier>
        <encoding>encode-xml</encoding>
        <stream>
          <name>NETCONF</name>
          <receiver>
            <address>1.2.3.4</address>
            <port>1234</port>
          </receiver>
        </stream>
      </subscription>
    </subscription-config>
  </edit-config>
</rpc>

                Figure 13: Create a configured subscription

   If the request is accepted, the publisher would reply:

   <rpc-reply message-id="201"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <ok/>
   </rpc-reply>

      Figure 14: Response to a successful configuration subscription
                               establishment

   If the request is not accepted because the publisher cannot serve it,
   no configuration is changed.  In this case the publisher may reply:

      <rpc-reply message-id="201"
                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
          <rpc-error>
              <error-type>application</error-type>
              <error-tag>resource-denied</error-tag>
              <error-severity>error</error-severity>
              <error-message xml:lang="en">
                  Temporarily the publisher cannot serve this
                  subscription due to the current workload.
              </error-message>
          </rpc-error>
      </rpc-reply>

   Figure 15: Response to a failed configured subscription establishment

   After a subscription has been created, NETCONF connectivity to each
   receiver's IP address and port will be established if it does not
   already exist.  This will be accomplished via [RFC8071].

   To get an idea of the interaction model, the following figure shows a
   successful configuration based creation of a subscription.

    +----------+                 +-----------+     +---------+
    |Config Ops|                 | Publisher |     |                            |--------------->| 1.2.3.4 |
    +----------+                 +-----------+     +---------+
         |                            |---------------------------->|                            |                |
         |    Capability Exchange     |                |
         |<-------------------------->|                |  Subscription
         |                            |                |
         |  Suspended                            |                |
         |                            |--------------->|        Edit-config         |                |
         |--------------------------->|                |
         |       RPC Reply: OK        |                |
         |<---------------------------|                |  Notification
         |                            |   Call Home    |                            |---------------------------->|
         |                            |<-------------->|
         |                            |                |
         |                            |  Subscription  |
         |                            |                            |  Resumed       |  Started       |
         |                            |--------------->|
         |                            |                |
         |                            |  notification  |
         |  Notification                            |  message       |
         |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

         Figure 31: Suspended and resumed notifications for a single
                            configured receiver

4.  Interleave Capability

   The :interleave capability is originally defined in [RFC5277].  It is
   incorporated in this document with essentially the same semantics.
   That is, the NETCONF server MUST receive, process, and respond to
   NETCONF requests on a session with active notification subscriptions.

   The :interleave capability is identified by the following string:
   urn:ietf:params:netconf:capability:interleave:1.0
   Note that subscription operations MUST be received, processed, and
   responded on a session with active notification subscriptions That
   mandatory requirement together with the :interleave capability
   permits a client performing all operations against a server using a
   single connection, allowing for better scalability with respect to
   the number of NETCONF sessions required to manage an entity.

5.  Security Considerations

   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
   user has sufficient authorization to perform the function they are
   requesting against the specific subset of content involved.

   The contents of notifications, as well as the names of event streams,
   may contain sensitive information and care should be taken to ensure
   that they are viewed only by authorized users.  The NETCONF server
   MUST NOT include any content in a notification that the user is not
   authorized to view.

   If a malicious or buggy NETCONF client sends a number of <establish-
   subscription>requests, then these subscriptions accumulate and may
   use up system resources.  In such a situation, 16: Interaction model for configured subscription
                               establishment

A.3.2.  Modifying Configured Subscriptions

   Configured subscriptions MAY can be
   terminated by terminating modified using configuration
   operations against the suspect underlying NETCONF sessions.
   The server MAY also suspend or terminate a subset of top-level subtree subscription-config.

   For example, the active
   subscriptions on subscription established in the NETCONF session .

   Configured subscriptions from one or more publishers previous section
   could be used to
   overwhelm modified as follows, here a receiver, which perhaps doesn't even support
   subscriptions.  Clients that do not want pushed data need only
   terminate or refuse any transport sessions from adding a second receiver:

   <rpc message-id="202"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <edit-config>
       <target>
         <running/>
       </target>
       <subscription-config
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
         <subscription>
           <identifier>
             1922
           </identifier>
           <receiver>
             <address>
               1.2.3.5
             </address>
             <port>
               1234
             </port>
           </receiver>
         </subscription>
       </subscription-config>
     </edit-config>
   </rpc>

                 Figure 17: Modify configured subscription

   If the publisher.

   The NETCONF Authorization Control Model [RFC6536] SHOULD request is accepted, the publisher would reply:

      <rpc-reply message-id="202"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <ok/>
      </rpc-reply>

       Figure 18: A successful configured subscription modification

   And the previous interaction model would be used to
   control and restrict authorization of extended as follows.

 +----------+                 +-----------+     +---------+  +---------+
 |Config Ops|                 | Publisher |     | 1.2.3.4 |  | 1.2.3.5 |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
       |                            |                |            |
       |                            |  notification  |            |
       |                            |  message       |            |
       |                            |--------------->|            |
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |   Call Home    |            |
       |                            |<--------------------------->|
       |                            |  Subscription  |            |
       |                            |  Started       |            |
       |                            |---------------------------->|
       |                            |                |            |
       |                            |  notification  |            |
       |                            |  message       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

   Figure 19: Interaction model for configured subscription configuration.
   This control models permits specifying per-user permissions to
   receive modification

   Note in the above that in the specific event notification types.  The permissions are
   specified as example above, modifying a set
   configured subscription actually resulted in subscription-started
   notification.  If the edit of access control rules.

6.  Acknowledgments

   We wish the configuration had also added a
   filter, a separate modify-subscription would have gone to acknowledge the helpful contributions, comments, and
   suggestions that were received from: Andy Bierman, Yan Gang, Sharon
   Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins,
   Balazs Lengyel, Kent Watsen, and Guangying Zheng.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use
   original receiver.

A.3.3.  Deleting Configured Subscriptions

   Configured subscriptions can be deleted using configuration
   operations against the top-level subtree subscription-config.
   Deleting the subscription above would result in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
              <https://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,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <https://www.rfc-editor.org/info/rfc6536>.

   [RFC8071]  Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              RFC 8071, DOI 10.17487/RFC8071, February 2017,
              <https://www.rfc-editor.org/info/rfc8071>.

7.2.  Informative References

   [subscribe]
              Voit, Eric., Clemm, A., Gonzalez Prieto, A., Nilsen-
              Nygaard, E., and A. Tripathy, "Custom following flow
   impacting all receivers.

 +----------+                 +-----------+     +---------+  +---------+
 |Config Ops|                 | Publisher |     | 1.2.3.4 |  | 1.2.3.5 |
 +----------+                 +-----------+     +---------+  +---------+
       |                            |                |            |
       |                            |  notification  |            |
       |                            |  message       |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |
       |        Edit-config         |                |            |
       |--------------------------->|                |            |
       |       RPC Reply: OK        |                |            |
       |<---------------------------|                |            |
       |                            |  Subscription  |            |
       |                            |  Terminated    |            |
       |                            |--------------->|            |
       |                            |---------------------------->|
       |                            |                |            |

     Figure 20: Interaction model for configured subscription deletion

A.4.  Subscription State Notifications

   A publisher will send subscription state notifications according to
              Event Notifications", September 2017,
              <https://datatracker.ietf.org/doc/
              draft-ietf-netconf-subscribed-notifications/>.

   [yang-push]
              Clemm, A., Gonzalez Prieto, A., Voit, Eric., Tripathy, A.,
              Nilsen-Nygaard, E., Bierman, A.,
   the definitions within
   [I-D.draft-ietf-netconf-subscribed-notifications]).

A.4.1.  subscription-started and B. Lengyel,
              "Subscribing to YANG datastore push updates", September
              2017, <https://datatracker.ietf.org/doc/
              draft-ietf-netconf-yang-push/>.

Appendix A.  Open Items

   (To be removed subscription-modified

   A subscription-started over NETCONF encoded in XML would look like:

 <notification
   xmlns=" urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-09-01T10:00:00Z</eventTime>
   <subscription-started
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"/>
     <identifier>39</identifier>
     <encoding>encode-xml</encoding>
     <stream>
       <name>NETCONF</name>
       <xpath-filter xmlns:ex="http://example.com/events">
            /ex:foo
       </xpath-filter>
     </stream>
   </subscription-started/>
 </notification>

      Figure 21: subscription-started subscription state notification

   The subscription-modified is identical, with just the word "started"
   being replaced by RFC editor prior to publication)

   o  Formal definition of: notification-contents-json, "modified".

A.4.2.  subscription-completed, subscription-resumed, and
      incorporation of the subscription-id replay-
        complete

   A subscription-completed would look like:

  <notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2007-09-01T10:00:00Z</eventTime>
    <subscription-completed
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <identifier>39</identifier>
    </subscription-completed>
  </notification>

           Figure 22: subscription-completed notification in the notifications.  It
      depends on the formal definition of the XML

   The subscription-resumed and replay-complete are virtually identical,
   with "subscription-completed" simply being replaced by "subscription-
   resumed" and "replay-complete" in both encodings.

A.4.3.  subscription-terminated and subscription-suspended

   A subscription-terminated would look like:

  <notification
    xmlns=" urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2007-09-01T10:00:00Z</eventTime>
    <subscription-terminated
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <identifier>39</identifier>
      <error-id>
         unsupportable-volume
      </error-id>
    </subscription-terminated>
  </notification>

    Figure 23: subscription-terminated subscription state notification element

   The subscription-suspended is virtually identical, with
   "subscription-terminated" simply being replaced by "subscription-
   suspended".

Appendix B.  Changes between revisions

   (To be removed by RFC editor prior to publication)

B.1.  v04 to  v05 to v06

   o  Text presentation modifications throughout

   o  Modified  Moved examples to match the namespace, prefixes, and data node
      identifiers in [subscribe] and [yang-push] appendices

   o  Modified  All examples to include <subscription-result> rewritten based on namespace learnings

   o  Normative text consolidated in front

   o  Removed all RPC
      responses mention of JSON

   o  Modified examples  Call home process detailed

   o  Note: this is a major revision attempting to include mandatory fields in [subscribe] and
      [yang-push] cover those comments
      received from two week review.

B.2.  v03 to v04

   o  Added additional detail to "configured subscriptions"

   o  Added interleave capability

   o  Adjusted terminology to that in draft-ietf-netconf-subscribed-
      notifications

   o  Corrected namespaces in examples

B.3.  v01 to v03

   o  Text simplifications throughout

   o  v02 had no meaningful changes

B.4.  v00 to v01

   o  Added Call Home in solution for configured subscriptions.

   o  Clarified support for multiple subscription on a single session.
      No need to support multiple create-subscription.

   o  Added mapping between terminology in [yang-push] yang-push and [RFC6241] (the
      one followed in this document).

   o  Editorial improvements.

Authors' Addresses

   Alberto Gonzalez Prieto
   VMware

   Email: agonzalezpri@vmware.com

   Alexander Clemm
   Huawei

   Email: ludwig@clemm.org

   Eric Voit
   Cisco Systems

   Email: evoit@cisco.com

   Alexander Clemm
   Huawei

   Email: ludwig@clemm.org

   Einar Nilsen-Nygaard
   Cisco Systems

   Email: einarnn@cisco.com

   Ambika Prasad Tripathy
   Cisco Systems

   Email: ambtripa@cisco.com