draft-ietf-netconf-restconf-notif-14.txt   draft-ietf-netconf-restconf-notif-15.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: December 12, 2019 Cisco Systems Expires: December 13, 2019 Cisco Systems
A. Clemm A. Clemm
Huawei Huawei
A. Bierman A. Bierman
YumaWorks YumaWorks
June 10, 2019 June 11, 2019
Dynamic subscription to YANG Events and Datastores over RESTCONF Dynamic subscription to YANG Events and Datastores over RESTCONF
draft-ietf-netconf-restconf-notif-14 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 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 December 12, 2019. This Internet-Draft will expire on December 13, 2019.
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
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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 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 (multiple HTTP2 streams can be carried connection or an HTTP2 stream (if HTTP2 is used, multiple HTTP2
in one TCP connection). Requests to streams can be carried in one TCP connection). Requests to
[I-D.draft-ietf-netconf-subscribed-notifications] or [I-D.draft-ietf-netconf-subscribed-notifications] or
[I-D.ietf-netconf-yang-push] augmented RPCs are sent on a connection [I-D.ietf-netconf-yang-push] augmented RPCs are sent on a connection
indicated by (a). A successful "establish-subscription" will result indicated by (a). A successful "establish-subscription" will result
in an RPC response returned with both a subscription identifier which in an RPC response returned with both a subscription identifier which
uniquely identifies a subscription, as well as a URI which uniquely uniquely identifies a subscription, as well as a URI which uniquely
identifies the location of subscription on the publisher (b). This identifies the location of subscription on the publisher (b). This
URI is defined via the "uri" leaf 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 which are sent in SSE [W3C-20150203] as
a response to the GET. There can not be 2 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 [RFC8040] Section 6.4, 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 |
| | | | | | | |
skipping to change at page 9, line 32 skipping to change at page 9, line 32
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
4. QoS Treatment 4. QoS Treatment
Qos treatment for event streams is described in Qos treatment for event streams is described in
[I-D.draft-ietf-netconf-subscribed-notifications] Section 2.3. In [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.3. In
addition, where HTTP2 transport is available to a notification addition, if HTTP2 is used, the publisher MUST:
message queued for transport to a receiver, the publisher MUST:
o take the "weighting" leaf node in o take the "weighting" leaf node in
[I-D.draft-ietf-netconf-subscribed-notifications], and copy it [I-D.draft-ietf-netconf-subscribed-notifications], and copy it
into the HTTP2 stream weight, [RFC7540] section 5.3, and into the HTTP2 stream weight, [RFC7540] section 5.3, and
o take any existing subscription "dependency", as specified by the o take any existing subscription "dependency", as specified by the
"dependency" leaf node in "dependency" leaf node in
[I-D.draft-ietf-netconf-subscribed-notifications], and use the [I-D.draft-ietf-netconf-subscribed-notifications], and use the
HTTP2 stream for the parent subscription as the HTTP2 stream HTTP2 stream for the parent subscription as the HTTP2 stream
dependency, [RFC7540] section 5.3.1, 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. o set the exclusive flag, [RFC7540] section 5.3.1, to 0.
For dynamic subscriptions with the same DSCP value to a specific For dynamic subscriptions with the same DSCP value to a specific
publisher, it is recommended that the subscriber sends all URI GET publisher, it is recommended that the subscriber sends all URI GET
requests on a common HTTP2 session. Conversely, a subscriber can not requests on a common HTTP2 session (if HTTP2 is used). Conversely, a
use a common HTTP2 session for subscriptions with different DSCP subscriber can not use a common HTTP2 session for subscriptions with
values. 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 model defined in Section 7 has one leaf augmented into three
places of [I-D.draft-ietf-netconf-subscribed-notifications]. places of [I-D.draft-ietf-netconf-subscribed-notifications].
skipping to change at page 24, line 47 skipping to change at page 24, line 47
} }
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)
v13 - v14 v14 - v15
o Addressed review comments from Kent.
v13 - v14
o Addressed review comments from IESG. o Addressed review comments from IESG.
v12 - v13 v12 - v13
o Enhanced "error-tag" values based on SN review. o Enhanced "error-tag" values based on SN review.
v11 - v12 v11 - v12
o Added text in 3.2 for expected behavior when ietf-restconf- o Added text in 3.2 for expected behavior when ietf-restconf-
monitoring.yang is also supported. monitoring.yang is also supported.
o Added section 2 to the reference to draft-ietf-netconf-nmda- o Added section 2 to the reference to draft-ietf-netconf-nmda-
restconf. restconf.
 End of changes. 11 change blocks. 
13 lines changed or deleted 16 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/