< draft-ietf-netconf-restconf-notif-05.txt   draft-ietf-netconf-restconf-notif-06.txt >
NETCONF E. Voit NETCONF E. Voit
Internet-Draft E. Nilsen-Nygaard Internet-Draft R. Rahman
Intended status: Standards Track Cisco Systems Intended status: Standards Track E. Nilsen-Nygaard
Expires: November 19, 2018 A. Clemm Expires: December 20, 2018 Cisco Systems
A. Clemm
Huawei Huawei
A. Bierman A. Bierman
YumaWorks YumaWorks
May 18, 2018 June 18, 2018
RESTCONF and HTTP Transport for Event Notifications RESTCONF and HTTP Transport for Event Notifications
draft-ietf-netconf-restconf-notif-05 draft-ietf-netconf-restconf-notif-06
Abstract Abstract
This document defines RESTCONF, HTTP2, and HTTP1.1 bindings for the This document defines RESTCONF, HTTP2, and HTTP1.1 bindings for the
transport of subscription requests and corresponding push updates. transport of subscription requests and corresponding push updates.
Being subscribed may be either publisher defined event streams or Being subscribed may be either publisher defined event streams or
nodes/subtrees of YANG Datastores. nodes/subtrees of YANG Datastores.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 November 19, 2018. This Internet-Draft will expire on December 20, 2018.
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 27 skipping to change at page 2, line 28
3.5. Call flow for HTTP1.1 . . . . . . . . . . . . . . . . . . 8 3.5. Call flow for HTTP1.1 . . . . . . . . . . . . . . . . . . 8
4. Configured Subscription . . . . . . . . . . . . . . . . . . . 10 4. Configured Subscription . . . . . . . . . . . . . . . . . . . 10
4.1. Transport Connectivity . . . . . . . . . . . . . . . . . 10 4.1. Transport Connectivity . . . . . . . . . . . . . . . . . 10
4.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 11
5. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 12 5. QoS Treatment . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Mandatory JSON and datastore support . . . . . . . . . . . . 12 6. Mandatory JSON and datastore support . . . . . . . . . . . . 12
7. Notification Messages . . . . . . . . . . . . . . . . . . . . 12 7. Notification Messages . . . . . . . . . . . . . . . . . . . . 12
8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. RESTCONF over GRPC . . . . . . . . . . . . . . . . . 19 Appendix A. RESTCONF over GRPC . . . . . . . . . . . . . . . . . 19
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 19
B.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 20 B.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 19
B.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 20 B.1.1. Establishing Dynamic Subscriptions . . . . . . . . . 19
B.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 22 B.1.2. Modifying Dynamic Subscriptions . . . . . . . . . . . 22
B.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 24 B.1.3. Deleting Dynamic Subscriptions . . . . . . . . . . . 23
B.2. Configured Subscriptions . . . . . . . . . . . . . . . . 25 B.2. Configured Subscriptions . . . . . . . . . . . . . . . . 24
B.2.1. Creating Configured Subscriptions . . . . . . . . . . 25 B.2.1. Creating Configured Subscriptions . . . . . . . . . . 25
B.2.2. Modifying Configured Subscriptions . . . . . . . . . 28 B.2.2. Modifying Configured Subscriptions . . . . . . . . . 27
B.2.3. Deleting Configured Subscriptions . . . . . . . . . . 30 B.2.3. Deleting Configured Subscriptions . . . . . . . . . . 29
B.3. Subscription State Notifications . . . . . . . . . . . . 31 B.3. Subscription State Notifications . . . . . . . . . . . . 30
B.3.1. subscription-started and subscription-modified . . . 31 B.3.1. subscription-started and subscription-modified . . . 30
B.3.2. subscription-completed, subscription-resumed, and B.3.2. subscription-completed, subscription-resumed, and
replay-complete . . . . . . . . . . . . . . . . . . . 32 replay-complete . . . . . . . . . . . . . . . . . . . 31
B.3.3. subscription-terminated and subscription-suspended . 32 B.3.3. subscription-terminated and subscription-suspended . 31
Appendix C. Changes between revisions . . . . . . . . . . . . . 33 Appendix C. Changes between revisions . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Mechanisms to support event subscription and push are defined in Mechanisms to support event subscription and push are defined in
[I-D.draft-ietf-netconf-subscribed-notifications]. Enhancements to [I-D.draft-ietf-netconf-subscribed-notifications]. Enhancements to
[I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG [I-D.draft-ietf-netconf-subscribed-notifications] which enable YANG
datastore subscription and push are defined in datastore subscription and push are defined in
[I-D.ietf-netconf-yang-push]. This document provides a transport [I-D.ietf-netconf-yang-push]. This document provides a transport
specification for these protocols over RESTCONF [RFC8040] and HTTP. specification for these protocols over RESTCONF [RFC8040] and HTTP.
Driving these requirements is [RFC7923]. Driving these requirements is [RFC7923].
skipping to change at page 3, line 52 skipping to change at page 3, line 52
accomplished in this way via a RESTCONF POST into RPCs defined within accomplished in this way via a RESTCONF POST into RPCs defined within
[I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4. YANG [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4. YANG
datastore subscription is accomplished via augmentations to datastore subscription is accomplished via augmentations to
[I-D.draft-ietf-netconf-subscribed-notifications] as described within [I-D.draft-ietf-netconf-subscribed-notifications] as described within
[I-D.ietf-netconf-yang-push] Section 4.4. [I-D.ietf-netconf-yang-push] Section 4.4.
Common across all HTTP based dynamic subscriptions is that a POST Common across all HTTP based dynamic subscriptions is that a POST
needs to be made against a specific URI on the Publisher. needs to be made against a specific URI on the Publisher.
Subscribers cannot pre-determine the URI against which a subscription Subscribers cannot pre-determine the URI against which a subscription
might exist on a publisher, as the URI will only exist after the might exist on a publisher, as the URI will only exist after the
"establish-subscription" has been accepted. There subscription URI "establish-subscription" has been accepted. The subscription URI
will be determined and sent as part of the response to the will be determined and sent as part of the response to the
"establish-subscription", and a subsequent POST to this URI will be "establish-subscription", and a subsequent POST to this URI will be
done in order to start the flow of notification messages back to the done in order to start the flow of notification messages back to the
subscriber. A subscription does not become ACTIVE as per subscriber. A subscription does not move to the active state as per
Section 2.4.1. of [I-D.draft-ietf-netconf-subscribed-notifications] Section 2.4.1. of [I-D.draft-ietf-netconf-subscribed-notifications]
until the POST is received. until the POST is received.
3.1. Transport Connectivity 3.1. Transport Connectivity
For a dynamic subscription, where an HTTP client session doesn't For a dynamic subscription, where an HTTP client session doesn't
already exist, a new client session is initiated from the subscriber. already exist, a new client session is initiated from the subscriber.
If the subscriber is unsure if HTTP2 is supported by the publisher, If the subscriber is unsure if HTTP2 is supported by the publisher,
HTTP1.1 will be used for initial messages, and these messages will HTTP1.1 will be used for initial messages, and these messages will
include an HTTP version upgrade request as per [RFC7230], include an HTTP version upgrade request as per [RFC7230],
skipping to change at page 10, line 25 skipping to change at page 10, line 25
exist on the receiver, it is not desirable to require that subscribed exist on the receiver, it is not desirable to require that subscribed
content be pushed with any dependency on RESTCONF. Therefore in content be pushed with any dependency on RESTCONF. Therefore in
place of RESTCONF, an HTTP2 Client connection must be established place of RESTCONF, an HTTP2 Client connection must be established
with an HTTP2 Server located on the receiver. Notification messages with an HTTP2 Server located on the receiver. Notification messages
will then be sent as part of an extended HTTP POST to the receiver. will then be sent as part of an extended HTTP POST to the receiver.
4.1. Transport Connectivity 4.1. Transport Connectivity
Configured subscriptions MUST only be connected over HTTP2 via a Configured subscriptions MUST only be connected over HTTP2 via a
client session initiated from the publisher. Following are the client session initiated from the publisher. Following are the
conditions which MUST be met before estabishing a new HTTP2 conditions which MUST be met before establishing a new HTTP2
connection with a receiver: connection with a receiver:
o a configured subscription has a receiver in the CONNECTING state o a configured subscription has a receiver in the connecting state
as described in [I-D.draft-ietf-netconf-subscribed-notifications], as described in [I-D.draft-ietf-netconf-subscribed-notifications],
section 2.5.1., section 2.5.1.,
o the transport configured for that subscription is HTTP2, o the transport configured for that subscription is HTTP2,
o there are state change notifications or notification messages o there are state change notifications or notification messages
pending for that receiver, and pending for that receiver, and
o no HTTP2 transport session exists to that receiver, o no HTTP2 transport session exists to that receiver,
skipping to change at page 10, line 50 skipping to change at page 10, line 50
transport session via RESTCONF call home [RFC8071], section 4.1 to transport session via RESTCONF call home [RFC8071], section 4.1 to
that receiver. HTTP2 only communications must be used as per that receiver. HTTP2 only communications must be used as per
[RFC7540], Section 3.3 when the HTTP session over TLS [RFC5246]. and [RFC7540], Section 3.3 when the HTTP session over TLS [RFC5246]. and
[RFC7540], Section 3.4 when transporting cleartext over TCP. Note [RFC7540], Section 3.4 when transporting cleartext over TCP. Note
that a subscriber SHOULD establish over TLS in order to secure the that a subscriber SHOULD establish over TLS in order to secure the
content in transit. content in transit.
If the RESTCONF call home fails because the publisher receives If the RESTCONF call home fails because the publisher receives
receiver credentials which are subsequently declined per [RFC8071], receiver credentials which are subsequently declined per [RFC8071],
Section 4.1, step S5 authentication, then that receiver MUST be Section 4.1, step S5 authentication, then that receiver MUST be
placed into the TIMEOUT state. placed into the timeout state.
If the call home fails to establish for any other reason, the If the call home fails to establish for any other reason, the
publisher MUST NOT progress the receiver to the ACTIVE state. publisher MUST NOT progress the receiver to the active state.
Additionally, the publisher SHOULD place the receiver into the Additionally, the publisher SHOULD place the receiver into the
TIMEOUT state after a predetermined number of either failed call home timeout state after a predetermined number of either failed call home
attempts or remote transport session termination by the receiver. attempts or remote transport session termination by the receiver.
4.2. Call Flow 4.2. Call Flow
With HTTP2 connectivity established, a POST of each new With HTTP2 connectivity established, a POST of each new
"subscription-started" state change notification messages will be "subscription-started" state change notification messages will be
addressed to HTTP augmentation code on the receiver capable of addressed to HTTP augmentation code on the receiver capable of
accepting and acknowleding to subscription state change accepting and acknowledging to subscription state change
notifications. Until the "HTTP 200 OK" at point (c) of Figure 3 for notifications. Until the "HTTP 200 OK" at point (c) of Figure 3 for
each the "subscription-started" state change notification, a each the "subscription-started" state change notification, a
publisher MUST NOT progress the receiver to the ACTIVE state. In publisher MUST NOT progress the receiver to the active state. In
other words, is at point (c) which indicates that the receiver is other words, is at point (c) which indicates that the receiver is
ready for the delivery of subscribed content. At this point a ready for the delivery of subscribed content. At this point a
notification-messages including subscribed content may be placed onto notification-messages including subscribed content may be placed onto
an HTTP2 stream for that subscription. an HTTP2 stream for that subscription.
+------------+ +------------+ +------------+ +------------+
| Receiver | | Publisher | | Receiver | | Publisher |
|HTTP2 Stream| |HTTP2 Stream| |HTTP2 Stream| |HTTP2 Stream|
| (a) (b) | | (a) (b) | | (a) (b) | | (a) (b) |
+------------+ +------------+ +------------+ +------------+
skipping to change at page 13, line 10 skipping to change at page 13, line 10
The YANG model defined in Section 9 has one leaf augmented into four The YANG model defined in Section 9 has one leaf augmented into four
places of [I-D.draft-ietf-netconf-subscribed-notifications], plus two places of [I-D.draft-ietf-netconf-subscribed-notifications], plus two
identities. As the resulting full tree is large, it will only be identities. As the resulting full tree is large, it will only be
inserted at later stages of this document. inserted at later stages of this document.
9. YANG module 9. YANG module
This module references This module references
[I-D.draft-ietf-netconf-subscribed-notifications]. [I-D.draft-ietf-netconf-subscribed-notifications].
<CODE BEGINS> file "ietf-http-subscribed-notifications@2018-05-01.yang" <CODE BEGINS> file "ietf-http-subscribed-notifications@2018-06-11.yang"
module ietf-http-subscribed-notifications { module ietf-http-subscribed-notifications {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-http-subscribed-notifications"; "urn:ietf:params:xml:ns:yang:ietf-http-subscribed-notifications";
prefix hsn; prefix hsn;
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
} }
import ietf-yang-types { import ietf-inet-types {
prefix yang; prefix inet;
} }
organization "IETF NETCONF (Network Configuration) Working Group"; organization "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http:/tools.ietf.org/wg/netconf/> "WG Web: <http:/tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Editor: Eric Voit Editor: Eric Voit
<mailto:evoit@cisco.com> <mailto:evoit@cisco.com>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:ludwig@clemm.org> <mailto:ludwig@clemm.org>
Editor: Einar Nilsen-Nygaard Editor: Reshad Rahman
<mailto:einarnn@cisco.com>"; <mailto:rrahman@cisco.com>";
description description
"Defines HTTP variants as a supported transports for subscribed "Defines HTTP variants as a supported transports for subscribed
event notifications. event notifications.
Copyright (c) 2018 IETF Trust and the persons identified as authors Copyright (c) 2018 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision 2018-05-01 { revision 2018-06-11 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: RESTCONF and HTTP Transport for Event Notifications"; "RFC XXXX: RESTCONF and HTTP Transport for Event Notifications";
} }
identity http2 { identity http2 {
base sn:transport; base sn:transport;
base sn:inline-address; base sn:inline-address;
base sn:configurable-encoding; base sn:configurable-encoding;
description description
"HTTP2 is used a transport for notification messages and state "HTTP2 is used a transport for notification messages and state
change notifications."; change notifications.";
} }
identity http1.1 { identity http1.1 {
base sn:transport; base sn:transport;
base sn:inline-address; base sn:inline-address;
base sn:configurable-encoding; base sn:configurable-encoding;
description description
"HTTP1.1 is used a transport for notification messages and state "HTTP1.1 is used a transport for notification messages and state
change notifications."; change notifications.";
} }
grouping uri { grouping uri {
description description
"Provides a reusable description of a URI."; "Provides a reusable description of a URI.";
leaf uri { leaf uri {
type inet:uri;
config false; config false;
type yang:uri;
description description
"Location of a subscription specific URI on the publisher."; "Location of a subscription specific URI on the publisher.";
} }
} }
augment "/sn:establish-subscription/sn:output" { augment "/sn:establish-subscription/sn:output" {
description description
"This augmentation allows HTTP specific parameters for a "This augmentation allows HTTP specific parameters for a
response to a publisher's subscription request."; response to a publisher's subscription request.";
uses uri; uses uri;
} }
augment "/sn:subscriptions/sn:subscription/sn:target" { augment "/sn:subscriptions/sn:subscription" {
description description
"This augmentation allows HTTP specific parameters to be "This augmentation allows HTTP specific parameters to be
exposed for a subscription."; exposed for a subscription.";
uses uri; uses uri;
} }
augment "/sn:subscription-started/sn:target" { augment "/sn:subscription-started" {
description description
"This augmentation allows HTTP specific parameters to be included "This augmentation allows HTTP specific parameters to be included
part of the notification that a subscription has started."; part of the notification that a subscription has started.";
uses uri; uses uri;
} }
augment "/sn:subscription-modified/sn:target" { augment "/sn:subscription-modified" {
description description
"This augmentation allows HTTP specific parameters to be included "This augmentation allows HTTP specific parameters to be included
part of the notification that a subscription has been modified."; part of the notification that a subscription has been modified.";
uses uri; uses uri;
} }
/* need to add a constraint that HTTP1.1 not allowed for
configured subscriptions - needs the right syntax below...
augment "sn:subscriptions/sn:subscription/sn:protocol" {
when '../sn:configured-subscription-state'
must ' protocol <> "http1.1"' {
error-message "HTTP1.1 not used for configured subscriptions";
}
}
*/
} }
<CODE ENDS> <CODE ENDS>
10. IANA Considerations 10. IANA Considerations
This document registers the following namespace URI in the "IETF XML This document registers the following namespace URI in the "IETF XML
Registry" [RFC3688]: Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-http-subscribed-notifications URI: urn:ietf:params:xml:ns:yang:ietf-http-subscribed-notifications
Registrant Contact: The IESG. Registrant Contact: The IESG.
skipping to change at page 20, line 31 skipping to change at page 20, line 21
|establish-subscription | |establish-subscription |
|------------------------------>| (a) |------------------------------>| (a)
| HTTP 200 OK, id#22, URI#1 | | HTTP 200 OK, id#22, URI#1 |
|<------------------------------| (b) |<------------------------------| (b)
|POST (URI#1) | |POST (URI#1) |
|------------------------------>| (c) |------------------------------>| (c)
| HTTP 200 OK,notif-mesg (id#22)| | HTTP 200 OK,notif-mesg (id#22)|
|<------------------------------| |<------------------------------|
| | | |
| | | |
|stablish-subscription | |establish-subscription |
|------------------------------>| |------------------------------>|
| HTTP 200 OK, id#23, URI#2| | HTTP 200 OK, id#23, URI#2|
|<------------------------------| |<------------------------------|
|POST (URI#2) | |POST (URI#2) |
|------------------------------>| |------------------------------>|
| | | |
| | | |
| notif-mesg (id#22)| | notif-mesg (id#22)|
|<------------------------------| |<------------------------------|
| HTTP 200 OK,notif-mesg (id#23)| | HTTP 200 OK,notif-mesg (id#23)|
skipping to change at page 21, line 8 skipping to change at page 20, line 43
| | | |
Figure 4: Multiple subscriptions over RESTCONF/HTTP Figure 4: 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 4 are detailed below: messages for interactions in Figure 4 are detailed below:
POST /restconf/operations/subscriptions:establish-subscription POST /restconf/operations/subscriptions:establish-subscription
{ {
"establish-subscription": { "ietf-subscribed-notifications:input": {
"stream": { "stream": "NETCONF",
"ietf-netconf-subscribed-notifications" : "NETCONF"
},
"stream-xpath-filter": "/ex:foo/", "stream-xpath-filter": "/ex:foo/",
"dscp": "10" "dscp": "10"
} }
} }
Figure 5: establish-subscription request (a) Figure 5: establish-subscription request (a)
As publisher was able to fully satisfy the request, the publisher As 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:
skipping to change at page 21, line 34 skipping to change at page 21, line 20
{ {
"identifier": "22", "identifier": "22",
"uri": "/subscriptions/22" "uri": "/subscriptions/22"
} }
Figure 6: establish-subscription success (b) Figure 6: establish-subscription success (b)
Upon receipt of the successful response, the subscriber POSTs to the Upon receipt of the successful response, the subscriber POSTs 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 becomes ACTIVE (c). publisher receives this, the subscription is moved to the active
state (c).
POST /restconf/operations/subscriptions/22 POST /restconf/operations/subscriptions/22
Figure 7: establish-subscription subsequent POST Figure 7: establish-subscription subsequent POST
While not shown in Figure 4, if the publisher had not been able to While not shown in Figure 4, if the publisher had not been able to
fully satisfy the request, or subscriber has no authorization to fully satisfy the request, or 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 5 proved unacceptable, the publisher may the subscriber in Figure 5 proved unacceptable, the publisher may
skipping to change at page 23, line 37 skipping to change at page 23, line 8
If the subscription being modified in Figure 9 is a datastore If the subscription being modified in Figure 9 is a datastore
subscription as per [I-D.ietf-netconf-yang-push], the modification subscription as per [I-D.ietf-netconf-yang-push], the modification
request made in (d) may look like that shown in Figure 10. As can be request made in (d) may look like that shown in Figure 10. As can be
seen, the modifications being attempted are the application of a new seen, the modifications being attempted are the application of a new
xpath filter as well as the setting of a new periodic time interval. xpath filter as well as the setting of a new periodic time interval.
POST /restconf/operations/subscriptions:modify-subscription POST /restconf/operations/subscriptions:modify-subscription
{ {
"modify-subscription": { "ietf-subscribed-notifications:input": {
"identifier": "23", "identifier": "23",
{ "ietf-yang-push:datastore-xpath-filter":
"ietf-yang-push": "datastore-xpath-filter":
"/interfaces-state/interface/oper-status" "/interfaces-state/interface/oper-status"
}, "ietf-yang-push:periodic": {
{ "ietf-yang-push:period": "500"
"ietf-yang-push": "periodic": "500" }
}
} }
} }
Figure 10: Subscription modification request (c) Figure 10: 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) which
includes a hint. This hint is an alternative time period value which includes a hint. This hint is an alternative time period value which
might have resulted in a successful modification: might have resulted in a successful modification:
HTTP status code - 406 HTTP status code - 406
{ "ietf-restconf:errors" : { { "ietf-restconf:errors" : {
"error" : [ "error" : [
"error-type": "application", "error-type": "application",
"error-tag": "operation-failed", "error-tag": "operation-failed",
"error-severity": "error", "error-severity": "error",
"error-app-tag": { "error-app-tag": "ietf-yang-push:period-unsupported",
"ietf-yang-push": "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"
} }
} }
] ]
} }
} }
skipping to change at page 33, line 9 skipping to change at page 32, line 9
Figure 22: subscription-terminated subscription state notification Figure 22: 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".
Appendix C. Changes between revisions Appendix C. Changes between revisions
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
v05 - v06
o JSON examples updated by Reshad.
v04 - v05 v04 - v05
o Error mechanisms updated to match embedded RESTCONF mechanisms o Error mechanisms updated to match embedded RESTCONF mechanisms
o Restructured format and sections of document. o Restructured format and sections of document.
o Added a YANG data model for HTTP specific parameters. o Added a YANG data model for HTTP specific parameters.
o Mirrored the examples from the NETCONF transport draft to allow o Mirrored the examples from the NETCONF transport draft to allow
easy comparison. easy comparison.
skipping to change at page 33, line 49 skipping to change at page 33, line 4
o 3rd party subscriptions are out-of-scope. o 3rd party subscriptions are out-of-scope.
o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions
o Timeframes for event tagging are self-defined. o Timeframes for event tagging are self-defined.
o Clean-up of wording, references to terminology, section numbers. o Clean-up of wording, references to terminology, section numbers.
v00 - v01 v00 - v01
o Removed the ability for more than one subscription to go to a o Removed the ability for more than one subscription to go to a
single HTTP2 stream. single HTTP2 stream.
o Updated call flows. Extensively. o Updated call flows. Extensively.
o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions o SSE only used with RESTCONF and HTTP1.1 dynamic subscriptions
o HTTP is not used to determine that a receiver has gone silent and o HTTP is not used to determine that a receiver has gone silent and
is not Receiving Event Notifications is not Receiving Event Notifications
o Many clean-ups of wording and terminology o Many clean-ups of wording and terminology
Authors' Addresses Authors' Addresses
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Reshad Rahman
Cisco Systems
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 Huawei
Email: ludwig@clemm.org Email: ludwig@clemm.org
 End of changes. 42 change blocks. 
73 lines changed or deleted 65 lines changed or added

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