One document matched: draft-voit-netconf-restconf-notif-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-voit-netconf-restconf-notif-00"
ipr="trust200902">
<front>
<title abbrev="Restconf-Notif">Restconf and HTTP Transport for Event
Notifications</title>
<author fullname="Eric Voit" initials="E." surname="Voit">
<organization>Cisco Systems</organization>
<address>
<email>evoit@cisco.com</email>
</address>
</author>
<author fullname="Alexander Clemm" initials="A" surname="Clemm">
<organization>Cisco Systems</organization>
<address>
<email>alex@cisco.com</email>
</address>
</author>
<author fullname="Ambika Prasad Tripathy" initials="A" surname="Tripathy">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>ambtripa@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Einar Nilsen-Nygaard" initials="E"
surname="Nilsen-Nygaard">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>einarnn@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Alberto Gonzalez Prieto" initials="A"
surname="Gonzalez Prieto">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>albertgo@cisco.com</email>
<uri/>
</address>
</author>
<date day="15" month="June" year="2016"/>
<area>Operations & Management</area>
<workgroup>NETCONF</workgroup>
<keyword>Draft</keyword>
<abstract>
<t/>
<t>This document defines Event Notification YANG Subscription and Push
mechanisms for Restconf, HTTP, and HTTP2 transports.</t>
<t/>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Mechanisms to support Event subscription and push are defined in
<xref target="rfc5277bis"/>. Enhancements to <xref target="rfc5277bis"/>
which enable YANG Datastore subscription and push are defined in <xref
target="yang-push"/>. This document provides a transport specification
for these Restconf and HTTP. This has been driven by Requirements for
subscriptions to YANG datastores are defined in <xref
target="pub-sub-reqs"/>.</t>
<t>Beyond based transport bindings, there are benefits which can be
realized when transporting updates directly HTTP/2<xref
target="RFC7540"/> which cn be realized via an implementation of this
transport specification including:</t>
<t><list style="symbols">
<t>Subscription multiplexing over independent HTTP/2 streams</t>
<t>Stream prioritization and stream dependencies</t>
<t>Flow control on independent streams</t>
</list></t>
<t/>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>Configured Subscription: a Subscription installed via a configuration
interface which persissts across reboots.</t>
<t>Data Node: An instance of management information in a datastore.</t>
<t>Data Node Update: A data item containing the current value/property
of a Data Node at the time the Data Node Update was created.</t>
<t>Dynamic Subscription: a Subscription negotiated between Subscriber
and Publisher via create, establish, modify, and delete RPC control
plane signaling messages.</t>
<t>Event: an occurrence of something that may be of interest. (e.g., a
configuration change, a fault, a change in status, crossing a threshold,
status of a flow, or an external input to the system.)</t>
<t>Event Notification: a set of information intended for a Receiver
indicating that one or more Event(s) have occurred. Details of the
Event(s) may be included within.</t>
<t>Event Stream: a continuous, ordered set of Events grouped under an
explicit criteria.</t>
<t>Notification: the communication of an occurrence, perhaps triggered
by the occurrence of an Event.</t>
<t>Publisher: an entity responsible for streaming Event Notifications
per the terms of a Subscription.</t>
<t>Receiver: a target to which a Publisher pushes Event Notifications.
For Dynamic Subscriptions, the Receiver and Subscriber will often be the
same entity.</t>
<t/>
<t>Subscriber: an entity able to request and negotiate a contract for
the receipt of Event Notifications from a Publisher</t>
<t>Subscription: a contract between a Subscriber and a Publisher
stipulating which information the Receiver wishes to have pushed from
the Publisher without the need for further solicitation.</t>
<t/>
</section>
<section title="Solution">
<t>Event subscription is defined in <xref target="rfc5277bis"/>, YANG
Datastore subscription is defined in <xref target="yang-push"/>. This
section specifies transport mechanisms applicable to both.</t>
<section title="Mechanisms for Subscription Establishment and Maintenance">
<t>There are three models for Subscription establishment and
maintenance:</t>
<t><list style="numbers">
<t>Dynamic Subscription: Here the Subscriber and Receiver are the
same. A Subscription ends with a subscription-terminated
notification, or by a loss of transport connectivity.</t>
<t>Configured Subscription: Receiver(s) are specified on Publisher
in startup and running config. Subscription is not terminated
except via an operations interface. (Subscriptions may be
Suspended, with no Event Notifications sent however.)</t>
<t>Proxy Subscription: Subscriber and Receiver are different.
Subscription ends when a Subscription End-time is reached, or the
Publisher process is restarted.</t>
</list>The first two are described in this section. The third is
described in <xref target="app.ex-if"/>. This third option can be
moved into the body of this specification should the IETF community
desire. In theory, all three models may be intermixed in a single
deployment.</t>
<figure>
<artwork><![CDATA[ .---------------.
| Publisher |
'---------------'
^ ^ | ^
| | | |
.-----Restconf----' | | '-----Restconf----.
| .-----' '-HTTP-. |
V | V |
.-------------. .------------. .----------. .------------.
| Subscriber+ | | Operations | | Receiver | | Subscriber |
| Receiver | | /Config | '----------' '------------'
'-------------' '------------' ^ ^ ^
^ (out of scope) : : :
: ^ : :....Model 3....:
Model 1 :...Model 2...: (out of scope)]]></artwork>
</figure>
<section title="Dynamic YANG Subscription over RESTCONF">
<t>Dynamic Subscriptions are configured and manage Subscriptions via
signaling. This signaling is transported over <xref
target="restconf"/>. Once established, streaming Event Notifications
are then delivered via Restconf SSE.</t>
</section>
<section title="Configured Subscription over HTTP">
<t/>
<t>With a Configured Subscription, all information needed to
establish a secure relationship with that Receiver is configured on
the Publisher. With this information, the Publisher will establish a
secure transport connection with the Receiver and then begin pushing
the Event Notifications to the Receiver. Since Restconf might not
exist on the Receiver, it is not desirable to require that such
Event Notifications be pushed via Restconf. Nor is there value which
Restconf provides on top of HTTP. Therefore in place of Restconf, a
TLS secured HTTP Client connection must be established with an HTTP
Server located on the Receiver. Event Notifications will then be
sent via HTTP Post messages to the Receiver.</t>
<t>Post messages will be addressed to HTTP augmentation code on the
Receiver capable of accepting and responding to Event Notifications.
At least the initial Post message must include the URI for the
subscribed resource. This URI can be retained for operational
tracking and debugging use by the Receiver.</t>
<t>After successful receipt of an initial Event Notification for a
particular Subscription, the Reciever should reply back with an HTTP
status code of 201 (Created). Further successful receipts should
result in the return of code of 202 (Accepted). At any point,
receipt of any status codes from 300-510 with the exception of 408
(Request Timeout) should result in the movement of the Subscription
to the suspended state. A sequential series of multiple 408
exceptions should also drive the Subscription to a suspended
state.</t>
<t>Security on an HTTP client/Publisher can be strengthened by only
accepting Response code feedback for recently initiated HTTP
POSTs.</t>
<t>Figure 2 depicts this message flow.</t>
<figure>
<artwork><![CDATA[ +-----------+ +----------+
| Publisher | | Receiver |
+-----------+ +----------+
|<--------------TLS------------>|
| |
|HTTP POST (Sub ID, URI, data1) |
|------------------------------>|
| HTTP 201 (Created)|
|<------------------------------|
|HTTP POST (Sub ID, data2) |
|------------------------------>|
| HTTP 200 or 202 (Accepted)|
|<------------------------------|
| data3 |
|<----------------------------->| ]]></artwork>
</figure>
<t>If HTTP/2 transport is available to a Receiver, the Publisher
should also:</t>
<t><list style="symbols">
<t>point individual Event Notifications to a unique HTTP/2
stream for that Subscription,</t>
<t>take any subscription-priority and provision it into the
HTTP/2 stream priority, and</t>
<t>take any subscription-dependency and provision it into the
HTTP/2 stream dependency.</t>
</list></t>
</section>
</section>
<section title="Subscription Multiplexing">
<t>When pushed directly over HTTP/2, it is expected that the Event
Notifications from a single Subscription will be allocated a separate
HTTP/2 stream. This will enable multiplexing, and address issues of
Head-of-line blocking with different priority Subscriptions.</t>
<t>When pushed via Restconf over HTTP/2, different Subscriptions will
not be mapped to independent HTTP/2 streams. When Restconf specifies
this mapping, support may be appended on top of this
specification.</t>
<t>With or without independent queueing of multiplexed subscriptions,
it is possible that updates might be delivered in a different sequence
than generated. Reasons for this might include (but are not limited
to):</t>
<t><list style="symbols">
<t>replay of pushed updates</t>
<t>temporary loss of transport connectivity, with update buffering
and different dequeuing priorities per Subscription</t>
<t>population, marshalling and bundling of independent
Subscription Updates, and</t>
<t>parallel HTTP1.1 sessions</t>
</list>Therefore each Event Notification will include a microsecond
level timestamp to ensure that a Receiver understands the time when a
that update was generated. Use of this timestamp can give an
indication of the state of objects at a Publisher when state-entangled
information is received across different subscriptions. The use of the
latest Event Notification timestamp for a particular object update can
introduce errors. So when state-entangled updates have inconsistent
object values and temporally close timestamps, a Receiver might
consider performing a ‘get’ to validate the current state
of a Publisher.</t>
</section>
<section title="Push Data Stream and Transport Mapping">
<t>Transported updates will contain data for one or more Event
Notifications. Each transported Event Notification will contain
several parameters:</t>
<t><list style="symbols">
<t>A Subscription ID correlator</t>
<t>Event Notification(s) . (Note 1: These must be filtered per
access control rules to contain only data that the Subscriber is
authorized to see. Note 2: these Event Notifications might be Data
Node Update(s).)</t>
<t>A timestamp indication when the Event Notification was
generated on the Publisher.</t>
</list></t>
<section title="Subscription and Updates via Restconf">
<t>Subscribers can dynamically learn whether a RESTCONF server
supports various types of Event or Yang datastore subscription. This
is done by issuing an HTTP request OPTIONS, HEAD, or GET on the
stream. Some examples building upon the existing RESTCONF mechanisms
are below:</t>
<figure>
<artwork><![CDATA[GET /restconf/data/ietf-restconf-monitoring:restconf-state/
streams/stream=yang-push HTTP/1.1
Host: example.com
Accept: application/yang.data+xml ]]></artwork>
</figure>
<t>If the server supports it, it may respond</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/yang.api+xml
<stream xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">
<name>yang-push</name>
<description>Yang push stream</description>
<access>
<encoding>xml</encoding>
<location>https://example.com/streams/yang-push-xml
</location>
</access>
<access>
<encoding>json</encoding>
<location>https://example.com/streams/yang-push-json
</location>
</access>
</stream>
]]></artwork>
</figure>
<t>If the server does not support any form of subscription, it may
respond</t>
<figure>
<artwork><![CDATA[HTTP/1.1 404 Not Found
Date: Mon, 25 Apr 2012 11:10:30 GMT
Server: example-server
]]></artwork>
</figure>
<t>Subscribers can determine the URL to receive updates by sending
an HTTP GET request for the "location" leaf with the stream list
entry.The stream to use for may be selected from the Event Stream
list provided in the capabilities exchange. Note that different
encodings are supporting using different Event Stream locations. For
example, the Subscriber might send the following request:</t>
<figure>
<artwork><![CDATA[GET /restconf/data/ietf-restconf-monitoring:restconf-state/
streams/stream=yang-push/access=xml/location HTTP/1.1
Host: example.com
Accept: application/yang.data+xml
]]></artwork>
</figure>
<t>The publisher might send the following response:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/yang.api+xml
<location
xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">
https://example.com/streams/yang-push-xml
</location>
]]></artwork>
</figure>
<t>To subscribe and start receiving updates, the subscriber can then
send an HTTP GET request for the URL returned by the Publisher in
the request above. The accept header must be "text/event-stream".
The Publisher uses the Server Sent Events<xref
target="W3C-20121211"/> transport strategy to push filtered Event
Notifications from the Event stream,.</t>
<t>The publisher MUST support as query parameters for a GET method
on this resource all the parameters of a subscription. The only
exception is the encoding, which is embedded in the URI. An example
of this is:</t>
<figure>
<artwork><![CDATA[// subtree filter = /foo
// periodic updates, every 5 seconds
GET /mystreams/yang-push?subscription-id=my-sub&period=5&
xpath-filter=%2Fex:foo[starts-with("bar"."some"]
]]></artwork>
</figure>
<t>Should the publisher not support the requested subscription, it
may reply:</t>
<figure>
<artwork><![CDATA[HTTP/1.1 501 Not Implemented
Date: Mon, 23 Apr 2012 17:11:00 GMT
Server: example-server
Content-Type: application/yang.errors+xml
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>application</error-type>
<error-tag>operation-not-supported</error-tag>
<error-severity>error</error-severity>
<error-message>Xpath filters not supported</error-message>
<error-info>
<supported-subscription xmlns="urn:ietf:params:xml:ns:
netconf:datastore-push:1.0">
<subtree-filter/>
</supported-subscription>
</error-info>
</error>
</errors>
with an equivalent JSON encoding representation of:
HTTP/1.1 501 Not Implemented
Date: Mon, 23 Apr 2012 17:11:00 GMT
Server: example-server
Content-Type: application/yang.errors+json
{
"ietf-restconf:errors": {
"error": {
"error-type": "protocol",
"error-tag": "operation-not-supported",
"error-message": "Xpath filters not supported."
"error-info": {
"datastore-push:supported-subscription": {
"subtree-filter": [null]
}
}
}
}
}
]]></artwork>
</figure>
<t>The following is an example of a pushed Event Notification data
for the subscription above. It contains a subtree with root foo that
contains a leaf called bar:</t>
<figure>
<artwork><![CDATA[XML encoding representation:
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<subscription-id xmlns="urn:ietf:params:xml:ns:restconf:
datastore-push:1.0">
my-sub
</subscription-id>
<eventTime>2015-03-09T19:14:56Z</eventTime>
<datastore-contents xmlns="urn:ietf:params:xml:ns:restconf:
datastore-push:1.0">
<foo xmlns="http://example.com/yang-push/1.0">
<bar>some_string</bar>
</foo>
</datastore-contents>
</notification>
]]></artwork>
</figure>
<t>Or with the equivalent YANG over JSON encoding representation as
defined in<xref target="yang-json"/> :</t>
<figure>
<artwork><![CDATA[{
"ietf-restconf:notification": {
"datastore-push:subscription-id": "my-sub",
"eventTime": "2015-03-09T19:14:56Z",
"datastore-push:datastore-contents": {
"example-mod:foo": { "bar": "some_string" }
}
}
}
]]></artwork>
</figure>
<t>To modify a Subscription, the subscriber issues another GET
request on the provided URI using the same subscription-id as in the
original request. For example, to modify the update period to 10
seconds, the subscriber may send:</t>
<figure>
<artwork><![CDATA[GET /mystreams/yang-push?subscription-id=my-sub&period=10&
subtree-filter=%2Ffoo']]></artwork>
</figure>
<t>To delete a Subscription, the Subscriber issues a DELETE request
on the provided URI using the same subscription-id as in the
original request</t>
<figure>
<artwork><![CDATA[DELETE /mystreams/yang-push?subscription-id=my-sub]]></artwork>
</figure>
<t/>
</section>
<section title="Subscription and Updates directly via HTTP">
<t>For any version of HTTP, the basic encoding will look as below.
It consists of a JSON representation wrapped in an HTTP header.</t>
<figure>
<artwork><![CDATA[POST (IP+Port) HTTP/1.1
From: (Identifier for Network Element)
User-Agent: (CiscoYANGPubSub/1.0)
Content-Type: multipart/form-data
Content-Length: (determined runtime)
{
"ietf-yangpush:notification": {
"datastore-push:subscription-id": "my-sub",
"eventTime": "2015-03-09T19:14:56Z",
"datastore-push:datastore-contents": {
"foo": { "bar": "some_string" }
}
}
}
]]></artwork>
</figure>
<t/>
</section>
</section>
</section>
<section title="Security Considerations">
<t>Subscriptions could be used to intentionally or accidentally overload
resources of a Publisher. For this reason, it is important that the
Publisher has the ability to prioritize the establishment and push of
Event Notifications where there might be resource exhaust potential. In
addition, a server needs to be able to suspend existing Subscriptions
when needed. When this occurs, the subscription status must be updated
accordingly and the Receivers notified.</t>
<t>A Subscription could be used to attempt retrieve information for
which a Receiver has no authorized access. Therefore it is important
that data pushed via a Subscription is authorized equivalently with
regular data retrieval operations. Data being pushed to a Receiver needs
therefore to be filtered accordingly, just like if the data were being
retrieved on-demand. The Netconf Authorization Control Model <xref
target="RFC6536"/> applies even though the transport is not NETCONF.</t>
<t>One or more Publishers could be used to overwhelm a Receiver which
doesn’t even support Subscriptions. Therefore Event Notifications
for Configured Subscriptions MUST only be transmittable over Encrypted
transports. Clients which do not want pushed Event Notifications need
only terminate or refuse any transport sessions from the Publisher.</t>
<t>One or more Publishers could overwhelm a Receiver which is unable to
control or handle the volume of Event Notifications received. In
deployments where this might be a concern, transports supporting
per-subscription Flow Control and Prioritization (such as HTTP/2) should
be selected.</t>
<t>Another benefit is that a well-behaved Publisher implementation is
that it is difficult to a Publisher to perform a DoS attack on a
Receiver. DoS attack protection comes from:</t>
<t><list style="symbols">
<t>the requirement for trust of a TLS session before
publication,</t>
<t>the need for an HTTP transport augmentation on the Receiver,
and</t>
<t>that the Publication process is suspended when the Receiver
doesn’t respond.</t>
</list></t>
</section>
<section title="Acknowledgments">
<t>We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from: Andy Bierman, Sharon Chisholm, Yan
Gang, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, Hector
Trevino, Kent Watsen, and Guangying Zheng.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6520"?>
<?rfc include="reference.RFC.6536"?>
<?rfc include="reference.RFC.7540"?>
<reference anchor="restconf"
target="https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A Bierman" initials="Andy" surname="Bierman"/>
<author fullname="M Bjorklund" initials="Martin" surname="Bjorklund"/>
<author fullname="K Watsen" initials="Kent" surname="Watsen"/>
<date day="16" month="March" year="2016"/>
</front>
</reference>
<?rfc ?>
</references>
<references title="Informative References">
<reference anchor="yang-push"
target="https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/">
<front>
<title>Subscribing to YANG datastore push updates</title>
<author fullname="A Clemm" initials="Alexander" surname="Clemm">
<organization>Cisco</organization>
</author>
<author fullname="A Gonzalez Prieto" initials="Alberto"
surname="Gonzalez Prieto">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="E Voit" initials="Eric" surname="Voit">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="A Tripathy" initials="Ambika"
surname="Prasad Tripathy">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="E Nilsen-Nygaard" initials="Einar"
surname="Nilsen-Nygaard">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date day="23" month="February" year="2016"/>
</front>
</reference>
<reference anchor="rfc5277bis"
target="https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis/">
<front>
<title>NETCONF Event Notifications</title>
<author fullname="A Gonzalez Prieto" initials="Alberto"
surname="Gonzalez Prieto">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="A Clemm" initials="Alexander" surname="Clemm">
<organization>Cisco</organization>
</author>
<author fullname="E Voit" initials="Eric" surname="Voit">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="A Tripathy" initials="Ambika"
surname="Prasad Tripathy">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="E Nilsen-Nygaard" initials="Einar"
surname="Nilsen-Nygaard">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date day="21" month="March" year="2016"/>
</front>
</reference>
<reference anchor="pub-sub-reqs"
target="https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/">
<front>
<title>Subscribing to datastore push updates</title>
<author fullname="E Voit" initials="Eric " surname="Voit">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Alexander Clemm" initials="Alexander"
surname="Clemm">
<organization>Cisco</organization>
</author>
<author fullname="A Gonzalez Prieto" initials="Alberto"
surname="Gonzalez Prieto">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date day="3" month="February" year="2016"/>
</front>
</reference>
<reference anchor="yang-json"
target="https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/">
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author fullname="L. Lhotka" initials="Ladislav" surname="Lhotka">
<organization/>
</author>
<date day="9" month="March" year="2016"/>
</front>
</reference>
<reference anchor="W3C-20121211"
target="http://www.w3.org/TR/2012/CR-eventsource-20121211">
<front>
<title>Server-Sent Events, World Wide Web Consortium CR
CR-eventsource-20121211</title>
<author fullname="I Hickson">
<organization/>
</author>
<date month="December" year="2012"/>
</front>
</reference>
<reference anchor="call-home"
target="https://tools.ietf.org/html/draft-ietf-netconf-call-home-17">
<front>
<title>NETCONF Call Home and RESTCONF Call Home</title>
<author fullname="K Watsen" initials="K" surname="Watsen">
<organization/>
</author>
<date day="17" month="December" year="2015"/>
</front>
</reference>
</references>
<section anchor="app.ex-if"
title="Proxy YANG Subscription when the Subscriber and Receiver are different">
<t>The properties of Dynamic and Configured Subscriptions can be
combined to enable deployment models where the Subscriber and Receiver
are different. Such separation can be useful with some combination
of:</t>
<t><list style="symbols">
<t>An operator doesn’t want the subscription to be dependent
on the maintenance of transport level keep-alives. (Transport
independence provides different scalability characteristics.)</t>
<t>There is not a transport session binding, and a transient
Subscription needs to survive in an environment where there is
unreliable connectivity with the Receiver and/or Subscriber.</t>
<t>An operator wants the Publisher to include highly restrictive
capacity management and Subscription security mechanisms outside of
domain of existing operational or programmatic interfaces.</t>
</list>To build a Proxy Subscription, first the necessary information
must be signaled as part of the <establish-subscription>. Using
this set of Subscriber provided information; the same process described
within section 3 will be followed. There is one exception. When an HTTP
status code is 201 is received by the Publisher, it will inform the
Subscriber of Subscription establishment success via its Restconf
connection.</t>
<t/>
<t>After a successful establishment, if the Subscriber wishes to track
the state of Receiver subscriptions, it may choose to place a separate
on-change Subscription into the "Subscriptions" subtree of the YANG
Datastore on the Publisher.</t>
<t>Putting it all together, the message flow is:</t>
<figure>
<artwork><![CDATA[ +------------+ +-----------+ +----------+
| Subscriber | | Publisher | | Receiver |
+------------+ +-----------+ +----------+
| Restconf PUT: | |
| <establish-subscription>| |
|------------------------>| |
| | |
| |<-----------TLS------------>|
| | |
| |HTTP POST (Sub ID, data1, |
| |(stream ID, URI?)) |
| |--------------------------->|
| | HTTP 201 (Created)|
| |<---------------------------|
| Success: HTTP 204| |
|<------------------------| |
| |HTTP POST (Sub ID, data2) |
| |--------------------------->|
| | HTTP 200 or 202 (Accepted)|
| |<---------------------------|
| | data3 |
| |<-------------------------->|
| | |
]]></artwork>
</figure>
<t/>
</section>
<section title="End-to-End Deployment Guidance">
<t>Several technologies are expected to be seen within a deployment to
achieve security and ease-of-use requirements. These are not necessary
for an implementation of this specification, but will be useful to
consider when considering the operational context.</t>
<t/>
<section title="Call Home">
<t>Pub/Sub implementations should have the ability to transparently
incorporate lower layer technologies such as Call Home so that secure
TLS connections are always originated from the Publisher. There is a
Restconf Call home function in <xref target="call-home"/>. For
security reasons, this should be implemented when applicable.</t>
<t/>
</section>
<section title="TLS Heartbeat">
<t>Unlike NETCONF, HTTP sessions might not quickly allow a Subscriber
to recognize when the communication path has been lost from the
Publisher. To recognize this, it is possible for a Receiver (usually
the subscriber) to establish a TLS heartbeat <xref target="RFC6520"/>.
In the case where a TLS heartbeat is included, it should be sent just
from Receiver to Publisher. Loss of the heartbeat should result in the
Subscription being terminated with the Subscriber (even when the
Subscriber and Receiver are different). The Subscriber can then
attempt to re-establish the subscription if desired. If the
Subscription remains active on the Publisher, future receipt of
objects associated with that (or any other unknown) subscription ID
should result in a <delete-subscription> being returned to the
Publisher from the Receiver.</t>
<t/>
</section>
</section>
<section title="Issues being worked and resolved">
<t>(To be removed by RFC editor prior to publication)</t>
<section title="Unresolved Issues">
<t>RT1 - Integration specifics for Restconf capability discovery on
different types of Streams</t>
<t>RT2 - In what way to we position “Event notifications”
model in this document vs. current solution in Restconf.</t>
<t>RT3 - Do we include 3rd party signaled subscriptions within models
that need to be supported generically, or for a particular type of
transport.</t>
<t>RT6 - We need to define encodings of rfc5277bis notifications for
both Restconf and HTTP.</t>
<t>RT7 - HTTP native option doesn’t currently use SSE. But we
should evaluate moving to that as possible. It will make development
integration easier and more consistent.</t>
</section>
<section title="Agreement in principal ">
<t>RT4 - Need to add into document examples of 5277bis Event streams.
Document only includes yang-push examples at this point.</t>
<t/>
</section>
<section title="Resolved Issues">
<t/>
<t>RT5 - Doesn’t make sense to use Restconf for Configured
subscriptions. HTTP will be used.</t>
<t/>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:42:30 |