draft-ietf-netconf-restconf-notif-15.txt   rfc8650.txt 
NETCONF E. Voit Internet Engineering Task Force (IETF) E. Voit
Internet-Draft R. Rahman Request for Comments: 8650 R. Rahman
Intended status: Standards Track E. Nilsen-Nygaard Category: Standards Track E. Nilsen-Nygaard
Expires: December 13, 2019 Cisco Systems ISSN: 2070-1721 Cisco Systems
A. Clemm A. Clemm
Huawei Futurewei
A. Bierman A. Bierman
YumaWorks YumaWorks
June 11, 2019 November 2019
Dynamic subscription to YANG Events and Datastores over RESTCONF Dynamic Subscription to YANG Events and Datastores over RESTCONF
draft-ietf-netconf-restconf-notif-15
Abstract Abstract
This document provides a RESTCONF binding to the dynamic subscription This document provides a RESTCONF binding to the dynamic subscription
capability of both subscribed notifications and YANG-Push. capability of both subscribed notifications and YANG-Push.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 13, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8650.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3 3. Dynamic Subscriptions
3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4 3.1. Transport Connectivity
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Discovery
3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4 3.3. RESTCONF RPCs and HTTP Status Codes
3.4. Call Flow for Server-Sent Events . . . . . . . . . . . . 7 3.4. Call Flow for Server-Sent Events
4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 9 4. QoS Treatment
5. Notification Messages . . . . . . . . . . . . . . . . . . . . 10 5. Notification Messages
6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. YANG Tree
7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. YANG Module
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Examples
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Dynamic Subscriptions
A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 16 A.1.1. Establishing Dynamic Subscriptions
A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 16 A.1.2. Modifying Dynamic Subscriptions
A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 19 A.1.3. Deleting Dynamic Subscriptions
A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 21 A.2. Subscription State Notifications
A.2. Subscription State Notifications . . . . . . . . . . . . 21 A.2.1. "subscription-modified"
A.2.1. subscription-modified . . . . . . . . . . . . . . . . 22 A.2.2. "subscription-completed", "subscription-resumed", and
A.2.2. subscription-completed, subscription-resumed, and "replay-completed"
replay-complete . . . . . . . . . . . . . . . . . . . 22 A.2.3. "subscription-terminated" and "subscription-suspended"
A.2.3. subscription-terminated and subscription-suspended . 22 A.3. Filter Example
A.3. Filter Example . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments
Appendix B. Changes between revisions . . . . . . . . . . . . . 24 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Mechanisms to support event subscription and push are defined in Mechanisms to support event subscription and YANG-Push are defined in
[I-D.draft-ietf-netconf-subscribed-notifications]. Enhancements to [RFC8639]. Enhancements to [RFC8639] that enable YANG datastore
[I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG subscription and YANG-Push are defined in [RFC8641]. This document
datastore subscription and push are defined in provides a transport specification for dynamic subscriptions over
[I-D.ietf-netconf-yang-push]. This document provides a transport RESTCONF [RFC8040]. Requirements for these mechanisms are captured
specification for dynamic subscriptions over RESTCONF [RFC8040]. in [RFC7923].
Requirements for these mechanisms are captured in [RFC7923].
The streaming of notifications encapsulating the resulting The streaming of notifications that encapsulate the resulting
information push is done via the mechanism described in section 6.3 information push is done via the mechanism described in Section 6.3
of [RFC8040]. of [RFC8040].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms use the definitions from The following terms use the definitions from [RFC8639]: dynamic
[I-D.draft-ietf-netconf-subscribed-notifications]: dynamic
subscription, event stream, notification message, publisher, subscription, event stream, notification message, publisher,
receiver, subscriber, and subscription. receiver, subscriber, and subscription.
Other terms reused include datastore, which is defined in [RFC8342], Other terms reused include datastore, which is defined in [RFC8342],
and HTTP2 stream which maps to the definition of "stream" within and HTTP/2 stream, which maps to the definition of "stream" within
[RFC7540], Section 2. [RFC7540], Section 2.
[ note to the RFC Editor - please replace XXXX within this document
with the number of this document ]
3. Dynamic Subscriptions 3. Dynamic Subscriptions
This section provides specifics on how to establish and maintain This section provides specifics on how to establish and maintain
dynamic subscriptions over RESTCONF [RFC8040]. Subscribing to event dynamic subscriptions over RESTCONF [RFC8040]. Subscribing to event
streams is accomplished in this way via RPCs defined within streams is accomplished in this way via RPCs defined within
[I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4. The [RFC8639], Section 2.4. The RPCs are done via RESTCONF POSTs. YANG
RPCs are done via RESTCONF POSTs. YANG datastore subscription is datastore subscription is accomplished via augmentations to [RFC8639]
accomplished via augmentations to as described within [RFC8641], Section 4.4.
[I-D.draft-ietf-netconf-subscribed-notifications] as described within
[I-D.ietf-netconf-yang-push] Section 4.4.
As described in [RFC8040] Section 6.3, a GET needs to be made against As described in Section 6.3 of [RFC8040], a GET needs to be performed
a specific URI on the publisher. Subscribers cannot pre-determine on a specific URI on the publisher. Subscribers cannot predetermine
the URI against which a subscription might exist on a publisher, as the URI against which a subscription might exist on a publisher, as
the URI will only exist after the "establish-subscription" RPC has the URI will only exist after the "establish-subscription" RPC has
been accepted. Therefore, the POST for the "establish-subscription" been accepted. Therefore, the POST for the "establish-subscription"
RPC replaces the GET request for the "location" leaf which is used in RPC replaces the GET request for the "location" leaf that is used in
[RFC8040] to obtain the URI. The subscription URI will be determined [RFC8040] to obtain the URI. The subscription URI will be determined
and sent as part of the response to the "establish-subscription" RPC, and sent as part of the response to the "establish-subscription" RPC,
and a subsequent GET to this URI will be done in order to start the and a subsequent GET to this URI will be done in order to start the
flow of notification messages back to the subscriber. A subscription flow of notification messages back to the subscriber. As specified
does not move to the active state as per Section 2.4.1. of in Section 2.4.1 of [RFC8639], a subscription does not move to the
[I-D.draft-ietf-netconf-subscribed-notifications] until the GET is active state until the GET is received.
received.
3.1. Transport Connectivity 3.1. Transport Connectivity
For a dynamic subscription, where a RESTCONF session doesn't already For a dynamic subscription, when a RESTCONF session doesn't already
exist, a new RESTCONF session is initiated from the subscriber. exist, a new RESTCONF session is initiated from the subscriber.
As stated in Section 2.1 of [RFC8040], a subscriber MUST establish As stated in Section 2.1 of [RFC8040], a subscriber MUST establish
the HTTP session over TLS [RFC8446] in order to secure the content in the HTTP session over TLS [RFC8446] in order to secure the content in
transit. transit.
Without the involvement of additional protocols, HTTP sessions by Without the involvement of additional protocols, HTTP sessions by
themselves do not allow for a quick recognition of when the themselves do not support quick recognition of the loss of the
communication path has been lost with the publisher. Where quick communication path to the publisher. Where quick recognition of the
recognition of the loss of a publisher is required, a subscriber loss of a publisher is required, a subscriber SHOULD use a TLS
SHOULD use a TLS heartbeat [RFC6520], just from subscriber to heartbeat [RFC6520], just from subscriber to publisher, to track HTTP
publisher, to track HTTP session continuity. session continuity.
Loss of the heartbeat MUST result in any subscription related TCP Loss of the heartbeat MUST result in the teardown of any
sessions between those endpoints being torn down. A subscriber can subscription-related TCP sessions between those endpoints. A
then attempt to re-establish the dynamic subscription by using the subscriber can then attempt to re-establish the dynamic subscription
procedure described in Section 3.4. by using the procedure described in Section 3.4.
3.2. Discovery 3.2. Discovery
Subscribers can learn what event streams a RESTCONF server supports Subscribers can learn which event streams a RESTCONF server supports
by querying the "streams" container of ietf-subscribed- by querying the "streams" container of ietf-subscribed-
notification.yang in notifications.yang in [RFC8639]. Support for the "streams" container
[I-D.draft-ietf-netconf-subscribed-notifications]. Support for the of ietf-restconf-monitoring.yang in [RFC8040] is not required. In
"streams" container of ietf-restconf-monitoring.yang in [RFC8040] is the case when the RESTCONF binding specified by this document is used
not required. In the case when the RESTCONF binding specified by to convey the "streams" container from ietf-restconf-monitoring.yang
this document is used to convey the "streams" container from ietf- (i.e., that feature is supported), any event streams contained
restconf-monitoring.yang (i.e., that feature is supported), any event therein are also expected to be present in the "streams" container of
streams contained therein are also expected to be present in the ietf-restconf-monitoring.yang.
"streams" container of ietf-restconf-monitoring.yang.
Subscribers can learn what datastores a RESTCONF server supports by Subscribers can learn which datastores a RESTCONF server supports by
following Section 2 of [I-D.draft-ietf-netconf-nmda-restconf]. following Section 2 of [RFC8527].
3.3. RESTCONF RPCs and HTTP Status Codes 3.3. RESTCONF RPCs and HTTP Status Codes
Specific HTTP responses codes as defined in [RFC7231] section 6 will Specific HTTP response codes as defined in Section 6 of [RFC7231]
indicate the result of RESTCONF RPC requests with the publisher. An will indicate the result of RESTCONF RPC requests with the publisher.
HTTP status code of 200 is the proper response to any successful RPC An HTTP status code of 200 is the proper response to any successful
defined within [I-D.draft-ietf-netconf-subscribed-notifications] or RPC defined within [RFC8639] or [RFC8641].
[I-D.ietf-netconf-yang-push].
If a publisher fails to serve the RPC request for one of the reasons If a publisher fails to serve the RPC request for one of the reasons
indicated in [I-D.draft-ietf-netconf-subscribed-notifications] indicated in Section 2.4.6 of [RFC8639] or Appendix A of [RFC8641],
Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will this will be indicated by an appropriate error code, as shown below,
be indicated by an appropriate error code, as shown below,
transported in the HTTP response. transported in the HTTP response.
When an HTTP error code is returned, the RPC reply MUST include an When an HTTP error code is returned, the RPC reply MUST include an
"rpc-error" element per [RFC8040] Section 7.1 with the following <rpc-error> element per Section 7.1 of [RFC8040] with the following
parameter values: parameter values:
o an "error-type" node of "application". * an "error-type" node of "application".
o an "error-tag" node with the value being a string that corresponds * an "error-tag" node whose value is a string that corresponds to an
to an identity associated with the error. This "error-tag" will identity associated with the error. This "error-tag" will come
come from one of two places. Either it will correspond to the from one of two places and will correspond to the error identities
error identities within either within Section 2.4.6 of [RFC8639] for general subscription
[I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 errors (Table 1) or within Appendix A.1 of [RFC8641] for
for general subscription errors: subscription errors specific to YANG datastores (Table 2).
error identity uses error-tag HTTP Code * an "error-app-tag" node whose value is a string that corresponds
---------------------- -------------- --------- to an identity associated with the error, as defined in
dscp-unavailable invalid-value 400 Section 2.4.6 of [RFC8639] for general subscriptions or
encoding-unsupported invalid-value 400 Appendix A.1 of [RFC8641] for subscription errors specific to YANG
filter-unsupported invalid-value 400 datastores. The tag to use depends on the RPC for which the error
insufficient-resources resource-denied 409 occurred. Viable errors for different RPCs are found in Table 3.
no-such-subscription invalid-value 404
replay-unsupported operation-not-supported 501
Or this "error-tag" will correspond to the error identities within +------------------------+-------------------------+-----------+
[I-D.ietf-netconf-yang-push] Appendix A.1 for subscription errors | Error identity | Uses "error-tag" | HTTP code |
specific to YANG datastores: +========================+=========================+===========+
| dscp-unavailable | invalid-value | 400 |
+------------------------+-------------------------+-----------+
| encoding-unsupported | invalid-value | 400 |
+------------------------+-------------------------+-----------+
| filter-unsupported | invalid-value | 400 |
+------------------------+-------------------------+-----------+
| insufficient-resources | resource-denied | 409 |
+------------------------+-------------------------+-----------+
| no-such-subscription | invalid-value | 404 |
+------------------------+-------------------------+-----------+
| replay-unsupported | operation-not-supported | 501 |
+------------------------+-------------------------+-----------+
error identity uses error-tag HTTP Code Table 1: General Subscription Error Identities and
---------------------- -------------- --------- Associated "error-tag" Use
cant-exclude operation-not-supported 501
datastore-not-subscribable invalid-value 400
no-such-subscription-resync invalid-value 404
on-change-unsupported operation-not-supported 501
on-change-sync-unsupported operation-not-supported 501
period-unsupported invalid-value 400
update-too-big too-big 400
sync-too-big too-big 400
unchanging-selection operation-failed 500
o an "error-app-tag" node with the value being a string that +-----------------------------+-------------------------+-----------+
corresponds to an identity associated with the error, as defined | Error identity | Uses "error-tag" | HTTP |
in [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6 | | | code |
for general subscriptions, and [I-D.ietf-netconf-yang-push] +=============================+=========================+===========+
Appendix A.1, for datastore subscriptions. The tag to use depends | cant-include | operation-not-supported | 501 |
on the RPC for which the error occurred. Viable errors for +-----------------------------+-------------------------+-----------+
different RPCs are as follows: | datastore-not-subscribable | invalid-value | 400 |
+-----------------------------+-------------------------+-----------+
| no-such-subscription-resync | invalid-value | 404 |
+-----------------------------+-------------------------+-----------+
| on-change-unsupported | operation-not-supported | 501 |
+-----------------------------+-------------------------+-----------+
| on-change-sync-unsupported | operation-not-supported | 501 |
+-----------------------------+-------------------------+-----------+
| period-unsupported | invalid-value | 400 |
+-----------------------------+-------------------------+-----------+
| update-too-big | too-big | 400 |
+-----------------------------+-------------------------+-----------+
| sync-too-big | too-big | 400 |
+-----------------------------+-------------------------+-----------+
| unchanging-selection | operation-failed | 500 |
+-----------------------------+-------------------------+-----------+
RPC select an identity with a base Table 2: Datastore-Specific Error Identities and Associated
---------------------- ------------------------------ "error-tag" Use
establish-subscription establish-subscription-error
modify-subscription modify-subscription-error +------------------------+--------------------------------+
delete-subscription delete-subscription-error | RPC | Select an identity with a base |
kill-subscription delete-subscription-error +========================+================================+
resync-subscription resync-subscription-error | establish-subscription | establish-subscription-error |
+------------------------+--------------------------------+
| modify-subscription | modify-subscription-error |
+------------------------+--------------------------------+
| delete-subscription | delete-subscription-error |
+------------------------+--------------------------------+
| kill-subscription | delete-subscription-error |
+------------------------+--------------------------------+
| resync-subscription | resync-subscription-error |
+------------------------+--------------------------------+
Table 3: RPC Errors and Associated Error Identities
Each error identity will be inserted as the "error-app-tag" using Each error identity will be inserted as the "error-app-tag" using
JSON encoding following the form <modulename>:<identityname>. An JSON encoding following the form <modulename>:<identityname>. An
example of such a valid encoding would be "ietf-subscribed- example of such a valid encoding would be "ietf-subscribed-
notifications:no-such-subscription". notifications:no-such-subscription".
In case of error responses to an "establish-subscription" or "modify- In the case of error responses to an "establish-subscription" or
subscription" request there is the option of including an "error- "modify-subscription" request, there is the option to include an
info" node. This node may contain hints for parameter settings that "error-info" node. This node may contain hints for parameter
might lead to successful RPC requests in the future. Following are settings that might lead to successful RPC requests in the future.
the yang-data structures which may be returned: Tables 4 and 5 show the yang-data structures that may be returned.
establish-subscription returns hints in yang-data structure +--------------+---------------------------------------------+
---------------------- ------------------------------------ | Target: | Return hints in yang-data structure |
target: event stream establish-subscription-stream-error-info +==============+=============================================+
target: datastore establish-subscription-datastore-error-info | event stream | establish-subscription-stream-error-info |
+--------------+---------------------------------------------+
| datastore | establish-subscription-datastore-error-info |
+--------------+---------------------------------------------+
modify-subscription returns hints in yang-data structure Table 4: Optional "error-info" Node Hints for an
---------------------- ------------------------------------ "establish-subscription" Request
target: event stream modify-subscription-stream-error-info
target: datastore modify-subscription-datastore-error-info
The yang-data included within "error-info" SHOULD NOT include the +--------------+------------------------------------------+
optional leaf "reason", as such a leaf would be redundant | Target: | Returns hints in yang-data structure |
with information that is already placed within the +==============+==========================================+
"error-app-tag". | event stream | modify-subscription-stream-error-info |
+--------------+------------------------------------------+
| datastore | modify-subscription-datastore-error-info |
+--------------+------------------------------------------+
In case of an rpc error as a result of a "delete-subscription", a Table 5: Optional "error-info" Node Hints for an
"kill-subscription", or a "resync-subscription" request, no "modify-subscription" Request
"error-info" needs to be included, as the "subscription-id" is
the only RPC input parameter and no hints regarding this RPC input The yang-data included within "error-info" SHOULD NOT include the
parameters need to be provided. optional leaf "reason", as such a leaf would be redundant with
information that is already placed within the "error-app-tag".
In case of an <rpc-error> as a result of a "delete-subscription", a
"kill-subscription", or a "resync-subscription" request, no "error-
info" needs to be included, as the "subscription-id" is the only RPC
input parameter, and no hints regarding this RPC input parameters
need to be provided.
Note that "error-path" [RFC8040] does not need to be included with Note that "error-path" [RFC8040] does not need to be included with
the "rpc-error" element, as subscription errors are generally the <rpc-error> element, as subscription errors are generally
associated with the choice of RPC input parameters. associated with the choice of RPC input parameters.
3.4. Call Flow for Server-Sent Events 3.4. Call Flow for Server-Sent Events
The call flow for Server-Sent Events (SSE) is defined in Figure 1. The call flow for Server-Sent Events (SSE) is defined in Figure 1.
The logical connections denoted by (a) and (b) can be a TCP The logical connections denoted by (a) and (b) can be a TCP
connection or an HTTP2 stream (if HTTP2 is used, multiple HTTP2 connection or an HTTP/2 stream (if HTTP/2 is used, multiple HTTP/2
streams can be carried in one TCP connection). Requests to streams can be carried in one TCP connection). Requests to RPCs as
[I-D.draft-ietf-netconf-subscribed-notifications] or defined in [RFC8639] or [RFC8641] are sent on a connection indicated
[I-D.ietf-netconf-yang-push] augmented RPCs are sent on a connection by (a). A successful "establish-subscription" will result in an RPC
indicated by (a). A successful "establish-subscription" will result response returned with both a subscription identifier that uniquely
in an RPC response returned with both a subscription identifier which identifies a subscription, as well as a URI that uniquely identifies
uniquely identifies a subscription, as well as a URI which uniquely the location of subscription on the publisher (b). This URI is
identifies the location of subscription on the publisher (b). This defined via the "uri" leaf in the data model in Section 7.
URI is defined via the "uri" leaf the Data Model in Section 7.
An HTTP GET is then sent on a separate logical connection (b) to the An HTTP GET is then sent on a separate logical connection (b) to the
URI on the publisher. This signals the publisher to initiate the URI on the publisher. This signals the publisher to initiate the
flow of notification messages which are sent in SSE [W3C-20150203] as flow of notification messages that are sent in SSE [W3C-20150203] as
a response to the GET. There cannot be two or more simultaneous GET a response to the GET. There cannot be two or more simultaneous GET
requests on a subscription URI: any GET request received while there requests on a subscription URI: any GET request received while there
is a current GET request on the same URI MUST be rejected with HTTP is a current GET request on the same URI MUST be rejected with HTTP
error code 409. error code 409.
As described in [RFC8040] Section 6.4, RESTCONF servers SHOULD NOT As described in Section 6.4 of [RFC8040], RESTCONF servers SHOULD NOT
send the "event" or "id" fields in the SSE event notifications. send the "event" or "id" fields in the SSE event notifications.
+--------------+ +--------------+ +--------------+ +--------------+
| Subscriber | | Publisher | | Subscriber | | Publisher |
| | | | | | | |
| Logical | | Logical | | Logical | | Logical |
| Connection | | Connection | | Connection | | Connection |
| (a) (b) | | (a) (b) | | (a) (b) | | (a) (b) |
+--------------+ +--------------+ +--------------+ +--------------+
| RESTCONF POST (RPC:establish-subscription) | | RESTCONF POST (RPC:establish-subscription) |
skipping to change at page 8, line 38 skipping to change at line 364
| | SSE (notif-message)| | | SSE (notif-message)|
| |<---------------------------------------------| | |<---------------------------------------------|
| RESTCONF POST (RPC:delete-subscription) | | | RESTCONF POST (RPC:delete-subscription) | |
|--------------------------------------------->| | |--------------------------------------------->| |
| | HTTP 200 OK| | | | HTTP 200 OK| |
|<---------------------------------------------| | |<---------------------------------------------| |
| | | | | | | |
| | | | | | | |
(a) (b) (a) (b) (a) (b) (a) (b)
Figure 1: Dynamic with server-sent events Figure 1: Dynamic Subscriptions with Server-Sent Events
Additional requirements for dynamic subscriptions over SSE include: Additional requirements for dynamic subscriptions over SSE include:
o All subscription state notifications from a publisher MUST be * A publisher MUST return all subscription state notifications in a
returned in a separate SSE message used by the subscription to separate SSE message used by the subscription to which the state
which the state change refers. change refers.
o Subscription RPCs MUST NOT use the connection currently providing * Subscription RPCs MUST NOT use the connection currently providing
notification messages for that subscription. notification messages for that subscription.
o In addition to an RPC response for a "modify-subscription" RPC * In addition to an RPC response for a "modify-subscription" RPC
traveling over (a), a "subscription-modified" state change traveling over (a), a "subscription-modified" state change
notification MUST be sent within (b). This allows the receiver to notification MUST be sent within (b). This allows the receiver to
know exactly when, within the stream of events, the new terms of know exactly when, within the stream of events, the new terms of
the subscription have been applied to the notification messages. the subscription have been applied to the notification messages.
See arrow (c). See arrow (c).
o In addition to any required access permissions (e.g., NACM), RPCs * In addition to any required access permissions (e.g., Network
modify-subscription, resync-subscription and delete-subscription Configuration Access Control Model (NACM)), the RPCs "modify-
subscription", "resync-subscription", and "delete-subscription"
SHOULD only be allowed by the same RESTCONF username [RFC8040] SHOULD only be allowed by the same RESTCONF username [RFC8040]
which invoked establish-subscription. Such a restriction that invoked "establish-subscription". Such a restriction
generally serves to preserve users' privacy, but exceptions might generally serves to preserve users' privacy, but exceptions might
be made for administrators that may need to modify or delete other be made for administrators that may need to modify or delete other
users' subscriptions. users' subscriptions.
o The kill-subscription RPC can be invoked by any RESTCONF username * The "kill-subscription" RPC can be invoked by any RESTCONF
with the required administrative permissions. username with the required administrative permissions.
A publisher MUST terminate a subscription in the following cases: A publisher MUST terminate a subscription in the following cases:
o Receipt of a "delete-subscription" or a "kill-subscription" RPC * Receipt of a "delete-subscription" or a "kill-subscription" RPC
for that subscription. for that subscription
o Loss of TLS heartbeat * Loss of TLS heartbeat
A publisher MAY terminate a subscription at any time as stated in A publisher MAY terminate a subscription at any time as stated in
[I-D.draft-ietf-netconf-subscribed-notifications] Section 1.3 Section 1.3 of [RFC8639].
4. QoS Treatment 4. QoS Treatment
Qos treatment for event streams is described in Qos treatment for event streams is described in Section 2.3 of
[I-D.draft-ietf-netconf-subscribed-notifications] Section 2.3. In [RFC8639]. In addition, if HTTP/2 is used, the publisher MUST:
addition, if HTTP2 is used, the publisher MUST:
o take the "weighting" leaf node in * Take the "weighting" leaf node in [RFC8639] and copy it into the
[I-D.draft-ietf-netconf-subscribed-notifications], and copy it HTTP/2 stream weight, Section 5.3 of [RFC7540], and
into the HTTP2 stream weight, [RFC7540] section 5.3, and
o take any existing subscription "dependency", as specified by the * Take any existing subscription "dependency", as specified by the
"dependency" leaf node in "dependency" leaf node in [RFC8639], and use the HTTP/2 stream for
[I-D.draft-ietf-netconf-subscribed-notifications], and use the the parent subscription as the HTTP/2 stream dependency (as
HTTP2 stream for the parent subscription as the HTTP2 stream described in Section 5.3.1 of [RFC7540]) of the dependent
dependency, [RFC7540] section 5.3.1, of the dependent
subscription. subscription.
o set the exclusive flag, [RFC7540] section 5.3.1, to 0. * Set the exclusive flag (Section 5.3.1 of [RFC7540]) to 0.
For dynamic subscriptions with the same DSCP value to a specific For dynamic subscriptions with the same Differentiated Services Code
publisher, it is recommended that the subscriber sends all URI GET Point (DSCP) value to a specific publisher, it is recommended that
requests on a common HTTP2 session (if HTTP2 is used). Conversely, a the subscriber sends all URI GET requests on a common HTTP/2 session
subscriber can not use a common HTTP2 session for subscriptions with (if HTTP/2 is used). Conversely, a subscriber cannot use a common
different DSCP values. HTTP/2 session for subscriptions with different DSCP values.
5. Notification Messages 5. Notification Messages
Notification messages transported over RESTCONF will be encoded Notification messages transported over RESTCONF will be encoded
according to [RFC8040], section 6.4. according to [RFC8040], Section 6.4.
6. YANG Tree 6. YANG Tree
The YANG model defined in Section 7 has one leaf augmented into three The YANG module defined in Section 7 has one leaf that augments three
places of [I-D.draft-ietf-netconf-subscribed-notifications]. nodes of [RFC8639].
module: ietf-restconf-subscribed-notifications module: ietf-restconf-subscribed-notifications
augment /sn:establish-subscription/sn:output: augment /sn:establish-subscription/sn:output:
+--ro uri? inet:uri +--ro uri? inet:uri
augment /sn:subscriptions/sn:subscription: augment /sn:subscriptions/sn:subscription:
+--ro uri? inet:uri +--ro uri? inet:uri
augment /sn:subscription-modified: augment /sn:subscription-modified:
+--ro uri? inet:uri +--ro uri? inet:uri
7. YANG module 7. YANG Module
This module references This module references [RFC8639].
[I-D.draft-ietf-netconf-subscribed-notifications].
<CODE BEGINS> file <CODE BEGINS>
"ietf-restconf-subscribed-notifications@2019-01-11.yang" file "ietf-restconf-subscribed-notifications@2019-11-17.yang"
module ietf-restconf-subscribed-notifications { module ietf-restconf-subscribed-notifications {
yang-version 1.1; yang-version 1.1;
namespace namespace "urn:ietf:params:xml:ns:yang:"
"urn:ietf:params:xml:ns:yang:" + + "ietf-restconf-subscribed-notifications";
"ietf-restconf-subscribed-notifications"; prefix rsn;
prefix rsn; import ietf-subscribed-notifications {
prefix sn;
}
import ietf-inet-types {
prefix inet;
}
import ietf-subscribed-notifications { organization
prefix sn; "IETF NETCONF (Network Configuration) Working Group";
} contact
import ietf-inet-types { "WG Web: <https://datatracker.ietf.org/wg/netconf/>
prefix inet; WG List: <mailto:netconf@ietf.org>
}
organization "IETF NETCONF (Network Configuration) Working Group"; Editor: Eric Voit
contact <mailto:evoit@cisco.com>
"WG Web: <http:/tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Editor: Eric Voit Editor: Alexander Clemm
<mailto:evoit@cisco.com> <mailto:ludwig@clemm.org>
Editor: Alexander Clemm Editor: Reshad Rahman
<mailto:ludwig@clemm.org> <mailto:rrahman@cisco.com>";
description
"Defines RESTCONF as a supported transport for subscribed
event notifications.
Editor: Reshad Rahman Copyright (c) 2019 IETF Trust and the persons identified
<mailto:rrahman@cisco.com>"; as authors of the code. All rights reserved.
description Redistribution and use in source and binary forms, with or
"Defines RESTCONF as a supported transport for subscribed without modification, is permitted pursuant to, and subject to
event notifications. the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Copyright (c) 2019 IETF Trust and the persons identified as authors This version of this YANG module is part of RFC 8650; see the
of the code. All rights reserved. RFC itself for full legal notices.";
Redistribution and use in source and binary forms, with or without revision 2019-11-17 {
modification, is permitted pursuant to, and subject to the license description
terms contained in, the Simplified BSD License set forth in Section "Initial version";
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents reference
(https://trustee.ietf.org/license-info). "RFC 8650: Dynamic Subscription to YANG Events and Datastores
over RESTCONF";
}
This version of this YANG module is part of RFC XXXX; see the RFC grouping uri {
itself for full legal notices."; description
"Provides a reusable description of a URI.";
leaf uri {
type inet:uri;
config false;
description
"Location of a subscription-specific URI on the publisher.";
}
}
revision 2019-01-11 { augment "/sn:establish-subscription/sn:output" {
description description
"Initial version"; "This augmentation allows RESTCONF-specific parameters for a
reference response to a publisher's subscription request.";
"RFC XXXX: RESTCONF Transport for Event Notifications"; uses uri;
} }
grouping uri { augment "/sn:subscriptions/sn:subscription" {
description description
"Provides a reusable description of a URI."; "This augmentation allows RESTCONF-specific parameters to be
leaf uri { exposed for a subscription.";
type inet:uri; uses uri;
config false; }
description
"Location of a subscription specific URI on the publisher.";
}
}
augment "/sn:establish-subscription/sn:output" { augment "/sn:subscription-modified" {
description description
"This augmentation allows RESTCONF specific parameters for a "This augmentation allows RESTCONF-specific parameters to be
response to a publisher's subscription request."; included as part of the notification that a subscription has
uses uri; been modified.";
} uses uri;
}
}
<CODE ENDS>
augment "/sn:subscriptions/sn:subscription" { 8. IANA Considerations
description
"This augmentation allows RESTCONF specific parameters to be
exposed for a subscription.";
uses uri;
}
augment "/sn:subscription-modified" { This document registers the following namespace URI in the "ns"
description subregistry of the "IETF XML Registry" [RFC3688]:
"This augmentation allows RESTCONF specific parameters to be
included as part of the notification that a subscription has been
modified.";
uses uri;
}
}
<CODE ENDS>
8. IANA Considerations URI:
urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed-notifications
This document registers the following namespace URI in the "IETF XML Registrant Contact: The IESG.
Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed- XML: N/A; the requested URI is an XML namespace.
notifications
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG module in the "YANG Module This document registers the following YANG module in the "YANG Module
Names" registry [RFC6020]: Names" registry [RFC6020]:
Name: ietf-restconf-subscribed-notifications Name: ietf-restconf-subscribed-notifications
Namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed-
notifications Namespace:
Prefix: rsn urn:ietf:params:xml:ns:yang:ietf-restconf-subscribed-notifications
Reference: RFC XXXX: RESTCONF Transport for Event Notifications
Prefix: rsn
Reference: RFC 8650
9. Security Considerations 9. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management transports that is designed to be accessed via network management transports
such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF
layer is the secure transport layer, and the mandatory-to-implement layer is the secure transport layer, and the mandatory-to-implement
secure transport is Secure Shell (SSH) [RFC6242]. The lowest secure transport is Secure Shell (SSH) [RFC6242]. The lowest
RESTCONF layer is HTTPS, and the mandatory-to-implement secure RESTCONF layer is HTTPS, and the mandatory-to-implement secure
transport is TLS [RFC8446]. transport is TLS [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
The one new data node introduced in this YANG module may be The one new data node introduced in this YANG module may be
considered sensitive or vulnerable in some network environments. It considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to this data nodes. These are the subtrees and data or notification) to this data node. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
Container: "/subscriptions" Container: "/subscriptions"
o "uri": leaf will show where subscribed resources might be located * "uri": leaf will show where subscribed resources might be located
on a publisher. Access control must be set so that only someone on a publisher. Access control must be set so that only someone
with proper access permissions, i.e., the same RESTCONF [RFC8040] with proper access permissions, i.e., the same RESTCONF [RFC8040]
user credentials which invoked the corresponding "establish- user credentials that invoked the corresponding "establish-
subscription", has the ability to access this resource. subscription", has the ability to access this resource.
The subscription URI is implementation specific and is encrypted via The subscription URI is implementation specific and is encrypted via
the use of TLS. Therefore, even if an attacker succeeds in guessing the use of TLS. Therefore, even if an attacker succeeds in guessing
the subscription URI, a RESTCONF username [RFC8040] with the required the subscription URI, a RESTCONF username [RFC8040] with the required
administrative permissions must be used to be able to access or administrative permissions must be used to be able to access or
modify that subscription. It is recommended that the subscription modify that subscription. It is recommended that the subscription
URI values not be easily predictable. URI values not be easily predictable.
The access permission considerations for the RPCs modify- The access permission considerations for the RPCs "modify-
subscription, resync-subscription, delete-subscription and kill- subscription", "resync-subscription", "delete-subscription", and
subscription are described in Section 3.4. "kill-subscription" are described in Section 3.4.
If a buggy or compromised RESTCONF subscriber sends a number of If a buggy or compromised RESTCONF subscriber sends a number of
"establish-subscription" requests, then these subscriptions "establish-subscription" requests, then these subscriptions
accumulate and may use up system resources. In such a situation, the accumulate and may use up system resources. In such a situation, the
publisher MAY also suspend or terminate a subset of the active publisher MAY also suspend or terminate a subset of the active
subscriptions from that RESTCONF subscriber in order to reclaim subscriptions from that RESTCONF subscriber in order to reclaim
resources and preserve normal operation for the other subscriptions. resources and preserve normal operation for the other subscriptions.
10. Acknowledgments 10. References
We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from: Ambika Prasad Tripathy, Alberto
Gonzalez Prieto, Susan Hares, Tim Jenkins, Balazs Lengyel, Kent
Watsen, Michael Scharf, Guangying Zheng, Martin Bjorklund, Qin Wu and
Robert Wilton.
11. References
11.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 to Event
Streams", draft-ietf-netconf-subscribed-notifications-21
(work in progress), January 2019.
[I-D.ietf-netconf-yang-push] 10.1. Normative References
Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy,
A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel,
"Subscribing to YANG datastore push updates", draft-ietf-
netconf-yang-push-20 (work in progress), October 2018,
<https://datatracker.ietf.org/doc/
draft-ietf-netconf-yang-push/>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 15, line 9 skipping to change at line 654
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[W3C-20150203] [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
Hickson, I., "Server-Sent Events, World Wide Web E., and A. Tripathy, "Subscription to YANG Notifications",
Consortium CR CR-eventsource-20121211", February 2015, RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.w3.org/TR/2015/REC-eventsource-20150203/>. <https://www.rfc-editor.org/info/rfc8639>.
11.2. Informative References [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[I-D.draft-ietf-netconf-netconf-event-notifications] [W3C-20150203]
Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto., Hickson, I., "Server-Sent Events", W3C Recommendation, 3
Nilsen-Nygaard, E., and A. Tripathy, "NETCONF support for February 2015,
event notifications", May 2018, <https://www.w3.org/TR/2015/REC-eventsource-20150203/>.
<https://datatracker.ietf.org/doc/ Latest version available at <https://www.w3.org/TR/
draft-ietf-netconf-netconf-event-notifications/>. eventsource/>.
[I-D.draft-ietf-netconf-nmda-restconf] 10.2. Informative References
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "RESTCONF Extensions to Support the Network
Management Datastore Architecture", April 2018,
<https://datatracker.ietf.org/doc/
draft-ietf-netconf-nmda-restconf/>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
for Subscription to YANG Datastores", RFC 7923, for Subscription to YANG Datastores", RFC 7923,
DOI 10.17487/RFC7923, June 2016, DOI 10.17487/RFC7923, June 2016,
<https://www.rfc-editor.org/info/rfc7923>. <https://www.rfc-editor.org/info/rfc7923>.
skipping to change at page 16, line 11 skipping to change at line 706
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. [RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M.
Zhang, "A YANG Data Model for the Virtual Router Zhang, "A YANG Data Model for the Virtual Router
Redundancy Protocol (VRRP)", RFC 8347, Redundancy Protocol (VRRP)", RFC 8347,
DOI 10.17487/RFC8347, March 2018, DOI 10.17487/RFC8347, March 2018,
<https://www.rfc-editor.org/info/rfc8347>. <https://www.rfc-editor.org/info/rfc8347>.
[RFC8527] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "RESTCONF Extensions to Support the Network
Management Datastore Architecture", RFC 8527,
DOI 10.17487/RFC8527, March 2019,
<https://www.rfc-editor.org/info/rfc8527>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic Subscription to YANG Events
and Datastores over NETCONF", RFC 8640,
DOI 10.17487/RFC8640, September 2019,
<https://www.rfc-editor.org/info/rfc8640>.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", November 1999, Version 1.0", W3C Recommendation, 16 November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>. Latest
version available at <https://www.w3.org/TR/ xpath/>.
Appendix A. Examples Appendix A. Examples
This section is non-normative. To allow easy comparison, this This section is non-normative. To allow easy comparison, this
section mirrors the functional examples shown with NETCONF over XML section mirrors the functional examples shown with NETCONF over XML
within [I-D.draft-ietf-netconf-netconf-event-notifications]. In within [RFC8640]. In addition, HTTP/2 vs HTTP/1.1 headers are not
addition, HTTP2 vs HTTP1.1 headers are not shown as the contents of shown as the contents of the JSON encoded objects are identical
the JSON encoded objects are identical within. within.
The subscription URI values used in the examples in this section are The subscription URI values used in the examples in this section are
purely illustrative, and are not indicative of the expected usage purely illustrative, and are not indicative of the expected usage
which is described in Section 9. that is described in Section 9.
The DSCP values are only for example purposes and are all indicated The DSCP values are only for example purposes and are all indicated
in decimal since the encoding is JSON [RFC7951]. in decimal since the encoding is JSON [RFC7951].
A.1. Dynamic Subscriptions A.1. Dynamic Subscriptions
A.1.1. Establishing Dynamic Subscriptions A.1.1. Establishing Dynamic Subscriptions
The following figure shows two successful "establish-subscription" The following figure shows two successful "establish-subscription"
RPC requests as per RPC requests as per [RFC8639]. The first request is given a
[I-D.draft-ietf-netconf-subscribed-notifications]. The first request subscription identifier of 22, and the second, an identifier of 23.
is given a subscription identifier of 22, the second, an identifier
of 23.
+------------+ +-----------+ +------------+ +-----------+
| Subscriber | | Publisher | | Subscriber | | Publisher |
+------------+ +-----------+ +------------+ +-----------+
| | | |
|establish-subscription | |establish-subscription |
|------------------------------>| (a) |------------------------------>| (a)
| HTTP 200 OK, id#22, URI#1 | | HTTP 200 OK, id#22, URI#1 |
|<------------------------------| (b) |<------------------------------| (b)
|GET (URI#1) | |GET (URI#1) |
skipping to change at page 17, line 33 skipping to change at line 774
|GET (URI#2) | |GET (URI#2) |
|------------------------------>| |------------------------------>|
| | | |
| | | |
| notif-mesg (id#22)| | notif-mesg (id#22)|
|<------------------------------| |<------------------------------|
| HTTP 200 OK,notif-mesg (id#23)| | HTTP 200 OK,notif-mesg (id#23)|
|<------------------------------| |<------------------------------|
| | | |
Figure 2: Multiple subscriptions over RESTCONF/HTTP Figure 2: Multiple Subscriptions over RESTCONF/HTTP
To provide examples of the information being transported, example To provide examples of the information being transported, example
messages for interactions in Figure 2 are detailed below: messages for interactions in Figure 2 are detailed below:
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:establish-subscription /ietf-subscribed-notifications:establish-subscription
{ {
"ietf-subscribed-notifications:input": { "ietf-subscribed-notifications:input": {
"stream-xpath-filter": "/example-module:foo/", "stream-xpath-filter": "/example-module:foo/",
"stream": "NETCONF", "stream": "NETCONF",
"dscp": 10 "dscp": 10
} }
} }
Figure 3: establish-subscription request (a) Figure 3: "establish-subscription" Request (a)
As publisher was able to fully satisfy the request, the publisher As the publisher was able to fully satisfy the request, the publisher
sends the subscription identifier of the accepted subscription, and sends the subscription identifier of the accepted subscription and
the URI: the URI:
HTTP status code - 200 HTTP status code - 200
{ {
"id": 22, "id": 22,
"uri": "https://example.com/restconf/subscriptions/22" "uri": "https://example.com/restconf/subscriptions/22"
} }
Figure 4: establish-subscription success (b) Figure 4: "establish-subscription" Success (b)
Upon receipt of the successful response, the subscriber does a GET Upon receipt of the successful response, the subscriber does a GET to
the provided URI to start the flow of notification messages. When the provided URI to start the flow of notification messages. When
the publisher receives this, the subscription is moved to the active the publisher receives this, the subscription is moved to the active
state (c). state (c).
GET /restconf/subscriptions/22 GET /restconf/subscriptions/22
Figure 5: establish-subscription subsequent POST Figure 5: "establish-subscription" Subsequent POST
While not shown in Figure 2, if the publisher had not been able to While not shown in Figure 2, if the publisher had not been able to
fully satisfy the request, or subscriber has no authorization to fully satisfy the request, or the subscriber has no authorization to
establish the subscription, the publisher would have sent an RPC establish the subscription, the publisher would have sent an RPC
error response. For instance, if the "dscp" value of 10 asserted by error response. For instance, if the "dscp" value of 10 asserted by
the subscriber in Figure 3 proved unacceptable, the publisher may the subscriber in Figure 3 proved unacceptable, the publisher may
have returned: have returned:
HTTP status code - 400 HTTP status code - 400
{ "ietf-restconf:errors" : { { "ietf-restconf:errors" : {
"error" : [ "error" : [
{ {
"error-type": "application", "error-type": "application",
"error-tag": "invalid-value", "error-tag": "invalid-value",
"error-severity": "error", "error-severity": "error",
"error-app-tag": "error-app-tag":
"ietf-subscribed-notifications:dscp-unavailable" "ietf-subscribed-notifications:dscp-unavailable"
}
]
}
} }
]
}
}
Figure 6: an unsuccessful establish subscription Figure 6: An Unsuccessful "establish-subscription"
The subscriber can use this information in future attempts to The subscriber can use this information in future attempts to
establish a subscription. establish a subscription.
A.1.2. Modifying Dynamic Subscriptions A.1.2. Modifying Dynamic Subscriptions
An existing subscription may be modified. The following exchange An existing subscription may be modified. The following exchange
shows a negotiation of such a modification via several exchanges shows a negotiation of such a modification via several exchanges
between a subscriber and a publisher. This negotiation consists of a between a subscriber and a publisher. This negotiation consists of a
failed RPC modification request/response, followed by a successful failed RPC modification request/response followed by a successful
one. one.
+------------+ +-----------+ +------------+ +-----------+
| Subscriber | | Publisher | | Subscriber | | Publisher |
+------------+ +-----------+ +------------+ +-----------+
| | | |
| notification message (id#23)| | notification message (id#23)|
|<-----------------------------| |<-----------------------------|
| | | |
|modify-subscription (id#23) | |modify-subscription (id#23) |
skipping to change at page 19, line 37 skipping to change at line 870
| | | |
|modify-subscription (id#23) | |modify-subscription (id#23) |
|----------------------------->| |----------------------------->|
| HTTP 200 OK | | HTTP 200 OK |
|<-----------------------------| |<-----------------------------|
| | | |
| notif-mesg (id#23)| | notif-mesg (id#23)|
|<-----------------------------| |<-----------------------------|
| | | |
Figure 7: Interaction model for successful subscription modification Figure 7: Interaction Model for Successful Subscription Modification
If the subscription being modified in Figure 7 is a datastore If the subscription being modified in Figure 7 is a datastore
subscription as per [I-D.ietf-netconf-yang-push], the modification subscription as per [RFC8641], the modification request made in (d)
request made in (d) may look like that shown in Figure 8. As can be may look like that shown in Figure 8. As can be seen, the
seen, the modifications being attempted are the application of a new modifications being attempted are the application of a new XML Path
xpath filter as well as the setting of a new periodic time interval. Language (XPath) filter as well as the setting of a new periodic time
interval.
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:modify-subscription /ietf-subscribed-notifications:modify-subscription
{ {
"ietf-subscribed-notifications:input": { "ietf-subscribed-notifications:input": {
"id": 23, "id": 23,
"ietf-yang-push:datastore-xpath-filter": "ietf-yang-push:datastore-xpath-filter":
"/example-module:foo/example-module:bar", "/example-module:foo/example-module:bar",
"ietf-yang-push:periodic": { "ietf-yang-push:periodic": {
"ietf-yang-push:period": 500 "ietf-yang-push:period": 500
} }
} }
} }
Figure 8: Subscription modification request (c) Figure 8: Subscription Modification Request (c)
If the publisher can satisfy both changes, the publisher sends a If the publisher can satisfy both changes, the publisher sends a
positive result for the RPC. If the publisher cannot satisfy either positive result for the RPC. If the publisher cannot satisfy either
of the proposed changes, the publisher sends an RPC error response of the proposed changes, the publisher sends an RPC error response
(e). The following is an example RPC error response for (e) which (e). The following is an example RPC error response for (e) that
includes a hint. This hint is an alternative time period value which includes a hint. This hint is an alternative time period value that
might have resulted in a successful modification: might have resulted in a successful modification:
HTTP status code - 400 HTTP status code - 400
{ "ietf-restconf:errors" : { { "ietf-restconf:errors" : {
"error" : [ "error" : [
"error-type": "application", "error-type": "application",
"error-tag": "invalid-value", "error-tag": "invalid-value",
"error-severity": "error", "error-severity": "error",
"error-app-tag": "ietf-yang-push:period-unsupported", "error-app-tag": "ietf-yang-push:period-unsupported",
"error-info": { "error-info": {
"ietf-yang-push": "ietf-yang-push":
"modify-subscription-datastore-error-info": { "modify-subscription-datastore-error-info": {
"period-hint": 3000 "period-hint": 3000
}
}
]
} }
} }
]
}
}
Figure 9: Modify subscription failure with Hint (e) Figure 9: "modify-subscription" Failure with Hint (e)
A.1.3. Deleting Dynamic Subscriptions A.1.3. Deleting Dynamic Subscriptions
The following demonstrates deleting a subscription. This The following demonstrates deleting a subscription. This
subscription may have been to either a stream or a datastore. subscription may have been to either a stream or a datastore.
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:delete-subscription /ietf-subscribed-notifications:delete-subscription
{ {
"delete-subscription": { "delete-subscription": {
"id": "22" "id": "22"
} }
} }
Figure 10: Delete subscription Figure 10: "delete-subscription" Request
If the publisher can satisfy the request, the publisher replies with If the publisher can satisfy the request, the publisher replies with
success to the RPC request. success to the RPC request.
If the publisher cannot satisfy the request, the publisher sends an If the publisher cannot satisfy the request, the publisher sends an
error-rpc element indicating the modification didn't work. Figure 11 <rpc-error> element indicating the modification didn't work.
shows a valid response for existing valid subscription identifier, Figure 11 shows a valid response for an existing valid subscription
but that subscription identifier was created on a different transport identifier, but that subscription identifier was created on a
session: different transport session:
HTTP status code - 404 HTTP status code - 404
{ {
"ietf-restconf:errors" : { "ietf-restconf:errors" : {
"error" : [ "error" : [
"error-type": "application", "error-type": "application",
"error-tag": "invalid-value", "error-tag": "invalid-value",
"error-severity": "error", "error-severity": "error",
"error-app-tag": "error-app-tag":
"ietf-subscribed-notifications:no-such-subscription" "ietf-subscribed-notifications:no-such-subscription"
] ]
} }
} }
Figure 11: Unsuccessful delete subscription Figure 11: Unsuccessful "delete-subscription"
A.2. Subscription State Notifications A.2. Subscription State Notifications
A publisher will send subscription state notifications according to A publisher will send subscription state notifications according to
the definitions within the definitions within [RFC8639].
[I-D.draft-ietf-netconf-subscribed-notifications]).
A.2.1. subscription-modified A.2.1. "subscription-modified"
A "subscription-modified" encoded in JSON would look like: A "subscription-modified" encoded in JSON would look like:
{ {
"ietf-restconf:notification" : { "ietf-restconf:notification" : {
"eventTime": "2007-09-01T10:00:00Z", "eventTime": "2007-09-01T10:00:00Z",
"ietf-subscribed-notifications:subscription-modified": { "ietf-subscribed-notifications:subscription-modified": {
"id": 39, "id": 39,
"uri": "https://example.com/restconf/subscriptions/22" "uri": "https://example.com/restconf/subscriptions/22"
"stream-xpath-filter": "/example-module:foo", "stream-xpath-filter": "/example-module:foo",
"stream": { "stream": {
"ietf-netconf-subscribed-notifications" : "NETCONF" "ietf-netconf-subscribed-notifications" : "NETCONF"
} }
} }
} }
} }
Figure 12: subscription-modified subscription state notification Figure 12: "subscription-modified" Subscription State Notification
A.2.2. subscription-completed, subscription-resumed, and replay- A.2.2. "subscription-completed", "subscription-resumed", and "replay-
complete completed"
A "subscription-completed" would look like: A "subscription-completed" notification would look like:
{ {
"ietf-restconf:notification" : { "ietf-restconf:notification" : {
"eventTime": "2007-09-01T10:00:00Z", "eventTime": "2007-09-01T10:00:00Z",
"ietf-subscribed-notifications:subscription-completed": { "ietf-subscribed-notifications:subscription-completed": {
"id": 39, "id": 39,
} }
} }
} }
Figure 13: subscription-completed notification in JSON Figure 13: "subscription-completed" Notification in JSON
The "subscription-resumed" and "replay-complete" are virtually The "subscription-resumed" and "replay-complete" are virtually
identical, with "subscription-completed" simply being replaced by identical, with "subscription-completed" simply being replaced by
"subscription-resumed" and "replay-complete". "subscription-resumed" and "replay-complete".
A.2.3. subscription-terminated and subscription-suspended A.2.3. "subscription-terminated" and "subscription-suspended"
A "subscription-terminated" would look like: A "subscription-terminated" would look like:
{ {
"ietf-restconf:notification" : { "ietf-restconf:notification" : {
"eventTime": "2007-09-01T10:00:00Z", "eventTime": "2007-09-01T10:00:00Z",
"ietf-subscribed-notifications:subscription-terminated": { "ietf-subscribed-notifications:subscription-terminated": {
"id": 39, "id": 39,
"error-id": "suspension-timeout" "error-id": "suspension-timeout"
} }
} }
} }
Figure 14: subscription-terminated subscription state notification Figure 14: "subscription-terminated" Subscription State Notification
The "subscription-suspended" is virtually identical, with The "subscription-suspended" is virtually identical, with
"subscription-terminated" simply being replaced by "subscription- "subscription-terminated" simply being replaced by "subscription-
suspended". suspended".
A.3. Filter Example A.3. Filter Example
This section provides an example which illustrate the method of This section provides an example that illustrates the method of
filtering event record contents. The example is based on the YANG filtering event record contents. The example is based on the YANG
notification "vrrp-protocol-error-event" as defined per the ietf- notification "vrrp-protocol-error-event" as defined per the ietf-
vrrp.yang module within [RFC8347]. Event records based on this vrrp.yang module within [RFC8347]. Event records based on this
specification which are generated by the publisher might appear as: specification that are generated by the publisher might appear as:
data: { data: {
data: "ietf-restconf:notification" : { data: "ietf-restconf:notification" : {
data: "eventTime" : "2018-09-14T08:22:33.44Z", data: "eventTime" : "2018-09-14T08:22:33.44Z",
data: "ietf-vrrp:vrrp-protocol-error-event" : { data: "ietf-vrrp:vrrp-protocol-error-event" : {
data: "protocol-error-reason" : "checksum-error" data: "protocol-error-reason" : "checksum-error"
data: } data: }
data: } data: }
data: } data: }
Figure 15: RFC 8347 (VRRP) - Example Notification Figure 15: RFC 8347 (VRRP) - Example Notification
Suppose a subscriber wanted to establish a subscription which only Suppose a subscriber wanted to establish a subscription that only
passes instances of event records where there is a "checksum-error" passes instances of event records where there is a "checksum-error"
as part of a VRRP protocol event. Also assume the publisher places as part of a Virtual Router Redundancy Protocol (VRRP) protocol
such event records into the NETCONF stream. To get a continuous event. Also assume the publisher places such event records into the
series of matching event records, the subscriber might request the NETCONF stream. To get a continuous series of matching event
application of an XPath filter against the NETCONF stream. An records, the subscriber might request the application of an XPath
"establish-subscription" RPC to meet this objective might be: filter against the NETCONF stream. An "establish-subscription" RPC
to meet this objective might be:
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:establish-subscription /ietf-subscribed-notifications:establish-subscription
{ {
"ietf-subscribed-notifications:input": { "ietf-subscribed-notifications:input": {
"stream": "NETCONF", "stream": "NETCONF",
"stream-xpath-filter": "stream-xpath-filter":
"/ietf-vrrp:vrrp-protocol-error-event[ "/ietf-vrrp:vrrp-protocol-error-event[
protocol-error-reason='checksum-error']/", protocol-error-reason='checksum-error']/",
} }
} }
Figure 16: Establishing a subscription error reason via XPath Figure 16: Establishing a Subscription Error Reason via XPath
For more examples of XPath filters, see [XPATH]. For more examples of XPath filters, see [XPATH].
Suppose the "establish-subscription" in Figure 16 was accepted. And Suppose the "establish-subscription" in Figure 16 was accepted. And
suppose later a subscriber decided they wanted to broaden this suppose later a subscriber decided they wanted to broaden this
subscription cover to all VRRP protocol events (i.e., not just those subscription cover to all VRRP protocol events (i.e., not just those
with a "checksum error"). The subscriber might attempt to modify the with a "checksum error"). The subscriber might attempt to modify the
subscription in a way which replaces the XPath filter with a subtree subscription in a way that replaces the XPath filter with a subtree
filter which sends all VRRP protocol events to a subscriber. Such a filter that sends all VRRP protocol events to a subscriber. Such a
"modify-subscription" RPC might look like: "modify-subscription" RPC might look like:
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:modify-subscription /ietf-subscribed-notifications:modify-subscription
{ {
"ietf-subscribed-notifications:input": { "ietf-subscribed-notifications:input": {
"stream": "NETCONF", "stream": "NETCONF",
"stream-subtree-filter": { "stream-subtree-filter": {
"/ietf-vrrp:vrrp-protocol-error-event" : {} "/ietf-vrrp:vrrp-protocol-error-event" : {}
} }
} }
} }
Figure 17 Figure 17: Example "modify-subscription" RPC
For more examples of subtree filters, see [RFC6241], section 6.4.
Appendix B. Changes between revisions
(To be removed by RFC editor prior to publication)
v14 - v15
o Addressed review comments from Kent.
v13 - v14
o Addressed review comments from IESG.
v12 - v13
o Enhanced "error-tag" values based on SN review.
v11 - v12
o Added text in 3.2 for expected behavior when ietf-restconf-
monitoring.yang is also supported.
o Added section 2 to the reference to draft-ietf-netconf-nmda-
restconf.
o Replaced kill-subscription-error by delete-subscription-error in
section 3.3.
o Clarified vertical lines (a) and (b) in Figure 1 of section 3.4
o Section 3.4, 3rd bullet after Figure 1, replaced "must" with
"MUST".
o Modified text in section 3.4 regarding access to RPCs modify-
subscription, resync-subscription, delete-subscription and kill-
subscription.
o Section 4, first bullet for HTTP2: replaced dscp and priority with
weighting and weight.
o Section 6, added YANG tree diagram and fixed description of the
module.
o Section 7, fixed indentation of module description statement.
o Section 7, in YANG module changed year in copyright statement to
2019.
o Section 8, added text on how server protects access to the
subscription URI.
o Fixed outdated references and removed unused references.
o Fixed the instances of line too long.
o Fixed example in Figure 3.
v10 - v11
o Per Kent's request, added name attribute to artwork which need to
be extracted
v09 - v10
o Fixed typo for resync.
o Added text wrt RPC permissions and RESTCONF username.
v08 - v09
o Addressed comments received during WGLC.
v07 - v08
o Aligned with RESTCONF mechanism.
o YANG model: removed augment of subscription-started, added
restconf transport.
o Tweaked Appendix A.1 to match draft-ietf-netconf-netconf-event-
notifications-13.
o Added Appendix A.3 for filter example.
v06 - v07
o Removed configured subscriptions.
o Subscription identifier renamed to id.
v05 - v06
o JSON examples updated by Reshad.
v04 - v05
o Error mechanisms updated to match embedded RESTCONF mechanisms
o Restructured format and sections of document.
o Added a YANG data model for HTTP specific parameters.
o Mirrored the examples from the NETCONF transport draft to allow
easy comparison.
v03 - v04
o Draft not fully synched to new version of subscribed-notifications
yet.
o References updated
v02 - v03
o Event notification reframed to notification message.
o Tweaks to wording/capitalization/format.
v01 - v02
o Removed sections now redundant with
[I-D.draft-ietf-netconf-subscribed-notifications] and
[I-D.ietf-netconf-yang-push] such as: mechanisms for subscription
maintenance, terminology definitions, stream discovery.
o 3rd party subscriptions are out-of-scope.
o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions
o Timeframes for event tagging are self-defined.
o Clean-up of wording, references to terminology, section numbers.
v00 - v01
o Removed the ability for more than one subscription to go to a
single HTTP2 stream.
o Updated call flows. Extensively.
o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions For more examples of subtree filters, see [RFC6241], Section 6.4.
o HTTP is not used to determine that a receiver has gone silent and Acknowledgments
is not Receiving Event Notifications
o Many clean-ups of wording and terminology We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ambika Prasad Tripathy, Alberto
Gonzalez Prieto, Susan Hares, Tim Jenkins, Balazs Lengyel, Kent
Watsen, Michael Scharf, Guangying Zheng, Martin Bjorklund, Qin Wu,
and Robert Wilton.
Authors' Addresses Authors' Addresses
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Reshad Rahman Reshad Rahman
Cisco Systems Cisco Systems
Email: rrahman@cisco.com Email: rrahman@cisco.com
Einar Nilsen-Nygaard Einar Nilsen-Nygaard
Cisco Systems Cisco Systems
Email: einarnn@cisco.com Email: einarnn@cisco.com
skipping to change at page 28, line 15 skipping to change at line 1120
Cisco Systems Cisco Systems
Email: rrahman@cisco.com Email: rrahman@cisco.com
Einar Nilsen-Nygaard Einar Nilsen-Nygaard
Cisco Systems Cisco Systems
Email: einarnn@cisco.com Email: einarnn@cisco.com
Alexander Clemm Alexander Clemm
Huawei Futurewei
Email: ludwig@clemm.org Email: ludwig@clemm.org
Andy Bierman Andy Bierman
YumaWorks YumaWorks
Email: andy@yumaworks.com Email: andy@yumaworks.com
 End of changes. 145 change blocks. 
602 lines changed or deleted 488 lines changed or added

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