idnits 2.17.1
draft-ietf-netconf-netconf-event-notifications-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
== There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (February 22, 2018) is 2246 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-26) exists of
draft-ietf-netconf-subscribed-notifications-10
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF A. Gonzalez Prieto
3 Internet-Draft VMware
4 Intended status: Standards Track E. Voit
5 Expires: August 26, 2018 Cisco Systems
6 A. Clemm
7 Huawei
8 E. Nilsen-Nygaard
9 A. Tripathy
10 Cisco Systems
11 February 22, 2018
13 NETCONF Support for Event Notifications
14 draft-ietf-netconf-netconf-event-notifications-08
16 Abstract
18 This document provides a NETCONF binding to subscribed notifications
19 and to YANG push.
21 RFC Editor note: please replace the four references to pre-RFC
22 normative drafts with the actual assigned RFC numbers.
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at https://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on August 26, 2018.
41 Copyright Notice
43 Copyright (c) 2018 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Interleave Capability . . . . . . . . . . . . . . . . . . . . 3
61 4. Compatibility with RFC-5277's create-subscription . . . . . . 3
62 5. Mandatory XML, stream and datastore support . . . . . . . . . 3
63 6. Transport connectivity . . . . . . . . . . . . . . . . . . . 4
64 6.1. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 4
65 6.2. Configured Subscriptions . . . . . . . . . . . . . . . . 4
66 7. Notification Messages . . . . . . . . . . . . . . . . . . . . 5
67 8. Dynamic Subscriptions and RPC Error Responses . . . . . . . . 5
68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
70 11. Normative References . . . . . . . . . . . . . . . . . . . . 6
71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
72 A.1. Event Stream Discovery . . . . . . . . . . . . . . . . . 7
73 A.2. Dynamic Subscriptions . . . . . . . . . . . . . . . . . . 8
74 A.3. Configured Subscriptions . . . . . . . . . . . . . . . . 15
75 A.4. Subscription State Notifications . . . . . . . . . . . . 20
76 Appendix B. Changes between revisions . . . . . . . . . . . . . 22
77 B.1. v07 to v08 . . . . . . . . . . . . . . . . . . . . . . . 22
78 B.2. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 22
79 B.3. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 22
80 B.4. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 22
81 B.5. v01 to v03 . . . . . . . . . . . . . . . . . . . . . . . 23
82 B.6. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 23
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
85 1. Introduction
87 This document provides a binding for events streamed over the NETCONF
88 protocol [RFC6241] as per
89 [I-D.draft-ietf-netconf-subscribed-notifications]. In addition, as
90 [I-D.ietf-netconf-yang-push] is itself built upon
91 [I-D.draft-ietf-netconf-subscribed-notifications], this document
92 enables a NETCONF client to request and receive updates from a YANG
93 datastore located on a NETCONF server.
95 2. Terminology
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in RFC 2119 [RFC2119].
101 The following terms are defined in
102 [I-D.draft-ietf-netconf-subscribed-notifications]: notification
103 message, stream, publisher, receiver, subscriber, subscription,
104 configured subscription.
106 3. Interleave Capability
108 To support multiple subscriptions on a single session, a NETCONF
109 publisher MUST support the :interleave capability as defined in
110 [RFC5277]. Such support MUST be indicated by the following
111 capability: "urn:ietf:params:netconf:capability:interleave:1.0".
112 Advertisement of both the :interleave capability and
113 "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" within a
114 NETCONF capability exchange MUST indicate that a NETCONF publisher is
115 able to receive, process, and respond to NETCONF requests and
116 [I-D.draft-ietf-netconf-subscribed-notifications] subscription
117 operations.
119 4. Compatibility with RFC-5277's create-subscription
121 A publisher is allowed to concurrently support both
122 [I-D.draft-ietf-netconf-subscribed-notifications] and [RFC5277]'s
123 "create-subscription" RPC, however this support MUST NOT happen on a
124 single transport NETCONF session. To accomplish this:
126 o A solution must reply with the [RFC6241] error "operation-not-
127 supported" if a "create-subscription" RPC is received on a NETCONF
128 session where at least one subscription is currently active.
129 o It is a prohibited to send updates or state change notifications
130 for a configured subscription on a NETCONF session where the
131 create-subscription RPC has successfully created a subscription.
132 o A "create-subscription" RPC MUST be rejected if a subscription is
133 already active across that NETCONF transport session.
135 5. Mandatory XML, stream and datastore support
137 A NETCONF publisher MUST support XML encoding of RPCs and
138 Notifications.
140 A NETCONF publisher supporting
141 [I-D.draft-ietf-netconf-subscribed-notifications] MUST support the
142 "NETCONF" event stream identified in that draft.
144 A NETCONF publisher supporting [I-D.ietf-netconf-yang-push] MUST
145 support the operational state datastore as defined by
146 [I.D.draft-ietf-netmod-revised-datastores].
148 6. Transport connectivity
150 6.1. Dynamic Subscriptions
152 For dynamic subscriptions, if the NETCONF session involved with the
153 "establish-subscription" terminates, the subscription MUST be
154 deleted.
156 6.2. Configured Subscriptions
158 For a configured subscription, there is no guarantee a transport
159 session is currently in place with each associated receiver. In
160 cases where a configured subscription has a receiver in the
161 connecting state and the protocol configured as NETCONF, but no
162 NETCONF transport session exists to that receiver, the publisher MUST
163 initiate a transport session via NETCONF call home [RFC8071], section
164 4.1 to that receiver. Until NETCONF connectivity is established and
165 a subscription-started state change notification is successfully
166 sent, that receiver MUST remain in a status of either "connecting" or
167 "timeout".
169 If the call home fails because the publisher receives receiver
170 credentials which are subsequently declined per [RFC8071],
171 Section 4.1, step S5 authentication, then that receiver MUST be
172 assigned a "timeout" status.
174 If the call home fails to establish for any other reason, the
175 publisher MUST NOT progress the receiver to the "active" state.
176 Additionally, the publisher SHOULD place the receiver into a
177 "timeout" status after a predetermined number of either failed call
178 home attempts or NETCONF sessions remotely terminated by the
179 receiver.
181 NETCONF Transport session connectivity SHOULD be verified via
182 Section 4.1, step S7.
184 If an active NETCONF session is disconnected but the stop-time of a
185 subscription has not been reached, the publisher MUST restart the
186 call home process and return the receiver to the "connecting" state.
188 7. Notification Messages
190 Notification messages transported over NETCONF will be identical in
191 format and content to those encoded using one-way operations defined
192 within [RFC5277], section 4.
194 8. Dynamic Subscriptions and RPC Error Responses
196 Management of dynamic subscriptions occurs via RPCs as defined in
197 [I-D.ietf-netconf-yang-push] and
198 [I-D.draft-ietf-netconf-subscribed-notifications]. When an RPC error
199 occurs, the NETCONF RPC reply MUST include an "rpc-error" element per
200 [RFC6241] with the error information populated as follows:
202 o "error-type" of "application".
203 o "error-tag" of "operation-failed".
204 o Optionally, an "error-severity" of "error" (this MAY but does not
205 have to be included).
206 o "error-app-tag" with the value being a string that corresponds to
207 an identity associated with the error, as defined in
208 [I-D.draft-ietf-netconf-subscribed-notifications] section 2.4.6
209 for general subscriptions, and [I-D.ietf-netconf-yang-push]
210 Appendix A.1, for datastore (YANG-Push) subscriptions. The tag to
211 use depends on the RPC for which the error occurred. Applicable
212 are identities with a base identity of "establish-subscription-
213 error" (for error responses to an establish-subscription request),
214 "modify- subscription-error" (for error responses to a modify-
215 subscription request), "delete-subscription-error" (for error
216 responses to a delete-subscription request), "resynch-
217 subscription-error" (for error responses to resynch-subscription
218 request), or "kill- subscription-error" (for error responses to a
219 kill-subscription request), respectively.
220 o In case of error responses to an establish-subscription or modify-
221 subscription request: optionally, "error-info" containing XML-
222 encoded data with hints regarding parameter settings that might
223 lead to successful requests in the future, per yang-data
224 definitions "establish-subscription-error-datastore" (for error
225 responses to an establish-subscription request) or "modify-
226 subscription-error-datastore (for error responses to a modify-
227 subscription request), respectively.
229 These yang-data that is included in "error-info" SHOULD NOT
230 include the optional leaf "error-reason", as such a leaf would be
231 redundant with the information that is already placed within the
232 error-app-tag.
234 In case of an rpc error as a result of a delete-subscription, or a
235 kill-subscription, or a resynch-subscription request, no error-
236 info needs to be included, as the subscription-id is the only RPC
237 input parameter and no hints regarding RPC input parameters need
238 to be provided.
240 Note that "error-path" does not need to be included with the "rpc-
241 error" element, as subscription errors are generally not associated
242 with nodes in the datastore but with the choice of RPC input
243 parameters.
245 9. Security Considerations
247 Notification messages (including state change notifications) are
248 never sent before the NETCONF capabilities exchange has completed.
250 If a malicious or buggy NETCONF subscriber sends a number of
251 "establish-subscription" requests, then these subscriptions
252 accumulate and may use up system resources. In such a situation,
253 subscriptions MAY be terminated by terminating the underlying NETCONF
254 session. The publisher MAY also suspend or terminate a subset of the
255 active subscriptions on that NETCONF session.
257 The NETCONF Authorization Control Model [rfc6536bis] SHOULD be used
258 to control and restrict authorization of subscription configuration.
260 10. Acknowledgments
262 We wish to acknowledge the helpful contributions, comments, and
263 suggestions that were received from: Andy Bierman, Yan Gang, Sharon
264 Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins,
265 Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen,
266 and Guangying Zheng.
268 11. Normative References
270 [I-D.draft-ietf-netconf-subscribed-notifications]
271 Voit, E., Clemm, A., Gonzalez Prieto, A., Tripathy, A.,
272 and E. Nilsen-Nygaard, "Custom Subscription to Event
273 Streams", draft-ietf-netconf-subscribed-notifications-10
274 (work in progress), January 2018.
276 [I-D.ietf-netconf-yang-push]
277 Clemm, Alexander., Voit, Eric., Gonzalez Prieto, Alberto.,
278 Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B.
279 Lengyel, "YANG Datastore Subscription", February 2018,
280 .
283 [I.D.draft-ietf-netmod-revised-datastores]
284 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
285 and R. Wilton, "Network Management Datastore
286 Architecture", draft-ietf-netmod-revised-datastores-10
287 (work in progress), January 2018.
289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
290 Requirement Levels", BCP 14, RFC 2119,
291 DOI 10.17487/RFC2119, March 1997,
292 .
294 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
295 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
296 .
298 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
299 and A. Bierman, Ed., "Network Configuration Protocol
300 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
301 .
303 [rfc6536bis]
304 Bierman, A. and M. Bjorklund, "Network Configuration
305 Access Control Module", December 2017,
306 .
309 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
310 RFC 8071, DOI 10.17487/RFC8071, February 2017,
311 .
313 Appendix A. Examples
315 A.1. Event Stream Discovery
317 As defined in [I-D.draft-ietf-netconf-subscribed-notifications] an
318 event stream exposes a continuous set of events available for
319 subscription. A NETCONF client can retrieve the list of available
320 event streams from a NETCONF publisher using the "get" operation
321 against the top-level container "/streams" defined in
322 [I-D.draft-ietf-netconf-subscribed-notifications].
324 The following example illustrates the retrieval of the list of
325 available event streams using the "get" operation.
327
329
330
331
333
334
335
337 Figure 1: Get streams request
339 After such a request, the NETCONF publisher returns a list of event
340 streams available.
342 A.2. Dynamic Subscriptions
344 A.2.1. Establishing Dynamic Subscriptions
346 The following figure shows two successful "establish-subscription"
347 RPC requests as per
348 [I-D.draft-ietf-netconf-subscribed-notifications]. The first request
349 is given a subscription identifier of 22, the second, an identifier
350 of 23.
352 +------------+ +-----------+
353 | Subscriber | | Publisher |
354 +------------+ +-----------+
355 | |
356 | Capability Exchange |
357 |<---------------------------->|
358 | |
359 | |
360 | establish-subscription |
361 |----------------------------->| (a)
362 | RPC Reply: OK, id = 22 |
363 |<-----------------------------| (b)
364 | |
365 | notification message (for 22)|
366 |<-----------------------------|
367 | |
368 | |
369 | establish-subscription |
370 |----------------------------->|
371 | RPC Reply: OK, id = 23 |
372 |<-----------------------------|
373 | |
374 | |
375 | notification message (for 22)|
376 |<-----------------------------|
377 | notification message (for 23)|
378 |<-----------------------------|
379 | |
381 Figure 2: Multiple subscriptions over a NETCONF session
383 To provide examples of the information being transported, example
384 messages for interactions (a) and (b) in Figure 2 are detailed below:
386
388
390
391 NETCONF
392
393 /ex:foo
394
395
396
397 10
398
399
400
402 Figure 3: establish-subscription request (a)
404 As NETCONF publisher was able to fully satisfy the request (a), the
405 publisher sends the subscription identifier of the accepted
406 subscription within message (b):
408
410
412 22
413
414
416 Figure 4: establish-subscription success (b)
418 If the NETCONF publisher had not been able to fully satisfy the
419 request, or subscriber has no authorization to establish the
420 subscription, the publisher would have sent an RPC error response.
421 For instance, if the "dscp" value of 10 asserted by the subscriber in
422 Figure 3 proved unacceptable, the publisher may have returned:
424
426
427 application
428 operation-failed
429 error
430
431 dscp-unavailable
432
433
434
436
437 100
438
439
440
441
443 Figure 5: an unsuccessful establish subscription
445 The subscriber can use this information in future attempts to
446 establish a subscription.
448 A.2.2. Modifying Dynamic Subscriptions
450 An existing subscription may be modified. The following exchange
451 shows a negotiation of such a modification via several exchanges
452 between a subscriber and a publisher. This negotiation consists of a
453 failed RPC modification request/response, followed by a successful
454 one.
456 +------------+ +-----------+
457 | Subscriber | | Publisher |
458 +------------+ +-----------+
459 | |
460 | notification message (for 23)|
461 |<-----------------------------|
462 | |
463 | modify-subscription (id = 23)|
464 |----------------------------->| (c)
465 | RPC error (with hint) |
466 |<-----------------------------| (d)
467 | |
468 | modify-subscription (id = 23)|
469 |----------------------------->|
470 | RPC Reply: OK |
471 |<-----------------------------|
472 | |
473 | notification message (for 23)|
474 |<-----------------------------|
475 | |
477 Figure 6: Interaction model for successful subscription modification
479 If the subscription being modified in Figure 6 is a datastore
480 subscription as per [I-D.ietf-netconf-yang-push], the modification
481 request made in (c) may look like that shown in Figure 7. As can be
482 seen, the modifications being attempted are the application of a new
483 xpath filter as well as the setting of a new periodic time interval.
485
487
490
491
492 /interfaces-state/interface/oper-status
493
494
495 500
496
497
498
499 23
500
501
502
504 Figure 7: Subscription modification request (c)
506 If the NETCONF publisher can satisfy both changes, the publisher
507 sends a positive result for the RPC. If the NETCONF publisher cannot
508 satisfy either of the proposed changes, the publisher sends an RPC
509 error response (d). The following is an example RPC error response
510 for (d) which includes a hint. This hint is an alternative time
511 period value which might have resulted in a successful modification:
513
515
516 application
517 operation-failed
518 error
519
520 period-unsupported
521
522
524
525
526 3000
527
528
529
530
531
533 Figure 8: Modify subscription failure with Hint (d)
535 A.2.3. Deleting Dynamic Subscriptions
537 The following demonstrates deleting a subscription.
539
541
543 22
544
545
547 Figure 9: Delete subscription
549 If the NETCONF publisher can satisfy the request, the publisher
550 replies with success to the RPC request.
552 If the NETCONF publisher cannot satisfy the request, the publisher
553 sends an error-rpc element indicating the modification didn't work.
554 Figure 10 shows a valid response for existing valid subscription
555 identifier, but that subscription identifier was created on a
556 different NETCONF transport session:
558
560
561 application
562 operation-failed
563 error
564
565 no-such-subscription
566
567
568
570 Figure 10: Unsuccessful delete subscription
572 A.3. Configured Subscriptions
574 Configured subscriptions may be established, modified, and deleted
575 using configuration operations against the top-level subtree of
576 [I-D.draft-ietf-netconf-subscribed-notifications] or
577 [I-D.ietf-netconf-yang-push].
579 In this section, we present examples of how to manage the
580 configuration subscriptions using a NETCONF client.
582 A.3.1. Creating Configured Subscriptions
584 For subscription creation, a NETCONF client may send:
586
589
590
591
592
593
595
596 22
597 encode-xml
598
599 NETCONF
600
601 1.2.3.4
602 1234
603
604
605
606
607
608
610 Figure 11: Create a configured subscription
612 If the request is accepted, the publisher will indicate this. If the
613 request is not accepted because the publisher cannot serve it, no
614 configuration is changed. In this case the publisher may reply:
616
618
619 application
620 resource-denied
621 error
622
623 Temporarily the publisher cannot serve this
624 subscription due to the current workload.
625
626
627
629 Figure 12: Response to a failed configured subscription establishment
631 After a subscription has been created, NETCONF connectivity to each
632 receiver's IP address and port will be established if it does not
633 already exist. This will be accomplished via [RFC8071].
635 The following figure shows the interaction model for the successful
636 creation of a configured subscription.
638 +----------+ +-----------+ +---------+
639 |Config Ops| | Publisher | | 1.2.3.4 |
640 +----------+ +-----------+ +---------+
641 | | |
642 | Capability Exchange | |
643 |<-------------------------->| |
644 | | |
645 | | |
646 | Edit-config | |
647 |--------------------------->| |
648 | RPC Reply: OK | |
649 |<---------------------------| |
650 | | Call Home |
651 | |<-------------->|
652 | | |
653 | | subscription- |
654 | | started |
655 | |--------------->|
656 | | |
657 | | notification |
658 | | message |
659 | |--------------->|
661 Figure 13: Interaction model for configured subscription
662 establishment
664 A.3.2. Modifying Configured Subscriptions
666 Configured subscriptions can be modified using configuration
667 operations against the top-level container "/subscriptions".
669 For example, the subscription established in the previous section
670 could be modified as follows, here a adding a second receiver:
672
675
676
677
678
679
681
682
683 1922
684
685
686
687 1.2.3.5
688
689
690 1234
691
692
693
694
695
696
698 Figure 14: Modify configured subscription
700 If the request is accepted, the publisher will indicate success. The
701 result is that the interaction model described in Figure 13 may be
702 extended as follows.
704 +----------+ +-----------+ +---------+ +---------+
705 |Config Ops| | Publisher | | 1.2.3.4 | | 1.2.3.5 |
706 +----------+ +-----------+ +---------+ +---------+
707 | | notification | |
708 | | message | |
709 | |--------------->| |
710 | Edit-config | | |
711 |--------------------------->| | |
712 | RPC Reply: OK | | |
713 |<---------------------------| | |
714 | | subscription- | |
715 | | started | |
716 | |---------------------------->|
717 | | | |
718 | | notification | |
719 | | message | |
720 | |--------------->| |
721 | |---------------------------->|
722 | | | |
724 Figure 15: Interaction model for configured subscription modification
726 Note in the above that in the specific example above, modifying a
727 configured subscription actually resulted in "subscription-started"
728 notification. And because of an existing NETCONF session, no
729 additional call home was needed. Also note that if the edit of the
730 configuration had impacted the filter, a separate modify-subscription
731 would have been required for the original receiver.
733 A.3.3. Deleting Configured Subscriptions
735 Configured subscriptions can be deleted using configuration
736 operations against the top-level container "/subscriptions".
737 Deleting the subscription above would result in the following flow
738 impacting all active receivers.
740 +----------+ +-----------+ +---------+ +---------+
741 |Config Ops| | Publisher | | 1.2.3.4 | | 1.2.3.5 |
742 +----------+ +-----------+ +---------+ +---------+
743 | | | |
744 | | notification | |
745 | | message | |
746 | |--------------->| |
747 | |---------------------------->|
748 | | | |
749 | Edit-config | | |
750 |--------------------------->| | |
751 | RPC Reply: OK | | |
752 |<---------------------------| | |
753 | | subscription- | |
754 | | terminated | |
755 | |--------------->| |
756 | |---------------------------->|
757 | | | |
759 Figure 16: Interaction model for configured subscription deletion
761 A.4. Subscription State Notifications
763 A publisher will send subscription state notifications according to
764 the definitions within
765 [I-D.draft-ietf-netconf-subscribed-notifications]).
767 A.4.1. subscription-started and subscription-modified
769 A "subscription-started" over NETCONF encoded in XML would look like:
771
773 2007-09-01T10:00:00Z
774
776 39
777 encode-xml
778
779 NETCONF
780
781 /ex:foo
782
783
784
785
787 Figure 17: subscription-started subscription state notification
789 The "subscription-modified" is identical to Figure 17, with just the
790 word "started" being replaced by "modified".
792 A.4.2. subscription-completed, subscription-resumed, and replay-
793 complete
795 A "subscription-completed" would look like:
797
799 2007-09-01T10:00:00Z
800
802 39
803
804
806 Figure 18: subscription-completed notification in XML
808 The "subscription-resumed" and "replay-complete" are virtually
809 identical, with "subscription-completed" simply being replaced by
810 "subscription-resumed" and "replay-complete" in both encodings.
812 A.4.3. subscription-terminated and subscription-suspended
814 A "subscription-terminated" would look like:
816
818 2007-09-01T10:00:00Z
819
821 39
822
823 suspension-timeout
824
825
826
828 Figure 19: subscription-terminated subscription state notification
830 The "subscription-suspended" is virtually identical, with
831 "subscription-terminated" simply being replaced by "subscription-
832 suspended".
834 Appendix B. Changes between revisions
836 (To be removed by RFC editor prior to publication)
838 B.1. v07 to v08
840 o Tweaks and clarification on :interleave.
842 B.2. v06 to v07
844 o XML encoding and operational datastore mandatory.
845 o Error mechanisms and examples updated.
847 B.3. v05 to v06
849 o Moved examples to appendices
850 o All examples rewritten based on namespace learnings
851 o Normative text consolidated in front
852 o Removed all mention of JSON
853 o Call home process detailed
854 o Note: this is a major revision attempting to cover those comments
855 received from two week review.
857 B.4. v03 to v04
859 o Added additional detail to "configured subscriptions"
860 o Added interleave capability
861 o Adjusted terminology to that in draft-ietf-netconf-subscribed-
862 notifications
863 o Corrected namespaces in examples
865 B.5. v01 to v03
867 o Text simplifications throughout
868 o v02 had no meaningful changes
870 B.6. v00 to v01
872 o Added Call Home in solution for configured subscriptions.
873 o Clarified support for multiple subscription on a single session.
874 No need to support multiple create-subscription.
875 o Added mapping between terminology in yang-push and [RFC6241] (the
876 one followed in this document).
877 o Editorial improvements.
879 Authors' Addresses
881 Alberto Gonzalez Prieto
882 VMware
884 Email: agonzalezpri@vmware.com
886 Eric Voit
887 Cisco Systems
889 Email: evoit@cisco.com
891 Alexander Clemm
892 Huawei
894 Email: ludwig@clemm.org
896 Einar Nilsen-Nygaard
897 Cisco Systems
899 Email: einarnn@cisco.com
901 Ambika Prasad Tripathy
902 Cisco Systems
904 Email: ambtripa@cisco.com