idnits 2.17.1
draft-ietf-netconf-notification-messages-02.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.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 03, 2017) is 2397 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)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF E. Voit
3 Internet-Draft Cisco Systems
4 Intended status: Standards Track A. Bierman
5 Expires: April 6, 2018 YumaWorks
6 A. Clemm
7 Huawei
8 T. Jenkins
9 Cisco Systems
10 October 03, 2017
12 Notification Message Headers and Bundles
13 draft-ietf-netconf-notification-messages-02
15 Abstract
17 This document defines a new notification message format, using yang-
18 data. Included are:
20 o a new notification mechanism and encoding to replace the one way
21 operation of RFC-5277
23 o a set of common, transport agnostic message header objects.
25 o how to bundle multiple event records into a single notification
26 message.
28 o how to ensure these new capabilities are only used with capable
29 receivers.
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on April 6, 2018.
48 Copyright Notice
50 Copyright (c) 2017 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Header Objects . . . . . . . . . . . . . . . . . . . . . . . 3
68 4. Encapsulation of Header Objects in Messages . . . . . . . . . 4
69 4.1. One Notification per Message . . . . . . . . . . . . . . 5
70 4.2. Many Notifications per Message . . . . . . . . . . . . . 6
71 4.3. Notification Type in Payload . . . . . . . . . . . . . . 8
72 5. Configuration of Headers . . . . . . . . . . . . . . . . . . 8
73 6. Discovering Receiver Support . . . . . . . . . . . . . . . . 9
74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
80 11.2. Informative References . . . . . . . . . . . . . . . . . 18
81 Appendix A. Changes between revisions . . . . . . . . . . . . . 19
82 Appendix B. Issues being worked . . . . . . . . . . . . . . . . 20
83 Appendix C. Subscription Specific Headers . . . . . . . . . . . 20
84 Appendix D. Implications to Existing RFCs . . . . . . . . . . . 21
85 D.1. Implications to RFC-7950 . . . . . . . . . . . . . . . . 21
86 D.2. Implications to RFC-8040 . . . . . . . . . . . . . . . . 21
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
89 1. Introduction
91 Mechanisms to support subscription to event notifications and yang
92 datastore push are being defined in [subscribe] and [yang-push].
93 Work on those documents has shown that notifications described in
94 [RFC7950] section 7.16 could benefit from transport independent
95 headers. Communicating the following information to receiving
96 applications can be done without explicit linkage to an underlying
97 transport protocol:
99 o the time information was generated
101 o the time the information was sent
103 o a signature to verify authenticity
105 o the process generating the information
107 o an originating request correlation
109 o an ability to bundle information records into one a message
111 o the ability to check for message loss/reordering
113 The document describes information elements needed for the functions
114 above. It also provides YANG structures for sending messages
115 containing one or more events and/or update records to a receiver.
117 2. Terminology
119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
121 "OPTIONAL" in this document are to be interpreted as described in BCP
122 14 [RFC2119] [RFC8174] when, and only when, they appear in all
123 capitals, as shown here.
125 The definition of notification is in RFC 7950 [RFC7950]. Publisher,
126 receiver, and subscription are defined in [subscribe].
128 3. Header Objects
130 There are a number of transport independent headers which should have
131 common definition. These include:
133 o subscription-id: provides a reference into the reason the
134 publisher believed the receiver wishes to be notified of this
135 specific information.
137 o notification-time: the time an event, datastore update, or other
138 item is recognized and recorded within the publisher.
140 o notification-id: Identifies the name of the notification, per the
141 YANG notification statement. May also provide the name of a yang-
142 data statement (whether transporting other types of messages is in
143 scope is tbd).
145 o observation-domain-id: identifies the publisher process which
146 discovered and recorded the event notification. (note: look to
147 reuse the domains set up with IPFIX.)
149 o message-time: the time the message was packaged sent to the
150 transport layer for delivery to the receiver.
152 o signature: allows an application to sign a message so that a
153 receiver can verify the authenticity of the message.
155 o message-id: for a specific message generator, this identifies a
156 message which includes one or more event records.
158 o previous-message-id: the message-id of the message preceding the
159 current one intended for the same receiver. When used in
160 conjunction with the current message-id, this allows loss/
161 duplication across previous messages to be discovered. If there
162 was no previous message from a message generator, the reserved id
163 "0" must be sent.
165 o message-generator-id: identifier for the process which created the
166 message. This allows disambiguation of an information source,
167 such as the identification of different line cards sending the
168 messages. Used in conjunction with previous-message-id, this can
169 help find drops and duplications when messages are coming from
170 multiple sources on a device. If there is a message-generator-id
171 in the header, then the previous-message-id MUST be the message-id
172 from the last time that message-generator-id was sent.
174 4. Encapsulation of Header Objects in Messages
176 A specific set of well-known objects are of potential use to
177 networking layers prior being interpreted by some receiving
178 application layer process. By exposing this object information as
179 part of a header, and by using standardized object names, it becomes
180 possible for this object information to be leveraged in transit.
182 The objects defined in the previous section are these well-known
183 header objects. These objects are identified within a dedicated
184 header subtree which leads off a particular transportable message.
185 This allows header objects to be easily be decoupled, stripped, and
186 processed separately.
188 There are two types of transportable messages: one format is used
189 when there is one notification being encapsulated, and another format
190 used when there are many notifications being bundled into one
191 message.
193 A receiver which supporting this document MUST be able to handle
194 receipt of either type of message from an publisher. It is possible
195 that changes between message types can occur without any prior
196 indication.
198 4.1. One Notification per Message
200 Below are contents of a message when there is only one notification
201 in an encapsulated and encoded message:
203 yang-data message
204 +-- message-header
205 | +-- notification-time yang:date-and-time
206 | +-- subscription-id* uint32
207 | +-- notification-id? uint32
208 | +-- observation-domain-id? string
209 | +-- module? yang-identifier
210 | +-- notification-type? notification
211 | +-- message-id? uint32
212 | +-- message-time? yang:date-and-time
213 | +-- previous-message-id? uint32
214 | +-- message-generator-id? string
215 | +-- signature? string
216 +-- receiver-record-contents?
218 An actual instance of such a message when encoded in XML might look
219 like:
221
223
224
225 2017-02-14T00:00:02Z
226
227
228 823472
229
230
231 ietf-yang-push
232
233
234 push-change-update
235
236
237 2017-02-14T00:00:05Z
238
239
240 456
241
242
243 567
244
245
246 lKIo8s03fd23.....
247
248
249
251
252
253
255
256
257
258
260 4.2. Many Notifications per Message
262 In many implementations, it may be inefficient to transport every
263 notification independently. Instead, scale and processing speed can
264 be improved by placing multiple notifications into one transportable
265 bundle.
267 When this is done, one additional header field becomes valuable.
268 This is the "notification-count" which would tally the quantity of
269 records which make up the contents of the bundle. It is true that
270 the record count can be derived, but early access to this information
271 could change receiver processing.
273 The format of a bundle would look as below. When compared to the
274 unbundled notification, note that the headers have been split so that
275 one set of headers associated with the notification occur once at the
276 beginning of the message, and additional record specific headers
277 which occur before individual records.
279 yang-data bundled-message
280 +-- bundled-message-header
281 | +-- message-time yang:date-and-time
282 | +-- message-id? uint32
283 | +-- previous-message-id? uint32
284 | +-- message-generator-id? string
285 | +-- signature? string
286 | +-- notification-count? uint16
287 +-- notifications*
288 +-- notification-header
289 | +-- notification-time yang:date-and-time
290 | +-- subscription-id* uint32
291 | +-- notification-id? uint32
292 | +-- module? yang-identifier
293 | +-- notification-type? notification
294 | +-- observation-domain-id? string
295 +-- receiver-record-contents?
297 An actual instance of a bundled notification might look like:
299
301
302
303 2017-02-14T00:00:05Z
304
305
306 456
307
308
309 567
310
311
312 lKIo8s03fd23...
313
314
315 2
317
318
319
320
321
322
323 2017-02-14T00:00:02Z
324
325
326 823472
327
328
329 ietf-yang-push
330
331
332 push-change-update
333
334
335
337
338
339
341
342
343
344
345
346 ...(record #2)...
347
348
349
351 4.3. Notification Type in Payload
353 The type of notification transported within a record could be a
354 header. However the notification name and namespace is the first
355 element in the receiver record contents payload. As this can be
356 determined by the YANG module containing the notification-stmt as
357 represented within the first part of the encapsulated notification
358 message, this information need not replicated within a header.
360 5. Configuration of Headers
362 A publisher MUST select the set of headers to use for a particular
363 message. The two mandatory headers which MUST always be applied to
364 every message are 'message-time' and 'subscription-id'
365 Beyond these two mandatory headers, the following are additional
366 sources which can add common headers to a message.
368 1. Publisher wide default headers for all notifications. These are
369 included if a common header is inserted into 'additional-headers'
370 shown in the figure below.
372 2. More notification specific headers may also be desired. If new
373 headers are needed for a specific notification in the YANG model,
374 this can be populated through 'per-notification-headers'.
376 3. An application process may also identify common headers to use
377 when transporting notifications for a specific subscription. How
378 these are identified to a publisher is out-of-scope.
380 The set of headers used for any particular message is the superset of
381 headers for the items listed above.
383 The YANG tree showing elements of configuration is depicted in the
384 following figure.
386 module: ietf-notification-messages
387 +--rw additional-default-headers {publisher}?
388 +--rw additional-headers* common-header
389 +--rw notification-specific-default* [module notification]
390 +--rw module yang:yang-identifier
391 +--rw notification notification
392 +--rw per-notification-headers* common-header
394 Configuration Model structure
396 Of note in this tree is the optional feature of 'publisher'. This
397 feature indicates an ability to send notifications. A publisher
398 supporting this specification MUST also be able to parse any messages
399 received as defined in this document.
401 6. Discovering Receiver Support
403 We need capability exchange from the receiver to the publisher at
404 transport session initiation to indicate support for this
405 specification.
407 For all types of transport connections, if the receiver indicates
408 support for this specification, then it MAY be used. In addition,
409 [RFC5277] one-way notifications MUST NOT be used if the receiver
410 indicates support for this specification to a publisher which also
411 supports it.
413 Where NETCONF transport is used, advertising this specification's
414 namespace during an earlier client capabilities discovery phase MAY
415 be used to indicate support for this specification:
417
418
419
420 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
421
422
423 4
424
426 NOTE: It is understood that even though it is allowed in [RFC6241]
427 section 8.1, robust NETCONF client driven capabilities exchange is
428 not something which is common in implementation. Therefore reviewers
429 are asked to submit alternative proposals to the mailing list.
431 For RESTCONF, a mechanism for capability discovery is TBD. Proposals
432 are also welcome here.
434 The mechanism described above assumes that a capability discovery
435 phase happens before a subscription is started. This is not always
436 the case. As an example, consider HTTP2 configured subscriptions
437 from section 3.1.3 of [http-push], there is no guarantee that a
438 capability exchange has taken place before the updates are pushed. A
439 solution for this could be that a receiver would reply "ok" and reply
440 with the client capabilities as part of the POST. (Or just use a
441 different HTTP status code like 202 instead of 200 'ok'). As such a
442 requirement creates a new dependency for [http-push] upon this
443 specification, more discussion is required to decide if this is a
444 viable solution.
446 7. YANG Module
448 file "ietf-notification-messages.yang"
449 module ietf-notification-messages {
450 yang-version 1.1;
451 namespace
452 "urn:ietf:params:xml:ns:yang:ietf-notification-messages";
453 prefix nm;
455 import ietf-yang-types { prefix yang; }
456 import ietf-restconf { prefix rc; }
458 organization "IETF";
459 contact
460 "WG Web:
461 WG List:
463 Editor: Eric Voit
464
466 Editor: Alexander Clemm
467
469 Editor: Andy Bierman
470
472 Editor: Tim Jenkins
473 ";
475 description
476 "This module contains conceptual YANG specifications for yang-data
477 messages carrying notifications with well known header objects.";
479 revision 2017-10-03 {
480 description
481 "Initial version.";
483 reference
484 "draft-ietf-netconf-notification-messages-02";
485 }
487 /*
488 * FEATURES
489 */
491 feature publisher {
492 description
493 "This feature indicates that support for both publisher and
494 receiver of messages complying to the specification.";
495 }
497 /*
498 * IDENTITIES
499 */
501 /* Identities for common headers */
503 identity common-header {
504 description
505 "A well known header which can be included somewhere within a
506 message.";
507 }
508 identity notification-time {
509 base common-header;
510 description
511 "Header information consisting of the time an originating process
512 created the notification.";
513 }
515 identity notification-id {
516 base common-header;
517 description
518 "Header information consisting of an identifier for an instance
519 of a notification egressing a publisher. ";
520 }
522 identity subscription-id {
523 base common-header;
524 description
525 "Header information consisting of the identifier of the
526 subscription associated with the notification being
527 encapsulated.";
528 }
530 identity observation-domain-id {
531 base common-header;
532 description
533 "Header information identifying the software entity which created
534 the notification (e.g., process id).";
535 }
537 identity message-id {
538 base common-header;
539 description
540 "Header information that identifies a message to a specific
541 receiver";
542 }
544 identity message-time {
545 base common-header;
546 description
547 "Header information consisting of time the message headers were
548 placed generated prior to being sent to transport";
549 }
551 identity previous-message-id {
552 base common-header;
553 description
554 "Header information consisting of a message id previously sent by
555 the publisher to a specific receiver (allows detection of
556 loss/duplication).";
557 }
559 identity message-generator-id {
560 base common-header;
561 description
562 "Header information consisting of an identifier for a software
563 entity which created the message (e.g., linecard 1).";
564 }
566 identity signature {
567 base common-header;
568 description
569 "Header information consisting of a signature on the contents of
570 a message. This can be useful for originating applications to
571 verify record contents even when shipping over unsecure
572 transport.";
573 }
575 identity notification-count {
576 base common-header;
577 description
578 "Header information consisting of the quantity of notifications in
579 a bundled-message for a specific receiver.";
580 }
582 /*
583 * TYPEDEFs
584 */
586 typedef common-header {
587 type identityref {
588 base common-header;
589 }
590 description
591 "Type of header object which may be included somewhere within a
592 message.";
593 }
595 typedef notification-type {
596 type string {
597 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
598 }
599 description
600 "The name of a notification within a YANG module.";
601 reference
602 "RFC-7950 Section 7.16";
603 }
604 /*
605 * GROUPINGS
606 */
608 grouping notification-and-module {
609 description
610 "A location of a notification within a yang model.";
611 leaf module {
612 type yang:yang-identifier;
613 description
614 "Name of the YANG module supported by the publisher.";
615 }
616 leaf notification {
617 type notification-type;
618 description
619 "The name of a notification within a YANG module.";
620 }
621 }
623 grouping message-header {
624 description
625 "Header information included with a message.";
626 leaf message-id {
627 type uint32;
628 description
629 "Unique id for a message going to a receiver.";
630 }
631 leaf message-time {
632 type yang:date-and-time;
633 description
634 "time the message was generated prior to being sent to
635 transport.";
636 }
637 leaf previous-message-id {
638 type uint32;
639 description
640 "message id previously sent by publisher to a specific
641 receiver (allows detection of loss/duplication).";
642 }
643 leaf message-generator-id {
644 type string;
645 description
646 "Software entity which created the message (e.g., linecard 1).";
647 }
648 leaf signature {
649 type string;
650 description
651 "Any originator signing of the contents of a message. This can
652 be useful for originating applications to verify record contents
653 even when shipping over unsecure transport.";
654 }
655 }
657 grouping notification-header {
658 description
659 "Common informational objects which might help a receiver
660 interpret the meaning, details, or importance of a notification.";
661 leaf notification-time {
662 type yang:date-and-time;
663 mandatory true;
664 description
665 "Time the system recognized the occurrence of an event.";
666 }
667 leaf-list subscription-id {
668 type uint32;
669 description
670 "Id of the subscription which led to the notification being
671 generated.";
672 }
673 leaf notification-id {
674 type uint32;
675 description
676 "Identifier for the notification record.";
677 }
678 leaf observation-domain-id {
679 type string;
680 description
681 "Software entity which created the notification record (e.g.,
682 process id).";
683 }
684 uses notification-and-module;
685 }
687 /*
688 * YANG-DATA messages for receivers
689 */
691 rc:yang-data message {
692 container message {
693 presence
694 "Indicates attempt to communicate notifications to a receiver.";
695 description
696 "Message to a receiver containing one notification";
697 container message-header {
698 description
699 "delineates header info from content for easy parsing.";
701 uses notification-header;
702 uses message-header;
703 }
704 anydata notification-contents {
705 description
706 "Encapsultates objects following YANG's notification-stmt
707 grammar of RFC-7950 section 14. Within are the notified
708 objects the publisher actually generated in order to be
709 passed to a receiver after all filtering has completed.";
710 }
711 }
712 }
714 rc:yang-data bundled-message {
715 container bundled-message {
716 presence
717 "Indicates attempt to communicate notifications to a receiver.";
718 description
719 "Message to a receiver containing many bundled notifications";
720 container bundled-message-header {
721 description
722 "Header info for messages.";
723 uses message-header {
724 refine message-time {
725 mandatory true;
726 }
727 }
728 leaf notification-count {
729 type uint16;
730 description
731 "Quantity of notification records in a bundled-message
732 specific receiver.";
733 }
734 }
735 list notifications {
736 description
737 "Set of notifications to a receiver.";
738 container notification-header {
739 description
740 "Header info for each bundled notification.";
741 uses notification-header;
742 }
743 anydata notification-contents {
744 description
745 "Encapsultates objects following YANG's notification-stmt
746 grammar of RFC-7950 section 14. Within are the notified
747 objects the publisher actually generated in order to be
748 passed to a receiver after all filtering has completed.";
750 }
751 }
752 }
753 }
755 /*
756 * DATA-NODES
757 */
759 container additional-default-headers {
760 if-feature "publisher";
761 description
762 "This container maintains a list of which additional notifications
763 should use which common headers if the receiver supports this
764 specification. The name starts with additional because there are
765 some mandatory common headers not listed in the container. These
766 headers are (1) message-time and (2) subscription-id.";
767 leaf-list additional-headers {
768 type common-header;
769 description
770 "This list contains the additional default headers which are to
771 be applied to each message from this publisher.";
772 }
773 list notification-specific-default {
774 key "module notification";
775 description
776 "For any included notification, this list provides additional
777 common headers.";
778 uses notification-and-module;
779 leaf-list per-notification-headers {
780 type common-header;
781 description
782 "The set of additional default headers for a specific
783 notification.";
784 }
785 }
786 }
787 }
788
790 8. Backwards Compatibility
792 With this specification, there is no change to YANG's 'notification'
793 statement
795 Legacy clients are unaffected, and existing users of [RFC5277],
796 [RFC7950], and [RFC8040] are free to use current behaviors until all
797 involved device support this specification.
799 9. Security Considerations
801 Certain headers might be computationally complex for a publisher to
802 deliver. Signatures or encryption are two examples of this. It MUST
803 be possible to suspend or terminate a subscription due to lack of
804 resources based on this reason.
806 Decisions on whether to bundle or not to a receiver are fully under
807 the purview of the Publisher. A receiver could slow delivery to
808 existing subscriptions by creating new ones. (Which would result in
809 the publisher going into a bundling mode.)
811 10. Acknowledgments
813 For their valuable comments, discussions, and feedback, we wish to
814 acknowledge Martin Bjorklund, Einar Nilsen-Nygaard, and Kent Watsen.
816 11. References
818 11.1. Normative References
820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
821 Requirement Levels", BCP 14, RFC 2119,
822 DOI 10.17487/RFC2119, March 1997,
823 .
825 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
826 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
827 .
829 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
830 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
831 May 2017, .
833 [subscribe]
834 Voit, E., Clemm, A., Gonzalez Prieto, A., Prasad Tripathy,
835 A., and E. Nilsen-Nygaard, "Custom Subscription to Event
836 Notifications", September 2017,
837 .
840 11.2. Informative References
842 [http-push]
843 Voit, Eric., Clemm, Alexander., Tripathy, A., Nilsen-
844 Nygaard, E., and Alberto. Gonzalez Prieto, "Restconf and
845 HTTP transport for event notifications", August 2016,
846 .
849 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
850 and A. Bierman, Ed., "Network Configuration Protocol
851 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
852 .
854 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
855 RFC 7950, DOI 10.17487/RFC7950, August 2016,
856 .
858 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
859 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
860 .
862 [yang-push]
863 Clemm, A., Voit, E., Gonzalez Prieto, A., Prasad Tripathy,
864 A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore
865 push updates", April 2017,
866 .
869 Appendix A. Changes between revisions
871 (To be removed by RFC editor prior to publication)
873 v01 - v02
875 o Fixed the yang-data encapsulation container issue
877 o Updated object definitions to point to RFC-7950 definitions
879 o Added headers for module and notification-type.
881 v00 - v01
883 o Alternative to 5277 one-way notification added
885 o Storage of default headers by notification type
887 o Backwards compatibility
889 o Capability discovery
890 o Move to yang-data
892 o Removed dscp and record-type as common headers. (Record type can
893 be determined by the namespace of the record contents. Dscp is
894 useful where applications need internal communications within a
895 Publisher, but it is unclear as to whether this use case need be
896 exposed to a receiver.
898 Appendix B. Issues being worked
900 (To be removed by RFC editor prior to publication)
902 Is this capability just for notifications, or is it for any yang-data
903 element too?
905 There is redundancy with module and notification in the headers,
906 along with the notification name and the namespace as the first
907 element of the pushed content. Do we remove one of them?
909 A complete JSON document is supposed to be sent as part of Media Type
910 "application/yang-data+json". As we are sending separate
911 notifications after eachother, we need to choose whether we start
912 with some extra encapsulation for the very first message pushed, or
913 if we want a new Media Type for streaming updates.
915 Improved discovery mechanisms for NETCONF
917 Do we want to have additional headers for a specific notification?
918 Right now this is included, but it could be excluded.
920 Should we defer support for HTTP2 configured subscriptions until this
921 draft is available? Without capabilities exchange, it might just be
922 easier to wait. In addition, JSON encoding still needs a
923 notification type which is not exising or represented in
924 referenceable in existing yang-models.
926 Need to ensure the proper references exist to a notification
927 definition driven by RFC-7950 which is acceptable to other eventual
928 users of this specification.
930 We need to link to Andy Bierman's anydata extensibility draft.
932 Appendix C. Subscription Specific Headers
934 (To be removed by RFC editor prior to publication)
936 This section discusses a future functional addition which could
937 leverage this draft. It is included for informational purposes only.
939 A dynamic subscriber might want to mandate that certain headers be
940 used for push updates from a publisher. Some examples of this
941 include a subscriber requesting to:
943 o establish this subscription, but just if transport messages
944 containing the pushed data will be encrypted,
946 o establish this subscription, but only if you can attest to the
947 information being delivered in requested notification records, or
949 o provide a sequence-id for all messages to this receiver (in order
950 to check for loss).
952 Providing this type of functionality would necessitate a new revision
953 of the [subscribe]'s RPCs and state change notifications.
954 Subscription specific header information would overwrite the default
955 headers identified in this document.
957 Appendix D. Implications to Existing RFCs
959 (To be removed by RFC editor prior to publication)
961 YANG one-way exchanges currently use a non-extensible header and
962 encoding defined in section 4 of RFC-5277. These RFCs MUST be
963 updated to enable this draft. These RFCs SHOULD be updated to
964 provide examples
966 D.1. Implications to RFC-7950
968 Sections which expose netconf:capability:notification:1.0 are 4.2.10
970 Sections which provide examples using netconf:notification:1.0 are
971 7.10.4, 7.16.3, and 9.9.6
973 D.2. Implications to RFC-8040
975 Section 6.4 demands use of RFC-5277's netconf:notification:1.0, and
976 later in the section provides an example.
978 Authors' Addresses
980 Eric Voit
981 Cisco Systems
983 Email: evoit@cisco.com
984 Andy Bierman
985 YumaWorks
987 Email: andy@yumaworks.com
989 Alexander Clemm
990 Huawei
992 Email: ludwig@clemm.org
994 Tim Jenkins
995 Cisco Systems
997 Email: timjenki@cisco.com