draft-ietf-netconf-restconf-notif-09.txt   draft-ietf-netconf-restconf-notif-10.txt 
NETCONF E. Voit NETCONF E. Voit
Internet-Draft R. Rahman Internet-Draft R. Rahman
Intended status: Standards Track E. Nilsen-Nygaard Intended status: Standards Track E. Nilsen-Nygaard
Expires: April 22, 2019 Cisco Systems Expires: May 8, 2019 Cisco Systems
A. Clemm A. Clemm
Huawei Huawei
A. Bierman A. Bierman
YumaWorks YumaWorks
October 19, 2018 November 4, 2018
Dynamic subscription to YANG Events and Datastores over RESTCONF Dynamic subscription to YANG Events and Datastores over RESTCONF
draft-ietf-netconf-restconf-notif-09 draft-ietf-netconf-restconf-notif-10
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2019. This Internet-Draft will expire on May 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3 3. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . . . 3
3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4 3.1. Transport Connectivity . . . . . . . . . . . . . . . . . 4
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4 3.3. RESTCONF RPCs and HTTP Status Codes . . . . . . . . . . . 4
3.4. Call Flow for Server-Sent Events (SSE) . . . . . . . . . 6 3.4. Call Flow for Server-Sent Events (SSE) . . . . . . . . . 6
4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 8 4. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Notification Messages . . . . . . . . . . . . . . . . . . . . 8 5. Notification Messages . . . . . . . . . . . . . . . . . . . . 8
6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 14 A.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 14
A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 14 A.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 14
A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 17 A.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 17
A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 18 A.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 18
A.2. Subscription State Notifications . . . . . . . . . . . . 19 A.2. Subscription State Notifications . . . . . . . . . . . . 19
A.2.1. subscription-modified . . . . . . . . . . . . . . . . 19 A.2.1. subscription-modified . . . . . . . . . . . . . . . . 19
A.2.2. subscription-completed, subscription-resumed, and A.2.2. subscription-completed, subscription-resumed, and
replay-complete . . . . . . . . . . . . . . . . . . . 20 replay-complete . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 5, line 27 skipping to change at page 5, line 27
Appendix A.1, for datastore subscriptions. The tag to use depends Appendix A.1, for datastore subscriptions. The tag to use depends
on the RPC for which the error occurred. Viable errors for on the RPC for which the error occurred. Viable errors for
different RPCs are as follows: different RPCs are as follows:
RPC select an identity with a base RPC select an identity with a base
---------------------- ------------------------------ ---------------------- ------------------------------
establish-subscription establish-subscription-error establish-subscription establish-subscription-error
modify-subscription modify-subscription-error modify-subscription modify-subscription-error
delete-subscription delete-subscription-error delete-subscription delete-subscription-error
kill-subscription kill-subscription-error kill-subscription kill-subscription-error
resynch-subscription resynch-subscription-error resync-subscription resync-subscription-error
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 as valid encoding would be "ietf-subscribed- example of such as 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 case of error responses to an "establish-subscription" or "modify-
subscription" request there is the option of including an "error- subscription" request there is the option of including an "error-
info" node. This node may contain hints for parameter settings that info" node. This node may contain hints for parameter settings that
might lead to successful RPC requests in the future. Following are might lead to successful RPC requests in the future. Following are
skipping to change at page 6, line 21 skipping to change at page 6, line 21
---------------------- ------------------------------------ ---------------------- ------------------------------------
target: event stream modify-subscription-stream-error-info target: event stream modify-subscription-stream-error-info
target: datastore modify-subscription-datastore-error-info target: datastore modify-subscription-datastore-error-info
The yang-data included within "error-info" SHOULD NOT include the The yang-data included within "error-info" SHOULD NOT include the
optional leaf "error-reason", as such a leaf would be redundant optional leaf "error-reason", as such a leaf would be redundant
with information that is already placed within the with information that is already placed within the
"error-app-tag". "error-app-tag".
In case of an rpc error as a result of a "delete-subscription", a In case of an rpc error as a result of a "delete-subscription", a
"kill-subscription", or a "resynch-subscription" request, no "kill-subscription", or a "resync-subscription" request, no
"error-info" needs to be included, as the "subscription-id" is "error-info" needs to be included, as the "subscription-id" is
the only RPC input parameter and no hints regarding this RPC input the only RPC input parameter and no hints regarding this RPC input
parameters need to be provided. 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 (SSE) 3.4. Call Flow for Server-Sent Events (SSE)
skipping to change at page 8, line 5 skipping to change at page 8, line 5
o Subscription RPCs MUST NOT use the connection currently providing o 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 o 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 the new terms of the subscription have been know exactly when the new terms of the subscription have been
applied to the notification messages. See arrow (c). applied to the notification messages. See arrow (c).
o RPCs modify-subscription, resync-subscription and delete-
subscription can only be done by the same RESTCONF username
[RFC8040] who did the establish-subscription, or by a RESTCONF
username with the required administrative permissions. The latter
also has access to the kill-subscription RPC.
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 o Receipt of a "delete-subscription" or a "kill-subscription" RPC
for that subscription. for that subscription.
o Loss of TLS heartbeat o 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 [I-D.draft-ietf-netconf-subscribed-notifications] Section 1.3
skipping to change at page 22, line 43 skipping to change at page 22, line 43
} }
Figure 17 Figure 17
For more examples of subtree filters, see [RFC6241], section 6.4. For more examples of subtree filters, see [RFC6241], section 6.4.
Appendix B. Changes between revisions Appendix B. Changes between revisions
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
v09 - v10
o Fixed typo for resync.
o Added text wrt RPC permissions and RESTCONF username.
v08 - v09 v08 - v09
o Addressed comments received during WGLC. o Addressed comments received during WGLC.
v07 - v08 v07 - v08
o Aligned with RESTCONF mechanism. o Aligned with RESTCONF mechanism.
o YANG model: removed augment of subscription-started, added o YANG model: removed augment of subscription-started, added
restconf transport. restconf transport.
 End of changes. 10 change blocks. 
9 lines changed or deleted 21 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/